Actualités cartes graphiques

Une GeFFX pour remplacer le P4 ?

Publié le 26/12/2003 à 12:21 par
Imprimer

Une équipe de recherche de l'université de Stanford a publié il y a quelques jours les prémices d'un langage de programmation qui permet de répartir "facilement" certaines tâches entre le CPU et le GPU. Ici, il n'est plus question de rendu 3D mais d'utiliser le GPU pour d'autres calculs. La puissance de calcul des GPUs devenant de plus en plus importante, il est logique de se demander si elle ne pourrait pas servir à autre chose qu'à affiner les courbes de Lara Croft.

Ce langage, BrookGPU, permet de spécifier quelle partie du code doit être calculée par le GPU et quelle autre partie doit être traitée normalement par le CPU. Le GPU agit donc ici comme une sorte de co-processeur ou plus précisément comme une unité vectorielle (comme le SSE) supplémentaire.

Directement après l'annonce de la concrétisation de ce langage, les gros titres ont fusés : "Votre GPU va remplacer votre CPU !", "Une GeForce FX vaut un Pentium 4 10 GHz !"… Tout ceci n'est bien entendu pas vraiment correct et n'est rien d'autre qu'un effet d'annonce autour de ce projet de recherche de l'université de Stanford (projet sponsorisé par NVIDIA, au passage). Un GPU ne peut pas remplacer un CPU car il ne peut faire qu'un nombre très limité de tâches alors qu'un CPU est polyvalent. Tout ce que le GPU peut faire c'est seconder le CPU en prenant en charge une partie du code qui peut profiter d'un traitement vectoriel. Il est donc tentant de vouloir comparer la puissance théorique de l'unité vectorielle d'un Pentium 4 à celle délivrée par le GPU (ou plutôt par les pipelines du GPU) :

    - Pentium 4 3.2 GHz : 6.4 GFlops
    - GeForce FX 5950 Ultra : 22.8 GFlops
    - Radeon 9800XT : 26.4 GFlops
Bien que ces chiffres laissent rêveur, ils ne représentent rien d'autre qu'une puissance maximale théorique. Si nous prenons un calcul élémentaire identique sur les 3, les puissances deviennent :

    - Pentium 4 3.2 GHz : 6.4 GFlops
    - GeForce FX 5950 Ultra : 7.6 GFlops
    - Radeon 9800XT : 13.2 GFlops
Un autre élément entre ensuite en compte : l'accès au données. Il devra normalement se faire via la lecture d'une texture. C'est d'ailleurs l'occasion de rappeler qu'une texture n'est rien d'autre qu'un tableau de données ! Ces données peuvent être des couleurs mais aussi bien d'autres choses. L'accès à ces données ne pouvant être distincts pour les 4 éléments de chaque pipeline d'un GPU, il faudra souvent ne traiter qu'un élément à la fois. En 3D cela reviendrait à ne pas pouvoir calculer toutes les couleurs en même temps. En terme de puissance, cela revient à la diviser par 4 :

    - Pentium 4 3.2 GHz : 6.4 GFlops
    - GeForce FX 5950 Ultra : 1.9 GFlops
    - Radeon 9800XT : 3.3 GFlops
Imaginons maintenant que le calcul demande 4 opérations et imaginons également que 8 registres soient utilisés (comme c'est le cas sur un CPU). La GeForce peut profiter de ses multiples unités de calcul mais est pénalisée par les 8 registres (les développeurs de BrookGPU avaient évoqué ce détail dans leur documentation de juillet  mais l'ont effacé dans la version de décembre ) :

    - Pentium 4 3.2 GHz : 6.4 GFlops
    - GeForce FX 5950 Ultra : 0.95 GFlops
    - Radeon 9800XT : 3.3 GFlops
Du coup, le Pentium 4 a beaucoup moins à rougir face aux GPUs. Bien entendu ceci n'est qu'une approche basique du problème car le tout est bien plus complexe que cela. Elle permet simplement de relativiser quelques gros titres qui ont fait la une ces derniers jours.

Concrètement, il y a encore beaucoup de limitations dans l'utilisation d'un GPU pour qu'il puisse seconder le CPU. La Radeon peut par exemple être directement écartée car elle ne supporte pas le FP32. Les GeForce FX retrouvent les mêmes limitations que dans les Pixel Shader 2.0 actuels. Les développeurs de BrookGPU ont d'ailleurs dû développer une version NVOGL (OpenGL avec extensions NVIDIA) spécialement pour les GeForce FX car elles ne gèrent pas les formats de données floating point dans DirectX.

Autrement dit, les ingénieurs de NVIDIA et ATI devront encore travailler un petit peu avant que ceci ne soit réellement utilisable. Car se servir d'un GPU actuel pour du calcul général revient un petit peu à essayer de s'éclairer grâce au courant tiré d'une pomme de terre. Ceci dit, l'évolution des GPUs étant fulgurante, il n'est pas trop tôt pour commencer à y travailler. Pour avoir quelques chose d'utilisable lors de la sortie des NV50 et R500 ? Nous pouvons même imaginer que ceci pourrait permettre dans le futur à ATI et NVIDIA de proposer leurs puces sur des marchés très différents.

Si vous désirez en savoir plus sur ce sujet, nous ne pouvons que vous recommander la lecture, que nous avions déjà trouvée très intéressante lors de sa publication au mois de mai, des travaux de Matthew Trentacoste  (étudiant/chercheur en sciences informatiques).

Les 5900XT en France

Publié le 24/12/2003 à 11:28 par
Imprimer

Dans cette news, nous vous parlions de l’arrivée au Japon à des prix compétitifs des GeForce FX 5900XT, cette déclinaison du 5900 cadencée à 390/350 (contre 400/425) et offrant en pratique des performances environ 7% inférieures. Les GeForce FX 5900XT commencent à arriver en France et leur prix est également compétitif, puisque l’on trouve par exemple selon Monsieur Prix le modèle Point Of View  à 219 €, le modèle Gigabyte  à 239 € et enfin la carte Leadtek  à 247 €.

4 Millions de XGI en 2004 ?

Publié le 19/12/2003 à 17:15 par
Imprimer

Dans une interview accordée à DigiTimes , un dirigeant de XGI a indiqué que la compagnie comptait multiplier par un facteur d'au moins 20 ses ventes l’année prochaine. Pour cette année, XGI devrait vendre 200 000 puces, dont une grande majorité sont des puces XP initialement développées par Trident, dont la division graphique a été rachetée en juin par XGI.

XGI semble confiant dans le succès de sa ligne Volari, qui est rentré en production en fin de mois de Novembre. En effet XGI espère vendre pas moins de 4 à 5 Millions de puces graphiques en 2004 !

Le DeltaChrome arrive enfin

Publié le 18/12/2003 à 17:50 par
Imprimer

Club3D mange décidément à tous les râteliers. Après avoir commercialisé une carte à base de Volari Duo, le fabricant annonce officiellement le lancement d'une gamme de produit autour des DeltaChrome de S3, puce qui a été annoncée il y a tout juste un an ! Pour rappel, il existe différentes versions du DeltaChrome :

- DeltaChrome S4, mémoire 64/128 bits, 4 pixel pipelines PS2.0+, 2 unités de vertex shader 2.0+
- DeltaChrome S8, mémoire 128 bits, 8 pixel pipelines PS2.0+, 4 unités de vertex shader 2.0+
- DeltaChrome F1, hautes fréquences, mémoire 128 bits, 8 pixel pipelines PS2.0+, 4 unités de vertex shader 2.0+

La première carte de Club3D utilisera la version S8 du DeltaChrome cadencée à 300 MHz, sera équipée de 256 Mo de DDR à 300 MHz et disposera d'un support complet de la HDTV. Elle devrait être disponible début 2004 au prix de 155€.

Notre récente expérience avec le Volari Duo de XGI nous indique de rester méfiants tant qu'aucun test complet avec des drivers corrects n'aura été réalisé. Nous rappellerons également que Club3D, filialle de C.P. Technology (PowerColor) est également le fabricant qui distribue en ce moment les Volari et ce, uniquement en Europe. Les premières cartes à base de DeltaChrome de Club3D / C.P. Tech seront également réservées à l'Europe. Nous espérons que Club3D ne se sert pas de l'Europe pour tester le marché avec des produits qui ne sont pas encore prêts ... Nous espérons bien entendu qu'il en ira autrement avec les DeltaChrome.

Drivers XGI, la suite

Publié le 18/12/2003 à 14:13 par
Imprimer

Suite à la news concernant les bizarreries dans les drivers XGI, nous avons fait quelques essais en modifiant le fichier des drivers XGI afin que les applications ne soit plus reconnues (modification de la chaîne de caractère 3 d m a r k 0 3 . e x e en 3 d m u r k 0 3 . e x e par exemple) puisque le simple renommage de fichier ne permettait pas de contourner la détection. Les résultats sont assez impressionnants, puisque par exemple on passe de 20.6 fps à 8.8 fps dans la scène Mother Nature de 3DMark03 (1024*768, le score global suit la même tendance), ou encore 88.2 à ... 18.7 fps dans le bench BotMatch intégré à Unreal Tournament 2003 (1600*1200). On remarquera que la baisse est toutefois moindre dans notre propre démo, plus réaliste, puisque le score ne passe « que » de 28.6 à 14.6 fps ...

D’où vient cette baisse de vitesse ? D’optimisations spécifiques à ces applications bien entendu. Ces dernières sont peut être multiples, mais la vérification par exemple de l’intégration de clip plane pour les démos (comme NVIDIA dans 3DMar03 à une époque) n’est pas vérifiable sans aide du développeur. Toutefois, nous avons remarqué que lorsque le driver détectait une des applications listées, il désactivait le filtrage trilinéaire pour ne faire que du simple bilinéaire, c'est-à-dire sans aucune transition entre les différents niveau de mip map. Bien entendu cela réduit la charge de travail par deux (interpolation à partir de 4 texels au lieu de 8). En fait étant donné l'importance de la baisse on peut même se demander si le second GPU est bien activé "par défaut" ...

Voici pour illustrer nos propos un screenshot sous Unreal Tournament 2003 avec les drivers d’origines, et un autre screenshot une fois que ces detections sont désactivées :


Nous avons ici utilisé la commande firstcoloredmip pour que les différents niveaux de détails soit colorés afin de bien mettre en évidence la différence au niveau du filtrage.

Pire, sous Halo avec la détection d’origine, la qualité graphique est vraiment déplorable, a tel point qu’on se croirait en 640*480 quand on est en 1024*768, si bien que l’on pense qu’il ne s’agit pas uniquement d’un problème de filtrage trilinéaire. Ce problème est résolu lorsque l’on désactive les optimisations, mais du coup on assiste à un slide show. Il est à noter que la fonction screenshot ne fonctionne pas correctement lorsque Halo est détecté par le driver, ce qui nous empêche de vous faire voir la différence de qualité graphique.

Voilà qui explique donc en grande partie pourquoi dans les benchs courant la Volari s’en sort relativement bien, et pourquoi dans des jeux moins courants pour les benchs mais pas forcément moins joués c’est la catastrophe. Dans notre protocole de test habituel utilisant en majeure partie des jeux non détectés, la Volari Duo V8 Ultra arrivait en effet à 55% des performances d’une GeForce4 Ti 4600, avec dans le meilleurs des cas 77% des performances de cette dernière sous UT2003 et les optimisations spécifiques qui vont avec (40% sans) et 15% de mieux sous Quake 3, puisqu'en OpenGL par défaut et contrairement à ce qui se passe en Direct3D XGI désactive d'office le filtrage trilinéaire et baisse également par défaut le niveau de détail des textures comme vous pouvez le constater en comparant les filtrages d'ATI et de XGI :


Au final, on peut se demander quel est l’intérêt pour XGI d’intégrer ce genre de choses dans ces drivers. En effet, si XGI pense que ses puces ne sont pas assez rapides pour effectuer un filtrage trilinéaire, autant le désactiver totalement des drivers plutôt que de le désactiver que dans certaines applications qui sont généralement utilisées pour mesurer les performances des cartes graphiques. Il ne reste plus qu’à espérer pour XGI qu’il apprendra de ses erreurs et que de futurs drivers viendront corriger le tir et améliorerons fortement les performances comme la qualité afin d'avoir un résultat digne d’une carte à 400 € ...

Top articles