GeForce 6600 : le test

Introduction

Après avoir vu plus en détails ce que nous proposaient les nouveaux GPU haut de gamme, nous nous attaquons désormais au milieu de gamme en commençant par le tout dernier chip de nVidia, le 6600 (nom de code : NV43).

L’entreprise située à Santa Clara n’a pas toujours fait preuve de la plus grande efficacité sur ce secteur. Auparavant, il existait une grosse différence d’architecture entre le haut de gamme (GeForce 3, GeForce 4), et le bas de gamme qui dérivait d’une ancienne génération (GeForce 2 MX 200/400, GeForce 4 MX), avec des écarts assez énormes en termes de performances et de prix. En fait il n’y avait pas vraiment de cartes de milieu de gamme, si l’on excluait la présence des cartes haut de gamme de génération précédente.

Depuis les GeForce FX, les choses ont changées et on constate désormais la présence de cartes qui dérivent directement du haut de gamme (technologies identiques), mais avec la désactivation de certains pixel pipelines, le recours à de la mémoire moins chère et quelques ajustements de fréquences. L’avantage pour nVidia consiste bien sûr à pouvoir recycler des puces haut de gamme partiellement défectueuses au niveau de quelques pipelines ou de la fréquence maximum.

Avant d’effectuer ce test, nous nous attendions donc à un chip sans surprise, simple GeForce 6800 GT coupé en deux. Nous étions loin du compte…

Architecture

Après nous avoir présenté sa nouvelle architecture avec le NV40 au printemps dernier, nVidia fidèle à la tradition instaurée il y a quelques années nous offre avec le NV43 un dérivé milieu de gamme afin de toucher un plus large public. L’enjeu est ici bien différent de celui du NV40 car si le haut de gamme consiste avant tout en une question de prestige, c’est sur le milieu et le bas de gamme que la firme réalise le plus gros de ses profits. Pas question donc de faire des choix technologiques extrêmes au détriment de la réalité économique comme il semble que cela a été le cas lors de la conception des GeForce 6800 dont l’objectif était de regagner la couronne des performances à n’importe quel prix.

Mais cela ne signifie pas pour autant que le NV43 soit inintéressant, ou que nVidia ait commis les mêmes erreurs que par le passé. Contrairement à la GeForce 4MX qui offrait des performances acceptables mais les fonctionnalités d’une GeForce 2, ou à la GeForce FX5600 qui offrait toutes les fonctionnalités de la 5800 mais une puissance brute insuffisante pour les exploiter, la GeForce 6600 se présente comme une alternative intéressante pour les joueurs ne souhaitant pas se ruiner dans une carte graphique haut de gamme. nVidia a-t-il trouvé la formule magique permettant de combiner performances et fonctionnalités ? C’est ce que nous allons voir.

Dans cette partie nous n’allons pas détailler de nouveau toute l’architecture de la famille NV4x. Au lieu de cela nous allons nous attarder sur les spécificités du NV43 avant de revenir plus précisément sur des technologies déjà présentes dans le NV40 comme le Geometry Instancing ou l’Ultra Shadow mais qui méritent que l’on s’y attarde plus attentivement afin de savoir ce qui se cache derrière ces termes marketing.

La gamme GeForce 6

Avant l’arrivée du NV43, la gamme GeForce 6 était constituée de 4 modèles différents :

Contrairement à ce que laisse penser ce tableau, il faut bien garder à l’esprit que toute cette famille reste basée sur une seule puce : le NV40. C’est flagrant pour les 6800 Ultra et GT mais c’est également le cas pour les 6800 et 6800LE qui sont aussi des NV40 auxquels certaines unités sont désactivées.

Cette façon de créer toute une gamme de cartes autour d’une seule puce n’est pas nouvelle : ATI avait procédé de la même manière avec son R300. L’intérêt de cette stratégie est d’occuper rapidement le marché avec une nouvelle architecture, mais aussi de limiter les pertes engendrées par les puces défectueuses. Mais elle présente également des limitations qui la condamnent à rester une solution temporaire.

Les cartes étant basées sur des NV40, pour nVidia les coûts sont les mêmes pour toute la gamme ce qui lui interdit de baisser le prix de ses puces autant qu’il le souhaiterait. De plus la production est insuffisante pour alimenter le marché milieu de gamme, le marché haut de gamme ayant la priorité et celui-ci n’est déjà pas assez fourni.

C’est pour l’ensemble de ces raisons que nVidia ne pouvait se contenter de la 6800 (la version LE étant réservée aux OEM pour l’instant) pour occuper le marché milieu de gamme. Entre en jeu le NV43 utilisé dans les GeForce 6600GT et GeForce 6600.

Une nouvelle puce, un nouvel équilibre

Cette fois il s’agit bien d’une nouvelle puce et cela se traduit dans le nombre de transistors utilisés : 143 millions contre 222 pour le NV40. Le NV43 ressemble à première vue à un demi NV40 : outre le nombre d’unités de vertex shaders réduit à 3, et le nombre de pixel pipelines qui passe à 8, le bus se retrouve réduit à 128 bits. En pratique toutefois nVidia a mis à profit l’expérience acquise avec le NV40 pour affiner légèrement son architecture et augmenter son efficacité. Ainsi selon les situations les pipes du NV43 seraient de 2 à 10 % plus efficaces que ceux du NV40 à fréquence égale.

Il faut également noter que, dans le but de réduire encore plus les coûts, le NV43 sera le premier GPU de chez nVidia à utiliser le processus de gravure 0.11µ de chez TSMC afin d’augmenter le nombre de puces par wafers (galettes de silicium).

Techniquement, si vous avez lu avec attention jusqu’ici et que vous suivez l’actualité des cartes 3D, quelque chose doit vous choquer. En effet si l’on compare l’ancien haut de gamme de nVidia (la GeForce FX 5950) à la toute nouvelle 6600 GT, on constate que le fillrate est prés de deux fois supérieur pour le nouveau venu (4Gpixels/s pour le NV43, 1.9GPixels/s pour le NV38) alors que sa bande passante elle est presque… deux fois inférieure ! (16 Go/s pour le NV43, 30.4 Go/s pour le NV38). Et ce genre de déséquilibre est en général bien mauvais signe pour les performances. Qui a oublié la GeForce 2 GTS dont le core avait augmenté de 80% comparé à la GeForce DDR alors que sa bande passante n’avait elle progressée dans le même temps que de 10% ?

Oui mais voilà, depuis les choses ont bien changées et le rendu s’est très nettement complexifié avec notamment l’apparition des shaders. Si dans un premier temps leur utilisation restait relativement limitée à certains effets bien spécifique, force est de constater qu’aujourd’hui les jeux commencent à utiliser des shaders de plus en plus complexes, demandant un nombre d’instructions toujours plus élevé. Far Cry et plus récemment Doom 3 ont ouvert la voie mais ce n’est qu’un début. Les shaders utilisés aujourd’hui restent encore relativement simples, mais déjà l’Unreal Engine 3 laisse présager des exigences des futurs moteurs 3D en terme de puissance de shading.

Vous vous demandez sans doute le rapport avec le problème qui nous préoccupe actuellement concernant la bande passante de la GeForce 6600 GT ? C’est simple : le temps où les jeux se contentaient d’appliquer deux textures par pixel et de les écrire dans le frame buffer est révolu, désormais les pixels doivent effectuer plusieurs passages dans le pipeline. Avec des shaders compris entre 50 et 100 instructions pour la prochaine génération de moteurs 3D il est clair que le goulet d’étranglement ne se situera plus au niveau du fillrate brut et de la bande passante mais bien au niveau de la puissance de shading.

Par ailleurs la flexibilité acquise à la génération précédente, et la puissance de traitement des nouvelles puces permet de réaliser des économies de bande passante : il est désormais possible de se passer de textures de pré calcul ou des fameux cube maps de normalisation hérités de l’époque du pipeline fixe. Aujourd’hui les programmeurs peuvent réaliser ces opérations avec de véritables calculs arithmétiques, sans gaspiller de la bande passante pour faire transiter ces textures.

Le choix de nVidia de doter sa puce de 8 pixel pipelines et d’augmenter dans le même temps la puissance de traitement de ses pipelines se comprend donc bien mieux, mais cette réflexion en amène une autre: puisque les pixels doivent effectuer plusieurs passages dans le pipeline, ce qui nécessitera invariablement plusieurs cycles, cela implique donc que dans la plupart des cas il n’y aura pas 8 pixels à écrire dans le frame buffer à chaque cycle. Dans ce cas là, pourquoi gâcher des transistors qui de toute façon resteront inutilisés la plupart du temps ? Nous touchons là à une des particularités du NV43 et pour bien la comprendre il est nécessaire de faire un petit rappel technique.

Il faut tout d’abord cesser de considérer le pixel pipeline comme un ensemble indivisible dans lequel les pixels arriveraient par un bout du setup engine, et ressortirait par un autre bout dans le frame buffer. En pratique derrière tout ça il y a deux unités bien distinctes. Pour être tout à fait exact dans la terminologie employée nous allons faire une distinction qui, si elle est utilisée par l’API OpenGL, n’est pas prise en compte par Direct3D. Techniquement il n’est correct de parler de pixels qu’au niveau du frame buffer, toutes les opérations qui sont effectuées auparavant le sont sur des fragments. Cette précision effectuée, reprenons notre chemin le long du pipeline graphique. Une fois les fragments générés (par quad) par le setup engine, ils passent par les unités de fragment shading et cette opération peut être répétée le nombre de fois nécessaire pour appliquer toutes les opérations du shader.

Après cette étape les fragments ne deviennent pas encore des pixels, ils doivent avant cela passer par une dernière unité : le ROP (Raster Operation Unit). Le rôle de cette unité est multiple : c’est en particulier à ce niveau qu’est effectué le FSAA ainsi que le test de profondeur qui détermine si le fragment est visible ou pas. Mais c’est aussi dans cette unité qu’à lieu le blending qui permet de mélanger la valeur d’un fragment avec celle contenue dans le frame buffer. Enfin c’est ici que se situe la fameuse astuce permettant de doubler le fillrate lorsque les écritures dans le frame buffer sont désactivées. En effet comme vous pouvez le constater sur le schéma ci-dessous, on trouve dans cette unité un ZROP qui réalise l’écriture des valeurs Z dans le ZBuffer mais aussi un CROP (C pour Color) qui se charge de l’écriture du pixel dans le frame buffer. nVidia a cependant doté ce CROP d’une capacité intéressante puisque dans le cas où il n’y a pas d’écriture dans le frame buffer il peut également fonctionner comme un second ZROP.

Maintenant que vous savez ce qu’est un ROP il est inutile de faire durer le suspense plus longtemps : le NV43 ne dispose que de 4 ROP ! 8 pixel pipelines ? 4 ROP ? Les ingénieurs de chez nVidia ont-ils consommés les substances hallucinogènes promises par leur CEO à leur concurrent canadien ? A priori non, et si vous avez bien suivi la partie qui précédait cela doit même vous sembler logique. Puisque dans la majeure partie des cas les unités de shading ne seront pas en mesure de fournir 8 fragments aux ROP et que même si c’était le cas ces derniers n’auraient pas la bande passante nécessaire pour les écrire dans le frame buffer, les ingénieurs ont donc décidé d’opter pour ce compromis.

Pour les jeux utilisant intensivement les shaders ça ne change donc pas grand-chose vu que le goulet d’étranglement ne se situera pas au niveau des ROP, mais que se passe-t-il dans le cas d’un rendu très simple ? Pour répondre à cette question il faut d’abord se poser une autre question : dans quelles conditions effectue-t-on un « rendu très simple » ? Dans une phase d’initialisation du ZBuffer par exemple, pour éviter de faire des calculs redondants sur des fragments qui ne seront pas affichés en utilisant au mieux le hardware d’élimination des parties cachés tôt dans le pipeline. Dans ce cas pas de problème : ce type de rendu peut s’effectuer à 8 valeurs par cycle grâce à l’astuce des ROP. Même principe pour le rendu des volumes d’ombre ou le rendu dans un shadow buffer. Que reste-t-il ? Et bien typiquement tous les anciens jeux. Et dans ce genre de situations inutile de tergiverser : effectivement les ROP constitueront le principal goulet d’étranglement du NV43. Mais soyons sérieux : vu la puissance dont disposent les puces actuels ce sacrifice n’est pas vraiment dérangeant.

D’autant que dans ce type de situations la configurations particulière du NV43 autorise une astuce intéressante : puisqu’il est inutile de fournir 8 fragments par cycle aux ROP qui seront vite saturés, autant faire deux passages dans le pipeline et donc fournir 8 fragments dual texturés tous les deux cycles. Le ROP est ainsi capable de retirer 4 fragments dual texturés à chaque cycle, ce qui signifie en clair que dans ce cas précis le NV43 se comporte comme une puce… 4×2 !

Alors évidemment, on peut regretter qu’il n’y ait pas 8 ROP, et on peut aussi regretter que le bus ne fasse pas 256 bits mais il faut quand même comprendre que les ingénieurs doivent composer avec un nombre de transistors limités (même si l’on dépasse allègrement les 100 millions dans le cas du NV43). C’est plus particulièrement vrai sur ce segment du marché et par conséquent ils ne peuvent pas se permettre de les gâcher pour accélérer des situations où le gain de vitesse aurait un intérêt des plus limités. Comment auriez vous réagi si l’on vous avait présenté des benchs sous Quake III par exemple ?

Le NV43 s’inscrit donc dans une vision à plus long terme impliquant un rééquilibrage total des ressources qui passent du ratio fillrate/bande passante, à la puissance de shading. Même s’il est plus que probable que vous ne jouiez pas aux jeux issus de l’Unreal Engine 3 sur une 6600GT, on ne peut pas reprocher à nVidia de poser dés aujourd’hui les bases de l’évolution de ses chips 3D.

Architecture (suite)

Cine FX 3.0

Au niveau des fonctionnalités de ce nouveau chip pas de mauvaise surprise, le NV43 reprend toutes les caractéristiques du NV40. On retrouve donc entre autres l’architecture CineFX 3.0. Sous ce terme nVidia regroupe :

• les Vertex Shaders 3.0, qui offrent un support des branchements dynamiques et la possibilité d’adresser une texture dans un vertex program
• les Pixels Shaders 3.0, qui offrent également un support des branchements dynamiques et supprime les limitations des Pixels Shaders 2.0
• le support complet des textures flottantes avec filtrage et blending des textures au format FP16

Pour plus de détails sur cette architecture nous vous invitons à lire notre dernier comparatif de GPU.

Geometry Instancing

Une des règles de base dans la programmation 3D que nVidia et ATI répètent sans cesse aux programmeurs tient en un mot : « batch ». Ce qui peut se traduire par « regrouper » ou « traiter par lot ».

Il faut en effet savoir que chaque changement d’état de l’API, ou chaque appel à une fonction de tracé implique un coût sur le CPU et demande une synchronisation CPU/GPU qui brise le parallélisme. Dans ce genre de situations il est très courant de se retrouver limité par le CPU. Par conséquent regrouper le maximum de primitives partageant des attributs identiques et les afficher avec un seul appel à une fonction de tracé est un gain très important de performance. Une façon très simple de s’en rendre compte consiste à passer d’un affichage en mode immédiat en dessinant chaque primitive indépendamment, à un affichage regroupant toutes les primitives dans un tableau de sommets et les affichant avec une seule fonction de tracé.

Prenons un exemple pratique : vous avez bien retenu la leçon précédente et vous avez donc placé le modèle 3D d’un arbre dans un tableau de sommets. Maintenant vous souhaitez dessiner une forêt. La façon de s’y prendre consiste à placer votre arbre et à l’orienter comme vous le souhaitez, lancer un premier appel à la fonction de tracé, se déplacer changer l’orientation (pour éviter que vos arbres soient alignés de façon totalement irréaliste) lancer un deuxième appel à la fonction de tracé et ainsi de suite… Si le modèle d’arbre utilise un petit nombre de triangles (de l’ordre de quelques centaines) alors le rendu est entièrement limité par le CPU qui doit traiter tous les appels aux fonctions de tracé et les changements d’état de l’API (le changement de position et d’orientation).

Oui mais comment faire autrement ? Une solution consiste à ne plus stocker un modèle de l’arbre dans son repère local (espace objet) mais tous les modèles des arbres constituant la forêt dans le repère global (espace monde). Ainsi il n’y a plus besoin de se déplacer et de changer l’orientation avant de renvoyer la géométrie d’un arbre, on peut dessiner la forêt avec un seul appel. Le problème de cette solution est qu’elle demande de répliquer le modèle autant de fois qu’il y a d’arbres et qu’elle sature donc la mémoire vidéo de façon inutile vu qu’il s’agit de la même géométrie positionnée à plusieurs endroits. Pas très satisfaisant…

Jusqu’à présent il n’y avait pas d’autres solutions pour ce genre de situations, mais le Geometry Instancing a justement été créé pour répondre à ce besoin. Comment ? Tout simplement en déplaçant le travail du CPU au GPU. Ainsi au lieu de passer au GPU uniquement un flux de sommets et de lui spécifier un ensemble d’états et d’attributs pour ce flux, le programmeur peut spécifier deux flux : le premier contient toujours les données de chaque sommet et le deuxième contient les données variant pour chaque instance.

Si l’on reprend notre exemple précédent, le flux 0 contiendrait les sommets de notre modèle d’arbre, et le flux 1 contiendrait les matrices permettant de changer la position et l’orientation de chaque instance de l’arbre. Ainsi il devient possible de rendre toute la forêt avec un seul appel à la fonction de tracé et sans dupliquer les sommets !

Il faut toutefois garder à l’esprit que cette technique a un surcoût pour le GPU et que son intérêt décroît au fur et à mesure que le nombre de sommets envoyé à chaque appel à la fonction de tracé augmente. Ainsi au delà de 1000 polygones par modèle le Geometry Instancing n’a plus aucun intérêt.

Pour finir avec le Geometry Instancing j’aimerais revenir sur un dernier point qui a suscité bien des confusions dernièrement. Initialement présentée par nVidia comme étant liée aux Vertex Shaders 3.0, il s’est avéré qu’en fait les puces ATI étaient également capables de faire du Geometry Instancing, et ce depuis le R300 ! En pratique les choses sont plus compliquées et pour l’instant ATI ne peut exposer son support du Geometry Instancing que par le biais d’une astuce, tout simplement parce que Microsoft ne souhaite pas que cette fonctionnalité soit exposée par des puces ne gérant pas le Shader Model 3.0. Il est difficile de trouver une justification à la firme de Redmond dans cette affaire, le Geometry Instancing étant entièrement décorellé du Shader Model.

Il est vrai que le support variable des fonctionnalités par les différentes puces dans le passé à quelque peu nuit à leur utilisation et par conséquent définir une base claire et saine pour les puces supportant le Shader Model 3.0 est une bonne chose. Mais s’il est logique et compréhensible de forcer les puces se revendiquant compatibles avec le Shader Model 3.0 à supporter le Geometry Instancing, il est en revanche déplorable d’empêcher les puces de la génération précédente qui supportent cette technologie de l’exposer.

Ultra Shadow 2.0

Le NV43 bénéficie aussi de l’Ultra Shadow 2.0, là encore derrière ce terme marketing pompeux on retrouve en fait des fonctionnalités désormais bien connues depuis la GeForce FX. Comme son nom l’indique cette technologie, qui regroupe en fait 3 techniques bien distinctes, a pour but d’accélérer les calculs des ombres lors de l’utilisation de l’algorithme des volumes d’ombre comme c’est le cas dans Doom III.

Pour bien comprendre le fonctionnement de cette technologie nous allons d’abord faire un rapide rappel de l’algorithme des volumes d’ombre. Considérons un objet et une source lumineuse, le volume d’ombre associé est défini par les lignes partant de la source lumineuse et passant par les sommets situés sur la silhouette de l’objet du point de vue de la lumière.

L’algorithme des volumes d’ombre consiste tout d’abord à déterminer la silhouette d’un objet de la scène, à générer une extrusion de cette surface pour déterminer le volume d’ombre de cet objet associé à cette source lumineuse. Une fois ce calcul effectué, la scène est rendue en 3 passes pour déterminer les pixels dans l’ombre :

• Passe 1 : la première passe rend la scène de façon classique le stencil buffer étant initialisé à 0. Puis les écritures dans le frame buffer sont désactivées.
• Passe 2 : les faces avant du volume d’ombre sont rendues en incrémentant le stencil buffer lorsqu’elles passent le test Z (elles sont « devant » l’objet)
• Passe 3 : Les faces arrière du volume d’ombre sont rendues en décrémentant le stencil buffer lorsqu’elles passent le test Z.

On remarque que si l’objet est situé devant ou derrière le volume d’ombre, sa valeur stencil est de zéro. A l’inverse elle vaudra 1 s’il est dans le volume d’ombre, il ne reste donc plus qu’à effectuer les calculs d’éclairage pour tous les pixels ayant une valeur de 0 dans le stencil buffer. Voilà pour le rappel théorique, voyons maintenant comment l’Ultra Shadow permet d’améliorer les performances dans ce genre de situations.

La première chose que l’on remarque c’est qu’il faut faire une distinction dans le traitement des faces avant (incrémentation du stencil) et des faces arrière (décrémentation du stencil). Comme on ne peut spécifier qu’une seule opération au stencil buffer cela oblige donc à effectuer deux passes en distinguant les faces avant des faces arrière. Pour éviter cela nVidia (et ATI aussi vu que ses cartes disposent depuis le R300 d’une fonctionnalité similaire) permet de spécifier deux opérations distinctes selon que les faces traitées soient des faces avants ou arrière ce qui permet de regrouper les passes 2 et 3 en une seule passe.

La deuxième technique est désormais bien connue vu qu’elle a générée beaucoup de confusions dans la compréhension des architectures de nVidia : elle consiste à permettre à une puce à doubler son fillrate lorsque les écritures dans le frame buffer sont désactivées et que les textures ne sont pas utilisées, comme c’est le cas lors des passes de rendu du volume d’ombre. Ainsi le NV43 peut traiter dans ce genre de situations jusqu’à 8 « zixels » par cycle d’horloge.

Enfin la 3ème technique, apparue avec le NV35 permet de définir un test supplémentaire indiquant si le pixel considéré entre dans les bornes définies par le programmeur. En pratique, lors du rendu du volume d’ombre cela permet de rejeter trivialement et tôt dans le pipeline les pixels qui ne peuvent pas être influencés par le volume d’ombre. On évite ainsi des opérations inutiles sur le stencil buffer. Il faut toutefois noter que cette fonctionnalité n’est pour l’instant exposé que par le biais d’une extension OpenGL : GL_EXT_depth_bounds_test qui n’est pas accessible avec l’API DirectX.

Conclusion

Avant même la présentation officielle du NV40, Jen-Hsun Huang, le CEO de nVidia, l’avait annoncé : la famille NV4x avait été conçue en ayant plusieurs objectifs en tête. Plus de programmabilité, plus de performance, tirer profit du PCI Express, avoir de meilleur yields (taux de rendement), et être extrêmement et facilement modulable, voila le cahier des charges qu’il avait été demandé de remplir aux ingénieurs responsables de l’architecture.

Le premier représentant de la gamme, le NV40, nous avait permis de constater qu’en ce qui concerne les deux premiers points les ingénieurs avaient atteints leur but. Le NV43 quant à lui nous confirme que le dernier objectif est également rempli, c’est en effet la première fois que nVidia est en mesure de nous présenter un dérivé milieu de gamme si rapidement après l’annonce de son chip haut de gamme. Après les errements de la génération précédente, force est donc de constater que nVidia s’est superbement ressaisi avec cette génération en offrant une gamme cohérente et performante à des tarifs compétitifs.

Filtrage des textures

Le filtrage des textures : présentation

Le filtrage des textures est une opération importante et omniprésente dans les jeux. Dès que la distance de vue dépasse les quelques mètres et qu’une texture se prolonge (typiquement, celle du sol), c’est lui qui intervient afin de faire en sorte que les transitions restent invisibles sur cette texture, plus précisément les mipmaps. Que sont les mipmaps ? Des versions basse résolution d’une texture, qui sont appliquées sur les polygones éloignés du joueur, partant du principe qu’une surface éloignée d’un kilomètre n’est pas perçue avec autant de détails qu’une surface située à un mètre. Les mipmaps correspondent donc en quelque sorte à l’antialiasing des textures ; un antialiasing précalculé ce qui permet d’utiliser des filtres de bonne qualité. Au passage, on remarque que l’utilisation des mipmaps permet également de préserver la qualité des textures, tout en économisant la bande passante. Notez toutefois que les mipmaps prennent plus de place en mémoire, et qu’ils demandent du calcul supplémentaire à la puce pour déterminer le niveau de mip à employer.

Seul problème, les dimensions des mipmaps sont divisées par deux à chaque fois (ex : texture de 256×256 pixels, puis 128×128 pour le mipmap suivant, puis 64×64, etc.). D’où la nécessité d’un filtrage, afin que les transitions deviennent invisibles y compris à longue distance.

Sans rentrer dans les détails, la différence de filtrage s’explique entre autres par le nombre de sample de texture utilisés au départ pour chaque pixel final – 4 pour le bilinéaire, 8 pour le trilinéaire, 16 pour l’anisotropie 2x, etc. Le trilinéaire consiste simplement à appliquer deux fois un filtrage bilinéaire, et à interpoler les deux points résultats.

Observons le résultat sur le tunnel de 3DMark03. L’écran se divise en 4 : en haut un filtrage bilinéaire est appliqué, en bas un filtrage trilinéaire ; à gauche le rendu est normal, à droite les mipmaps ont été colorés afin d’y voir plus clair. Si l’on observe ces derniers, on se rend compte assez clairement que dans le cadre d’un filtrage bilinéaire, il n’y a pas vraiment de transition entre chaque texture de qualité différente, au contraire du filtrage trilinéaire. Ainsi, en comparant maintenant le rendu à gauche, en bilinéaire on distingue facilement au premier plan les transitions entre mipmaps même si ceux-ci ne sont pas colorés. Ce n’est pas le cas du trilinaire.

Dès lors, quel est l’intérêt de l’anisotropie ? C’est très simple. En passant à chaque mipmap suivant, on perd en résolution, donc en détail et en précision : ceci génère un flou aisément observable. Ce flou est amplifié par l’effet de perspective, qui est utilisé par tous les jeux représentant une scène en 3 dimensions. L’anisotropie consiste donc à augmenter encore le nombre de texels sources, et à prendre en compte les déformations de l’objet sur lequel la texture est appliquée.

Ici, on retrouve le filtrage trilinéaire en haut, et l’anisotropie 16X en bas. Au final, on arrive donc à supprimer complètement le flou.

Evidemment, les textures appliquées à ce tunnel permettent de distinguer plus facilement ces différences. On retrouve pourtant exactement la même situation dans les jeux. Prenons par exemple Serious Sam : Second contact, et la fameuse grande cathédrale.

Comparons maintenant l’herbe, avec de gauche à droite un filtrage bilinéaire, trilinéaire, anisotropique 16x (note : aucun zoom n’est utilisé).

Ce qu’il faut bien comprendre, c’est que les filtrages trilinéaires et anisotropiques ne poursuivent pas le même but. Le premier permet une transition invisible entre les mipmaps, alors que le second supprime l’effet de flou. Aussi, la différence entre un filtrage anisotropique bilinéaire et trilinéaire est faible, parce que dans les deux cas le flou est supprimé ; or c’est à partir du flou que l’on est capable de distinguer les mipmaps. Ce point est capitale pour la suite, aussi étudions encore quelques screenshots, l’un utilisant un filtrage anisotropique bilinéaire, l’autre un filtrage anisotropique trilinéaire :

Sur ce type de surface, la différence est pratiquement invisible car il n’y a presque pas de flou. Prenons donc un mur de Teotihuacan :

Ici le flou et donc la différence est plus visible, on aperçoit de nouveau les différents mipmaps. Notez que la différence est toutefois bien plus faible que la comparaison entre le filtrage bilinéaire/trilinéaire, et que cette différence sera d’autant plus faible qu’un niveau élevé d’anisotropie sera appliqué.

nVidia vs nVidia

Les ForceWare 65 livrés avec les GeForce 6600 introduisent une nouvelle optimisation nommée “Anisotropic Sample Optimization”, qui réalise des compromis de qualité au niveau des samples des textures, à partir du deuxième mipmap.

Celle-ci vient donc se rajouter aux deux autres optimisations déjà présentes, concernant le filtrage anisotropique et le filtrage trilinéaire. Le problème, c’est qu’il faut donc prendre en compte deux facteurs dans le panneau de contrôle pour régler la qualité du filtrage : d’une part le réglage général de qualité…

… et d’autre part l’activation ou non de chaque optimisation.

Par exemple, l’activation de l’optimisation sur le trilinéaire entraînera une dégradation visuelle plus ou moins importante suivant la position du slide de qualité. Le tableau suivant résume chaque situation.

En laissant tout par défaut sur les ForceWare 65, le mode « Quality » est utilisé, les optimisations sur le trilinéaire et sur les samples d’anisotropie sont activées, alors que celle sur le filtrage du mipmap est désactivée. Cela fait donc une optimisation de plus que sur les 61.77 où seule l’optimisation sur le trilinéaire était activée.

La différence en pratique ? La voici :

Visuellement, le rendu par défaut des GeForce 6 sur 65.76 est donc identique au rendu sur 61.77, malgré l’optimisation supplémentaire sur les samples d’anisotropie.

Or dans le même temps, le rendu est également similaire entre X600 XT et X800 XT puisque les Radeon 9600 Pro ont inaugurés la fameuse optimisation sur le filtrage trilinéaire introduite en douce. Du coup, nous avons pensé qu’il serait plus intéressant de revenir dans un premier temps sur la comparaison entre le rendu des GeForce 6 et celui de la GeForce 5900 XT, puisque nous avons déjà comparé la qualité d’image entre GeForce 6 et X800 dans notre dernier comparatif.

Il est à noter que pour une raison inconnue les ForceWare 65.76 refusent de s’installer sur PCX 5900. Nous avons donc utilisé les ForceWare 61.77, sur celle-ci, ce qui ne change très probablement rien.

La encore, nous appliquons via les drivers un filtrage anisotropique 8X sur Serious Sam : Second Contact. Le premier screenshot correspond au rendu sur GeForce 6 en mode par défaut (“Quality”), c’est-à-dire avec les deux optimisations que nous avons vues plus haut. Le deuxième correspond au rendu sur GeForce 6 en mode “High Quality », c’est-à-dire toutes optimisations désactivées. Enfin, le dernier correspond à un rendu sur PCX 5900 en mode par défaut, mais qui est parfaitement identique au mode “High Quality”.

Deux choses ressortent de ces trois captures.

• La différence sur GeForce 6 entre le rendu par défaut et le rendu sans optimisation est très faible mais visible.

Les GeForce 6 produisent un filtrage anisotropique bien plus mauvais que les GeForce 5900.

Ce dernier constat n’est pas vraiment une surprise, mais peut-être est-il plus flagrant sur ce screenshot : concrètement, la qualité du filtrage baisse de plus en plus, et cela est navrant. Ici il est clair qu’il tient de l’abus de langage de nommer le filtrage des GeForce 6 « filtrage anisotropique 8X », et la situation est la même sur X600/X800. Quelles différences cela génère-t’il dans les jeux ? Nous le verrons sur les captures d’écran.

Une chose est sure en revanche : la comparaison de performance avec la PCX 5900 va être biaisée puisque celle-ci effectuera un bien meilleur filtrage anisotropique. Toutefois, ce fait est contrebalancé par la mauvaise qualité de l’antialiasing de cette carte.

Une dernière chose est à noter : selon nVidia, les optimisations sur le filtrage anisotropique ne sont tout simplement pas implémentées en OpenGL, de sorte que ces optimisations ne sont donc activables que sur les jeux DirectX Graphics.

AntiAliasing

Il existe plusieurs façons de voir l’antialiasing ; une d’entre elles consiste à le considérer comme une méthode permettant de représenter des vecteurs parfaits et continus sur un périphérique d’affichage imparfait et techniquement limité. A la base, les jeux utilisent pour représenter la réalité des formes géométriques ayant comme primitive les triangles. Ceux-ci, en tant que figure géométrique, sont donc lisses et parfaitement continus. Par contre, un moniteur possède une caractéristique essentielle : il affiche les images en utilisant une grille, qui représente en fait la résolution. Celle-ci est limitée à un certain nombre de pixels; dès lors, elle ne peut afficher qu’un nombre fini de nuances au niveau des courbes ou des vecteurs non parallèles avec les bords de l’écran. C’est alors qu’un effet d’escalier apparaît, mettant clairement en évidence les limitations de l’écran pour se rapprocher d’un rendu réaliste.

Une solution pour diminuer cet effet consiste à augmenter la résolution de l’écran dans les options des jeux. Le seul problème est qu’aujourd’hui, la puissance des cartes graphiques augmente bien plus rapidement que les capacités des écrans, et que rares sont ceux pouvant dépasser le 1600 x 1200, voir le 1920 x 1440 (sans même parler de la fréquence de rafraîchissement, si importante pour éviter la fatigue visuelle). Evidemment, ce problème est amplifié avec les écrans TFT, calibrés pour une seule résolution et qui doivent réaliser une interpolation des pixels (pas toujours réussie, il faut bien l’avouer) pour afficher une résolution supérieure. La résolution de base des TFT est généralement de 1280×1024 pour les 17″. Or on constate aujourd’hui que l’œil humain est capable de distinguer les effets d’escaliers jusqu’à une résolution de 4000×4000, voir au-delà.

L’antialiasing est donc plus précisément une technique permettant de diminuer les effets d’escalier sans modifier la résolution de l’écran. Il fut inventé par le Media Lab du Massachusetts Institute of Technology (MIT), et il est à noter qu’il ne se limite pas à l’image puisque dans le domaine du son, l’aliasing est un phénomène qui est éliminé en supprimant les fréquences situées au-delà de la moitié des fréquences de sampling.

Restait à connaître l’impact concret de l’activation de l’antialiasing tel que géré actuellement, sur les jeux. Pour ce faire, nous nous sommes placés devant une arche sur Serious Sam : Second Contact, et nous avons comparé les effets d’escaliers obtenus en montant la résolution d’une part, puis en restant en 1024×768 mais en augmentant l’antialiasing d’autre part. L’antialiasing utilisé était celui des cartes ATI de génération R3X0/R420 (voir détails plus bas).

Note : attention à ne pas se focaliser sur l’effet d’escalier visible au niveau du reflet du ciel sur l’arche. En effet, seul l’augmentation de la résolution peut améliorer ceci, l’antialiasing n’intervenant que sur les extrémités de l’arche.

• Le 1024*768 antialiasing 2X est environ équivalent au 1280*960. Cela dépend en grande partie de l’angle observé, et même si le 1280*960 est plus régulier sur l’ensemble, les deux modes sont à peu près équivalents sur les angles importants.

• Le 1024*768 antialiasing 4X est globalement équivalent au 1600*1200. Il lui est supérieur sur les angles très proches de l’horizontale ou de la verticale, mais légèrement inférieur sur les autres.

• Le 1024*768 antialiasing 6X est environ équivalent au 1920*1440. Là encore il est possible de distinguer un vainqueur suivant les situations, et même si la version « antialiasée » est plus efficace dans les cas visuellement importants, le 1920*1440 conserve un petit avantage dans d’autres situations.

nVidia vs nVidia

La GeForce 6600 produit le même antialiasing que les GeForce 6800, tout comme ATI utilise le même algorithme depuis les R3X0. Là encore, nous allons donc regarder plus précisément les différences entre l’ancienne et la nouvelle génération nVidia.

Lorsque l’on active l’antialiasing 2X, les choses n’ont absolument pas changées, puisque déjà les GeForce 5900 appliquaient un Rotated Grid Multi-Sampling. Voici la position des samples…

…et le résultat en pratique :

En ce qui concerne l’antialiasing 4X par contre, des différences existent. Pour une raison obscure, les NV3X appliquent en effet un antialiasing 4X de type de ‘Ordered Grid’, alors que les NV4X restent sur un antialiasing RGMS.

Position des samples :

Résultat :

Ici, les 5900 produisent un meilleur antialiasing sur les angles aux alentours de 45° et 135°, mais les 6600 gardent l’avantage quand on se rapproche de 0° et de 90°. Il est donc difficile de désigner un vainqueur absolu, même si en pratique on constate un meilleur résultat avec le RGMS (GeForce 6600 donc).

Ceux qui n’ont pas compris un traitre mot des deux dernières pages pourront s’en remettre aux screenshots fournis pour chaque jeu afin de se faire leur propre idée.

Le test

Le GeForce 6600 étant une puce PCI Express native et la version AGP ne devant arriver que dans quelques mois, nous avons utilisé une plateforme appropriée.

• Pentium 4 EE 3.4 GHz

D925XCV (i925)

Corsair XMS2-5400 (2 x 512 Mo DDR2)

Seagate 7200.7 200 Go

Concernant les drivers, nous avons donc utilisé les Forceware 65.76 sur GeForce 6600 et GeForce 6800, et les Forceware 61.77 sur PCX 5900 (65.76 non compatibles), et les Catalyst 4.9 beta sur Radeon X600XT. En effet, nous avons rencontré un bug avec les Catalyst 4.8 qui rendait aléatoire l’activation de l’antialiasing et de l’anisotropie via le panneau de contrôle.

Concernant la section « Test pratiques », nous avons bien sûr repris notre protocole de test privilégiant le gameplay à la charge graphique, comme expliqué plus tôt. Nous avons cependant opéré plusieurs changements, parmi lesquels la suppression de C&C Generals et Warcraft III : Frozen Throne. Celle-ci s’est faite à regret, particulièrement pour ce dernier qui est encore largement d’actualité sur Internet, mais les options graphiques qu’il faut pousser afin de ne plus être limité par le CPU restent considérables. Nous pensons donc que ces jeux ne doivent pas faire partie des critères de choix d’une nouvelle carte graphique.

En ce qui concerne la résolution de test, nVidia préconise le 1600 x 1200 antialiasing 4X + anisotropie 8X pour la 6600 GT. Evidemment, cette résolution est mise en avant afin d’amplifier les écarts avec la génération précédente. Nous avons cependant opté pour une autre approche, consistant à définir pour chaque jeu la résolution et le niveau d’antialiasing/anisotropie maximum pour conserver une fluidité acceptable sur 6600 GT. Nous n’avons ainsi que rarement pu atteindre la résolution conseillée.

Les screenshots pour chaque jeu ont été réalisés en 1024*768 dans le but de faciliter la comparaison pour ceux qui n’ont pas un bureau en 1600×1200. Le niveau d’antialiasing et d’anisotropie appliqué était le même que celui utilisé pour mesurer les performances.

Dernier changement par rapport à notre précédent protocole, nous avons cette fois-ci choisi d’activer l’antialiasing et l’anisotropie au sein même du jeu, lorsque cela était possible, et via les drivers le cas échéant. Ce choix a ses avantages et ses inconvénients suivant le point de vue selon lequel on se place, mais la nature de l’antialiasing multisampling implique que certains jeux doivent « savoir » si cet antialiasing a été activé afin de le gérer proprement. Par ailleurs, les joueurs ont plus tendance à activer ces effets dans le jeu que via les drivers quand ils ont le choix. Concernant l’anisotropie, cela permet également de privilégier la qualité dans certains cas.

Performances synthétiques

Malgré la suppression de deux quads, la GeForce 6600 GT conserve un fillrate de 4000 MPixels soit environ 71 % de celui de la 6800 GT, du fait d’une fréquence de 500 MHz. Ce fait couplé à l’augmentation de l’efficacité des pipelines font que la 6600 GT dispose de bien plus de puissance qu’on pourrait le croire en pensant au raccourci 6800 GT = 16 pipes et 6600 GT = 8 pipes.

La chose qui saute aux yeux à la vue de ce tableau, et qui en fait la principale caractéristique du GeForce 6600 GT, c’est son ratio fillrate/bande passante mémoire démesuré, a priori le plus élevé jamais atteint sur un chip grand public puisque la X800 XT reste à 232. Nous en avons déjà parlé, mais cela confirme encore une fois que la puissance de ce GPU est très importante comparativement à la bande passante mémoire de 16 Go/s (et à la quantité de mémoire d’ailleurs, qui n’est que de 128 Mo). Cette bande passante semble donc être le point faible de ce GPU, puisque moitié moindre que celle de la 6800 GT, du fait d’une largeur de bus de 128 bits.

Nous nous devons d’expliquer dès à présent l’existence dans ce tableau de la GeForce 5900 XT, une carte AGP. En réalité, l’équivalent de cette carte au niveau PCI Express est la PCX 5900. Le problème, c’est qu’au niveau des fréquences, rien n’est figé. nVidia préconise ainsi la fréquence minimum de 350/275. En pratique, certains constructeurs respectent ces spécifications, mais d’autres vont beaucoup plus loin puisque notre carte Asus finale était cadencée à 377/351. Après avoir beaucoup hésité nous avons donc choisit de cadencer cette carte à 390/350 afin de représenter les performances d’une 5900 XT, une carte qui posséda un rapport performances/prix pas inintéressant.

Les choses auraient été plus simples si nVidia définissait les mêmes fréquences pour les version AGP et PCI Express. En pratique ce n’es pas le cas, et pour donner un autre exemple la fréquence GPU minimale des 6800 Ultra AGP est de 400 MHz, alors qu’elle est de 425 MHz pour la 6800 Ultra PCI Express. Le but ? Favoriser cette nouvelle plateforme. D’ailleurs, rien ne dit que cela ne sera pas également le cas sur les versions finales des 6600 GT.

Fillrate

Surprise ! Si la X600 XT et la 6800 GT ont bien un fillrate pratique proche du fillrate théorique, ce n’est pas le cas de la 6600 GT et de la 5900 XT. Pour la 6600 GT, c’est une conséquence directe de la présence de seulement 4 ROP, qui fait que la 6600 GT se comporte dans ce test comme si elle ne possédait que 4 pipes. D’où un fillrate divisé par deux. Par contre, le fait que la 5900 XT ait ici un débit moitié moindre que son fillrate théorique de 1560 MPixels n’a pas d’explication, et provient soit d’un bug du benchmark, soit d’un bug des drivers.

Ici, on retrouve sur les GPU nVidia la possibilité de doubler le fillrate lorsque les écritures dans le color buffer sont désactivées, comme avons vu. On double donc le fillrate pur sur les 6600/6800, alors que la X600 XT conserve son fillrate. La 5900 XT n’échappe pas à la règle et ne fait que doubler son fillrate pur, ce qui prouve bien que le résultat observé plus haut provient bien d’un bug.

Attention à ne pas se tromper ici. La 6800 GT présente le résultat logique de son architecture, c’est-à-dire un fillrate qui double en passant du dual texturing au single texturing (architecture 16 x 1). En revanche, sur 5900 XT on voir que le fillrate est équivalent dans les deux cas : ceci est due à son architecture 4 x 2, qui fait qu’il ne lui est pas plus coûteux d’appliquer une seule ou deux textures par cycle.

En regardant les résultats du GeForce 6600 GT, on pourrait croire que l’on est exactement dans la même situation est que celle-ci ne possède pas 8 pipes mais 4, et non pas 1 unité de texture sampling mais deux. Rappelez vous ce que nous avons vu sur l’architecture de la 6600 GT : nous sommes ici dans le cas précis où la 6600 GT se comporte effectivement comme un chip 4×2 ! A moins que nVidia nous mente et que ce GPU ne soit bien munie que de 4 pipes ? C’est ce que nous allons voir plus loin.

En ce qui concerne la X600 XT, on observe un gros tassement des résultats dès le dual texturing. Ceci provient probablement d’une bande passante un peu trop limitée, c’est d’ailleurs un peu décevant.

Pixel Shaders

Décidément, nous allons de surprises en surprises ! Commençons par regarder ce qui se passe sur GeForce 6. En fait, ce graphe représente à lui seul 5 mois dévolution des drivers. Initialement, seuls les shaders 2.0 standards pouvaient être exécutés en deux cycles, et tous les autres shaders en nécessitaient trois. Avec les 61.77, notre dernier test avait montré que les PS 1.4 étaient également exécutés en deux cycles. Il semble qu’aujourd’hui nVidia parvienne enfin à maîtriser son architecture avec les ForceWare 65.76, puisque désormais tous les shaders de ce test sont exécutés à la même vitesse. Certes, c’est le cas chez ATI depuis la première apparition de l’architecture R420, mais c’est un peu logique puisque celle-ci reprend en grande partie l’architecture R3X0. Voilà donc une excellente nouvelle.

Ici, les résultats de la 6600 GT sont sans équivoque : nous sommes bien en présence d’un GPU doté de 8 pipes !

Concernant la 5900, ce test ne fait que rappeler une conséquence bien connue de son architecture : sa faiblesse en PS 2.0 (4 cycles au lieu de 2 sur ce test), qui ne peut-être compensée qu’en ayant recours à la précision partielle.

Ces résultats étaient plus prévisibles, et mettent en avant une spécificité des GeForce 6, que l’on retrouve donc sur la 6600 GT : le gain de performance en exécutant un éclairage par pixel en précision partielle, à l’instar de ce que réalise la 5900 XT, comparativement à la pleine précision.

Bilan

Avec les Forceware 65.76, la puissance des NV4X en pixel shaders est enfin domptée. La 6600 GT possède ici une puissance brute environ deux fois supérieure à la X600 XT, et environ trois fois supérieure à celle de la 5900 XT.

Vertex Shaders

Ici, le résultat souligne bien le fait qu’au niveau des Vertex Shaders, les performances des NV4X sont assez directement empreintes de celles des NV3X. Le T&L reste émulé très rapidement, mais cela n’aura pas vraiment de conséquence sur les jeux récents. Les VS 2.0 reste cependant en retrait par rapport au VS 1.X. Contrairement à ce que l’on observait auparavant sur pixels shaders, ceci ne provient pas des drivers mais bel et bien de l’architecture. Ce point a par ailleurs bien été amélioré par rapport à la 5900 XT. Au final les performances de la GeForce 6600 GT varient entre 70 % et 80 % de celles de la GeForce 6800 GT.

Bilan

Ici les gains sont moins impressionnants, et pour cause : la 6600 GT comme la 5900 XT dispose de 3 unités de Vertex. La 6600 GT est légèrement moins performante que la 5900 XT en T&L et en VS 1.1, mais environ deux fois supérieure au niveau des VS 2.0. Elle devance également assez facilement la X600 XT.

PCI Express : vitesse de lecture du frame buffer

Une des spécificités de la GeForce 6600, est donc d’être une puce PCI Express native, qui utilisera par la suite le HSI pour être disponible en version AGP. Pour mémoire, la principale caractéristique du PCI Express est d’être un port série, point à point, qui autorise des échanges full duplex, c’est-à-dire du GPU vers le chipset en même temps que du chipset vers le GPU. Cette différence pourrait paraître bénigne, mais elle ne l’est pas. J’en veux pour preuve Dany Lepage, Lead Programmer sur Splinter Cell (Ubisoft Montreal), qui dit les choses suivantes :

« A mon avis, le PCI Express aura un impact majeur sur la façon dont les jeux sont conçus car on pourra enfin accéder à la mémoire graphique sans interrompre les flux d’échanges entre le core logic et le GPU. […] Ceci devrait rendre possible l’utilisation d’une nouvelle série d’algorithmes (comme sur consoles). On pourra utiliser le GPU pour calculer très rapidement les zones de danger quand le joueur envoie une grenade (‘physic blast shadowing’). L’information pourrait ensuite être transmise au moteur d’intelligence artificielle et de physique afin d’aider l’IA à prendre la bonne décision sur la réaction à adopter face à cet évènement, et trouver quels objets devraient subir l’explosion (où et comment). […] Au final, le PCI Express n’aura pas un impact direct sur le rendu, mais il aura un gros impact sur la manière dont le moteur est conçu (seuls les programmeurs le remarqueront, mais les jeux vont s’améliorer plus rapidement). Tout ceci peut être fait par le CPU mais les programmeurs vont commencer à faire autre chose que du graphisme avec les GPU. Tout ceci vient du PCI Express. »

Nous avons donc exécuté un test de vitesse de lecture du frame buffer (mémoire graphique) pour voir ce qu’il en retournait entre les solutions PCI Express natives ou non.

La carte qui se détache clairement du lot est bien la GeForce 6600 GT. Surprise, on retrouve derrière elle la PCX 5900 qui utilise pourtant le HSI, à même le PCB de la carte. Celle-ci parvient à saturer l’interface qu’elle utilise, qui n’est autre que l’interface PCI (double vitesse), soit 266 Mo/s au maximum.

En troisième position, la X600 XT qui est pourtant la seconde carte de ce comparatif à être native PCI Express ! On peut donc se questionner sur l’intérêt de ceci, ou plutôt sur l’efficacité de l’implémentation vu les performances obtenues sur ce test.

Enfin, on trouve la GeForce 6800 GT. Ce résultat est encore une fois très surprenant. En effet, il faut savoir que la 6800 est la première carte de chez nVidia à dédier une partie de son hardware pour gérer le transfert remontant en mode AGP. C’est un énorme progrès par rapport au PCI mais on reste encore loin du débit théorique offert par l’AGP 8x. Ici, les performances sont pourries. Première hypothèse : cela provient du HSI. Mais cela est difficilement concevable puisque la 5900 XT, qui utilise ce même HSI, dispose de bien meilleures performances. Et surtout, les performances de la 5900 AGP sont proches de celles de la 5900 PCI Express. Ce n’est pas le cas de la 6800, qui est bien plus rapide en… AGP ! Notre avis est donc que les drivers pour les versions PCI Express ne sont peut être pas au point, ou bien que le NV45 ne dispose pas du hardware spécifique pour gérer les lecture AGP contrairement au NV40.

Ce qui est très clair aussi, c’est que la gestion du PCI Express des puces nVidia est très décevante, indépendamment de tout le marketing qu’il peut y avoir autour. Même la 6600 avec son support natif dispose de débits plus faibles que la 6800 Ultra AGP, qui elle parvient à atteindre les 600 Mo/s.

Au final, ces résultats restent donc assez faibles. Le débit maximum que nous mesurons ici reste de 410 Mo/s, alors que la limite théorique est située à 4 Go/s ! Bref, nous ne sommes pas encore au niveau du saut dont parle Dany Lepage…

HSR, Overdraw, Procedural Texturing

Voyons maintenant le test HSR. Pour rappel, le Hidden Surface Removal est une fonctionnalité visant à économiser des cycles GPU en ne lui faisant pas effectuer le rendu des pixels qui seront cachés par d’autres pixels au premier plan.

Les drivers ont encore améliorés les choses du côté des GeForce 6. La supériorité de la 6600 GT sur la 5900 XT n’est toutefois pas flagrante.

Observons maintenant ce qui se passe en ce qui concerne la gestion de l’overdraw, avec VillageMark. VillageMark est une démonstration technologique mise au point par PowerVR afin de mettre en avant l’efficacité du Tile Rendering propres aux GPU PowerVR en la matière. Pourquoi plaçons nous ce test après le test HSR ? Parce que l’overdraw représente le nombre de fois où un même pixel va être écrit dans le frame buffer, là où le HSR mesure la faculté de rejeter ces pixels avant de les écrire dans le frame buffer. Plus le HSR est efficace, plus il permet de limiter l’overdraw, vu qu’il rejettera les pixels plus tôt dans le pipe et donc ne les écrira pas dans le frame buffer.

Visiblement, ce test ne semble pas trop apprécier le PCI Express. On note encore une grosse différence entre les performances du 6600 GT et du 6800 GT.

En OpenGL, les performances des GeForce 6 sont en augmentation, ce qui semble encore une fois provenir du travail effectué sur les drivers. Par contre, la 5900 XT est en baisse.

Enfin, étudions les résultats dans des tests procéduraux.

Pas de soucis pour la 6600 GT qui conserve bien son avantage lié à ses 2 unités ALU.

Antialiasing, filtrage anisotropique

Après avoir vu l’aspect qualitatif dans les sections dédiées, nous nous sommes ici attachés à observer la contrepartie quantitative que provoquait l’activation de l’antialiasing et du filtrage anisotropique sur chacune des cartes. Pour ce faire, nous avons ramené à 100 % la performance de chaque carte hors AA + aniso. La scène de test est la Vallée du Jaguar de Serious Sam : Second Contact, et la résolution a cette fois été fixée à 1280 x 1024 (pas de limitation due à 128 Mo de mémoire). Ici, l’antialiasing et l’anisotropie étaient activés par les drivers, comme tous les jeux ne supportant pas d’eux même ces effets.

Ici, les résultats de la GeForce 6600 GT restent similaires à ceux de la 6800 GT, ce qui tendrait à prouver que la bande passante mémoire divisée par deux n’est pas vraiment un problème du point de vue de l’antialiasing. En fait, ce qui ressort clairement c’est le faible surcoût de performance entre antialiasing 2X et 4X. Dans le cas du GeForce 5900, ces résultats semblent nous permettre d’affirmer que l’OGMS (antialiasing 4X) est moins coûteux que le RGMS (antialiasing 2X). Dans tous les cas, l’antialiasing ne semble donc pas s’exécuter plus rapidement sur GeForce 6 que sur GeForce 5900.

Les résultats que l’on obtient ici sont extrêmement intéressants. Première chose : la GeForce 6600 GT. Elle devient la première carte de milieu de gamme à permettre une activation « gratuite » du filtrage anisotropique ! Et finalement, c’est assez logique : le filtrage anisotropique est définitivement plus gourmand en ressource GPU qu’en bande passante mémoire, ce qui va complètement dans le sens de la 6600 GT.

En regardant les chiffres de la GeForce 5900 XT, on comprend mieux pourquoi nVidia a changé de filtrage. Le filtrage qu’effectue cette carte est 5 fois plus coûteux que celui des GeForce 6 ! Il semble donc que l’écart en terme de vitesse d’exécution soit largement aussi important que celui en terme de qualité visuelle. La X600XT reste supérieure à la 5900 XT en terme de moindre perte de performance, mais malgré son fameux filtrage, l’impact reste important du fait d’un fillrate somme toute limité.

Au final, et contrairement à ce qui se passe avec des GPU haut de gamme, les différences entre chaque carte lors de l’activation de l’anistropie et de l’antialiasing proviennent principalement des différences relevées sur l’anisotropie ! Sur ce secteur, on comprend donc mieux pourquoi chaque constructeur essaye de rogner sur la qualité du filtrage des textures.

Tests pratiques

Ground Control 2

Le premier Ground Control reste selon nous une référence absolue et un des rares jeux à vraiment mériter l’intitulé « jeu de stratégie ». Malheureusement, la déception fut grande en découvrant que la suite du jeu phare de Massive n’atteignait pas cette dimension, du fait de l’arrivée de ravitaillements et d’un nombre d’unités beaucoup plus élevé. Mais on ne peut nier que Ground Control 2 reste un bon jeu, qui bien qu’assez classique est servi par un moteur 3D de très, très grande classe, supportant les Pixel Shaders 2.0.

Preuve que le moteur de ce jeu est excellent, nous avons ici pu pousser la résolution en 1600 x 1200 et même activer un antialiasing tout en bénéficiant d’un affichage fluide sur GeForce 6600 GT. Les cartes de génération précédente sont alors larguée et, petite surprise, la 5900 XT devance légèrement la X600 XT dans ce jeu DirectX 9.0.

Ici, le rendu de la 5900 XT est indissociable de celui de la 6600 GT, que ce soit sans AA + aniso…

… qu’avec.

Les 5900 XT utilisent probablement un path allégé au niveau de la précision des shaders 2.0, mais cela n’est pas visible sur ce screenshot ni sur notre scène de test.

Painkiller

Dans la catégorie des ‘First Person Shooter’ défoulant et notoirement gores, Painkiller se pose là. Comme toujours, son style ne plaira pas à tout le monde mais les amateurs du genre ne pourront passer à côté de ce jeu bien réalisé, et au moteur 3D sympathique. Nous avons ici changé de scène de test afin d’observer le framerate en plein combat.

Le résultat est assez similaire à ce que nous avons vu précédemment. Encore une fois, vu la résolution permise ici la 6600 GT est clairement limitée par ses 128 Mo de mémoire lors de l’activation de l’antialiasing, et on espère donc qu’une version 256 Mo verra le jour !

Curieusement ici, le filtrage anisotropique paraît de meilleure qualité sur 6600 !

Xpand Rally

Xpand Rally s’annonce clairement comme la nouvelle référence des jeux de rally. Graphiquement, c’est la claque avec notamment un ciel superbe et le support du Glow qui rajoute indéniablement au réalisme. Evidemment, toutes les étapes de Rallie n’ont pas forcément une végétation très riches mais quand c’est le cas, le rendu est superbe. La Chrome Engine 2004 assure en outre la gestion des lightmaps, et de l’éclairage par pixel et par vertex. Plus important, le gameplay du jeu est correctement ajusté pour une simulation, et le moteur physique fait bien son travail.

Ici, nous avons eut plus de problèmes à obtenir un affichage fluide en 1280*1024, puisque ce type de jeu réclame indéniablement un framerate élevé. Nous avons donc été contraint de désactiver le Glow, trop gourmand en ressources. Nous avons également changé de scène de test par rapport à notre précédent comparatif.

Les résultats sont plus serrés ici. A noter que malgré l’activation de l’anisotropie dans le jeu, le filtrage des textures semblait exempt de tout amélioration.

A noter un bug de filtrage sur le panneau du chronomètre (à droite de la piste) sur 6600 GT.

Splinter Cell : Pandora Tomorrow

Passons maintenant à l’infiltration avec l’excellentissime Splinter Cell : Pandora Tomorrow, la suite logique et sans surprise du premier opus. On retrouve donc le Unreal Warfare adapté afin de gérer au mieux les ombres et la luminosité ambiante, et le moins que le puisse dire est que le résultat est une réussite. A noter que de par sa technologie, ce jeu ne supporte pas l’antialiasing.

Les chiffres peuvent paraître un peu bas mais Splinter Cell est tout à fait jouable sur 6600 GT à cette résolution.

Par défaut, le rendu est identique entre l’ancienne et la nouvelle génération. A noter que sur ce jeu, forcer l’anisotropie 8X via les drivers dégrade la qualité des textures ! On le remarque notamment sur les planches en bois au second plan. Nous vous déconseillons donc d’activer le filtrage anisotropique dans ce jeu.

Far Cry

Far Cry, deuxième épisode. Suite à quelques problèmes rencontrés la dernière fois (et que nous avions clairement explicité dans cette section d’ailleurs), nous avons activé l’antialiasing et le filtrage anisotropique via le jeu, bien qu’en 1280*1024 nous n’aurions pas rencontré de problème en passant par les drivers.

Conformément à ce que nous vous expliquions, le patch 1.2 n’est toujours pas disponible de manière officielle, Ubisoft et Crytek ayant retirés ce patch (nous avons-nous même rencontrés des problèmes avec). Nous en sommes donc restés au patch 1.1. Problème : avec ce patch, les GeForce 6 utilisent un path ayant recours à des shaders en précision partielle, provoquant ainsi un rendu de moins bonne qualité. Pour le coup, la comparaison entre 5900 XT et 6600 GT va donc être des plus équitables, au contraire de la comparaison avec X600 XT. Nous avons cependant réalisé quelques tests de performances en forçant le path des R3X0/R4X0 (non allégé) sur GeForce 6 : la perte de performance est de l’ordre de 9 %. Ce chiffre ne vous est pourtant fourni qu’à titre indicatif, et les performances mentionnées ci-dessous sur GeForce 6 correspondent bien au path allégé. Ainsi, nous pensons représenter au mieux les performances de chaque carte en situation réelle chez les joueurs, car nous doutons que ces derniers utilisent en majorité 3DAnalyser pour forcer un meilleur rendu. Effectivement, ce test désaventage donc les X600 XT qui calculent un meilleur rendu.

La 6600 GT survole encore largement le milieu de gamme actuel, et on note que malgré son meilleur rendu, la X600 XT surpasse néanmoins la 5900 XT. Rappelons d’ailleurs que la vraie concurrente de la X600 XT est plutôt censée être la 5700 Ultra…

Ici, nous sommes moins limité par le CPU et les écarts se creusent : les GeForce 6 dominent encore plus dans ce type de scène, avec une charge plus importante au niveau des ombres et de l’éclairage par pixel.

Dans les deux cas, le rendu est parfaitement similaire, et force est de constater que le meilleur filtrage anisotropique du GeForce 5900 n’est pas visible ici.

Tests pratiques (suite)

Doom 3

Après de longues années de développement (presque 4), Doom 3 est enfin sortit. Au final, le résultat est mitigé. D’un côté, le jeu accuse une linéarité affligeante du gameplay et des scripts, et se révèle plus irritant qu’effrayant à la longue. De l’autre, l’expérience de jeu et l’atmosphère qu’est arrivé à recréer ID Software est tout simplement époustouflante, et le jeu exploite avec brio toutes les possibilités techniques pour recréer un univers hostile. Un test synthétise exactement notre point de vue sur Doom 3 : celui de Firingsquad. Le jeu multijoueur est un peu bâclé, mais dans la mesure où certains serveurs ont déjà trouvés le moyen d’outrepasser la limite de 4 joueurs et que l’activité des « moddeurs » ne faiblira pas, le succès à long terme du jeu ne fait pas trop de doute, d’où sa présence dans notre protocole.

Techniquement, nous avons déjà consacré un article entier à Doom 3.

Malgré la résolution et le niveau de détail (1280*1024 Medium Quality), l’activation de l’antialiasing provoque un grosse perte de performances sur 6600 GT, qui est là encore limitée par ses 128 Mo de mémoire. Pour le reste, cette carte se montre deux fois plus performante que la 5900 XT.

Ici le filtrage trilinéaire de la 5900 XT est visiblement meilleur que celui de la 6600 GT.

Les choses se compliquent lorsque l’on veut activer le filtrage anisotropique sur Doom 3. En effet il n’existe pas de réglage séparé dans ce jeu, de sorte que cela serait revenu à activer le mode Very High Quality. Bien sûr, il était hors de question d’activer ce mode prévu pour les cartes dotées de 512 Mo de mémoire ! Du coup nous l’avons activé via les drivers, ce qui produit un résultat très moyen.

MAJ : En fait, les drivers 65.76 ignorent les réglages du filtrage anisotropique sur Doom 3 ! Les GeForce 6 ont donc simplement calculés sur ce test un filtrage trilinéaire optimisé, ce qui revient à un filtrage trilinéaire au niveau 1, puis à un bilinéaire sur les niveaux supérieurs (d’où ce résultat immonde sur le sol). Alors que les 5900 XT ont elles calculées un filtrage anisotropique 8X non optimisé… Merci nVidia d’avoir implémenté ce profil de désactivation sur Doom 3, c’est vraiment un bonheur de faire des tests dans ces conditions !

Source Engine Stress Test

Ce test est issu du moteur de Half Life 2, le Source Engine. S’il ne représente pas le framerate réel de Half Life 2, il donne ne revanche une bonne indication du comportement des GPU sur ce moteur, avec un scène qui se présente sous la forme d’une démonstration technologique (HDR, etc.). Rappelons également que ce moteur est déjà utilisé dans un jeu qui marche plutôt fort en réseau : Counter Strike : Source, bien qu’il faille avoir recours à des effets avancés afin de mettre les GPU à mal avec ce jeu. D’où le recours à ce stress test et non à une scène de gameplay (impossible à reproduire avec précision en l’état, d’ailleurs).

La GeForce 6600 GT est plus de trois fois supérieure à la carte qu’elle remplace. La 5900 XT a vraiment des performances apathiques ici, et l’on comprend mieux maintenant pourquoi Valve forcera le path DirectX 8 sur NV3X avec Half Life 2 ! D’ailleurs, nous avons identifié plusieurs bugs de rendu avec la GeForce 5900, au niveau de la transparence de l’eau notamment.

Par défaut, le rendu est légèrement meilleur sur 5900 XT, grâce encore une fois au filtrage des textures.

Avec anisotropie 8X, tout dépend de l’endroit où l’on regarde, mais globalement la 5900 XT conserve l’avantage au niveau des textures. En revanche, la 6600 GT produit un antialiasing de meilleur qualité ici.

Lock On

Dans la catégorie simulateur d’avions de chasse moderne, Lock On est incontestablement le leader actuel, et le digne successeur du mythique Super EuroFighter 2000 de DiD, et de Falcon 4.0. Techniquement, ce jeu est également bien supérieur à IL-2, avec des couleurs plus réalistes et des textures bien plus détaillées.

L’objectif était donc de tester la réaction de ce jeu face aux différentes cartes. Nous avons enregistré un nouvelle scène de test, et surtout nous somme avons calées les options graphiques au niveau « Moyen », ce qui améliore bien les choses au niveau de la bride par le CPU.

Au niveau du match X600/5900XT, cette dernière l’emporte d’une courte tête. La GeForce 6600 GT reste toujours inatteignable. Notez que nous sommes resté à l’antialiasing 2X, car l’activation de l’antialiasing 4X provoquait une grosse chute de performance sur 6600 GT (24,3 fps), toujours limitée par ses 128 Mo.

La texture du fuselage de l’avion est un peu plus contrastée sur 5900 XT. Notez que l’ombre portée de l’avion sur les missiles a disparue, mais ceci semble du au passage en « Medium Quality ».

Là encore, l’avantage est au 5900 XT pour la texture de l’avion. Au niveau de l’antialiasing, c’est à peu près équivalent.

Tests Vidéo

Nous avons effectué à nouveau des tests concernant ce fameux moteur de compression/décompression. En ce qui concerne les fonctions de compression, rien n’est encore possible pour le moment. Il faut attendre qu’un logiciel utilise le DXVA de Microsoft, ce qui n’est pas encore le cas. nVidia précise que plusieurs grands éditeurs de logiciel d’acquisition travaillent en ce moment avec le SDK nVidia, mais 5 mois après la sortie du GeForce 6800 Ultra rien n’est encore là.

Concernant la décompression, nous avons effectué des tests sur DivX et WMV9. Nous avons utilisé Windows Media Play et divX Player. Afin d’augmenter la charge CPU, nous avons désactivé l’Hyperthreading.

En clair, aujourd’hui encore ce moteur video, c’est du flan. Lors de la lecture d’un fichier DivX, il y a bien un gain par rapport à la X600 XT, mais celui-ci s’observe également sur 5900 XT. Quand au WMV9, il n’y absolument aucune décompression matérielle qui est réalisée.

Cartes Asus, overclocking

Concernant les cartes de ce test, deux étaient des cartes finales du commerce signées Asus.

La Extreme N5900 est une carte assez longue, avec un GPU excentré. On devine bien sûr la présence du HSI derrière le gros radiateur, un HSI qui chauffe beaucoup d’ailleurs, tout comme les puces mémoire. Le ventirad du GPU est un modèle assez large, en aluminium. Elle est notamment dotée de fonctions VIVO. On retrouve donc dans son bundle un gros module VIVO, avec entrées et sorties S-VID et composite. Côté logiciels, sont présents Deus Ex 2, GunMetal, Battle Engine Aquila, PowerDirector 3DE, Asus DVD, Medi@Show SE et un CD de démos.

Concernant l’AX600 XT, nous avons droit à une carte plus petite en taille. Son seul problème, c’est d’avoir été visiblement désigné par le département marketing. En effet, du côté du GPU on trouve un gros radiateur qui englobe à la fois le GPU et les puces mémoire, avec un ventilateur excentré par rapport au GPU. Il est en aluminium et doté d’ailettes qui s’ouvrent d’abord en corolle. Seulement voilà : cette carte dispose de 8 puces mémoires, dont 4 au dos, qui ne bénéficient pas du moindre radiateur. Asus aurait mieux fait de se concentrer sur la dissipation du GPU seul donc. Au passage, les puces mémoires sont des FBGA Hynix 2.2 ns, capables donc de fonctionner à 454 MHz si le PCB suit. On trouve également sur la carte la puce Rage Theater.

Le bundle comprend le gros module VIVO de l’EN5900, mais aussi un inutile câble HDTV. Côté logiciels, sont présents Deux Ex 2, Asus DVD, Medi@Show SE 2.0, PowerDirector 3DE et Cool3D.

Overclocking

Concernant la PCX 5900, les résultats obtenus étaient étranges et les fréquences spécifiées via Coolbits n’étaient pas toujours appliquées. A noter la grosse propension à l’overclocking des cartes de référence chez nVidia (6600 GT, 6800 GT), avec une fréquence respectable de 585 MHz pour la 6600 GT. Ceci indique généralement une bonne marge de sécurité pour nVidia, et donc des yields probablement assez élevés (indispensable sur ce secteur). A noter que les gains observés sous Doom 3 avec les GeForce 6 ne font pas honneurs aux overclocking atteint, tout simplement parce que le CPU limitait.

Nous ne nous sommes pas attardé à départager les cartes sur leur bruit, faute de disposer de toutes les cartes en version finale (d’ailleurs, notre 6600 GT émettait des gémissement à chaque sollicitation 2D/3D). De manière générale elles ne sont pas spécialement bruyantes, en tout cas à côté du ventirad Intel surmontant le P4 EE 3.4 GHz…

Bilan, conclusion

Bilan

Au final, que conclure de toutes nos analyses ? Qu’il faut bien sûr attendre de voir les performances des X700 avant de se prononcer définitivement. Mais indépendamment des performances de celles-ci, ce qui ne changera pas c’est que nVidia nous a sortit avec sa 6600 GT une puce redoutable, qui est en fait une adaptation intelligente de l’architecture NV45 sur le milieu de gamme. Ainsi, les économies inéluctables à l’obtention de cartes bon marché ont été principalement réalisées sur la bande passante mémoire et sur le ROP, au profit d’un puissance GPU faiblement diminuée. Cela est parfaitement en adéquation avec les jeux récents et à venir, et permet d’activer l’antialiasing et surtout le filtrage anisotropique à moindre coût. Par ailleurs, les Forceware 65 semblent enfin délivrer la puissance de cette architecture.

De manière très pratique, la 6600 GT se retrouve donc dans beaucoup de jeux deux fois plus performante que l’ancien milieu de gamme, représenté par les X600 XT et 5900 XT, dans les résolutions jouables sur 6600 GT. Son prix est annoncé à 229 € pour la version 128 Mo, et nous espérons également qu’une version 256 Mo verra le jour. En effet, si cette quantité de mémoire est ridicule sur des puces comme le GeForce 5600, nous avons rencontré plusieurs situations où nous étions ici limités par les 128 Mo.

Un bémol cependant. Nous pensons que l’augmentation des performances vis-à-vis de la génération précédente ne doit pas se faire au détriment de la qualité visuelle. Or, force est de constater que le filtrage anisotropique des GeForce 5X00 reste meilleur que celui des GeForce 6X00 (filtrage anisotropique adaptatif en fonction de l’angle). Certes, le gain que cela permet au niveau des performances est conséquent, et la différence dans les jeux n’est pas flagrante. Mais elle n’est pas inexistante, et nous souhaiterions donc que ceux qui ne veulent aucun compromis sur la qualité puissent revenir à un filtrage non optimisé.

Conclusion

Voilà un test dont le résultat nous surprend ! Mine de rien, cela faisait très longtemps que l’on ne pouvait plus parler d’une puce nVidia n’appartenant pas au haut de gamme, sans mettre l’évolutivité ou au contraire l’efficacité en doute, et accompagner les résultats positifs de mises en gardes diverses. Ce qui nous permet d’affirmer aujourd’hui que la génération de GPU NV4X est un succès pour nVidia, ce n’est pas les performances du haut de gamme, mais bien les performances du milieu de gamme et de cette 6600 GT !

Outre la réaction d’ATI, nous sommes assez curieux de savoir comment nVidia va maintenant renouveler son offre bas de gamme et décliner une nouvelle fois son architecture, mais avec des contraintes plus grandes encore.