HardWare.fr


Nvidia GeForce GF100 : la révolution géométrique ?
Cartes Graphiques
Publié le Lundi 18 Janvier 2010 par Damien Triolet

URL: /articles/782-1/nvidia-geforce-gf100-revolution-geometrique.html


Page 1 - Introduction



A la fin de ce CES 2010, Nvidia a décidé de nous réveiller le dimanche au petit matin pour enfin nous en dire plus sur l’architecture graphique de son futur GPU haut de gamme, alias Fermi ou le GF100. Le travail de journaliste technique est décidément bien difficile mais que ne ferions nous pas pour un apprendre plus sur un nouveau GPU ?


Continuer le hype…
… en attendant le produit. Non, Nvidia ne va pas lancer ni dévoiler ses futures cartes graphiques aujourd’hui. Certes, le fabricant a donné et démontré quelques résultats, mais à la pertinence plutôt limitée. Le but est, comme vous vous en doutez, de dévoiler les détails de l’architecture liés au rendu 3D pour assurer une communication continue sur le GF100 en attendant sa concrétisation, mais également de rassurer en faisant passer quelques messages bien précis.


Premièrement, le graphique est important pour Nvidia et la conception du GF100 avait cet aspect comme priorité. Certains ont pu en douter parce que le fabricant a d’abord dévoilé le côté « compute » de son architecture et l’a fortement mis en avant pour séduire un nouveau marché, parce que la concurrence y a vu une opportunité pour attaquer et parce qu’une partie de la presse a utilisé la polémique pour alimenter des débats sans aucune réflexion. Bien entendu Nvidia ne va pas négliger son marché principal, qu’il soit grand public ou professionnel, pour un pari sur l’explosion d’un nouveau marché. Cela aurait été suicidaire d’autant plus que le design du GF100 a débuté alors que CUDA était toujours en incubation. Attention, cela ne veut pas dire qu’au final l’architecture puisse connaître plus de succès dans un domaine différent de celui qui était la priorité, mais il faut bien garder en tête que celle-ci a toujours été le graphisme.

Pour anticiper les éventuelles critiques qui pourraient malgré tout venir à ce niveau, Nvidia a tenu à insister sur le fait que l’aspect « compute » va devenir de plus en plus important pour le graphique que ce soit directement (post processing) ou indirectement (physique, AI…).

Ensuite Nvidia a voulu marquer la différence entre une nouvelle architecture pour le GF100 contre une simple évolution pour les Radeon HD 5000. Un élément de communication bateau bien entendu puisque la notion de nouvelle architecture et d’évolution est purement subjective en plus de ne représenter que ce dont un fabricant donné avait besoin à un moment donné. Son architecture précédente ayant stagné pendant longtemps, Nvidia était en retard sur certains éléments et avait donc besoin de faire un bond architectural plus important qu’AMD qui avait apporté des améliorations plus régulièrement. Qui plus est, tout cela est cyclique, chacun disposant à tour de rôle d’une architecture vue comme plus évoluée. C’est également un argument dangereux puisque nouvelle architecture a souvent rimé avec faible efficacité. Nous l’avons vu avec le R600 et le NV30. Certes Nvidia a fait mentir tout cela avec le G80 mais globalement il faut du temps pour tirer le maximum d’une nouvelle architecture tant au niveau logiciel que de son implémentation physique.

Nvidia tente d’ailleurs ici aussi d’anticiper les liens négatifs avec le NV30 (GeForce FX 5800) en le réhabilitant en tant qu’évolution importante apportée à la 3D. Si sous certains aspects le NV30 a pu séduire le monde professionnel, nous ne sommes pas dupes, ce n’est qu’une tentative d’éviter des liens négatifs avec la situation actuelle. Le NV30 était une mauvaise implémentation de DirectX 9 qui a forcé Nvidia à mentir lamentablement pour essayer de cacher ses défauts le plus longtemps possible. Plus qu’une évolution importante, le NV30 et ses dérivés ont étés un frein à l’évolution.

Enfin, Nvidia a voulu revenir sur sa relation avec les développeurs et la mauvaise image qu’elle peut parfois avoir. Rien de neuf cependant à ce niveau. Bien entendu le travail de Nvidia auprès des développeurs est important et bénéfique. Nous ne sommes cependant pas dupes ici non plus et bien que Nvidia le nie avec insistance il y a dans certains cas, surtout quand la concurrence dispose de meilleurs produits et qu’il y un partenariat important avec un éditeur de jeux, des débordements regrettables et le non support du MSAA dans Batman sur les Radeon en est un selon nous. Par contre nous comprenons qu’il soit frustrant pour les équipes de développement de Nvidia d’être présentées sous un mauvais jour alors que dans l’énorme majorité des cas elles ne font qu’apporter une aide bénéfique et nécessaire aux développeurs pour que le jeu PC puisse continuer à évoluer.


Si vous suivez depuis des années le petit monde du GPU, vous aurez probablement pu vous faire une idée, en lisant entre les lignes, de ce que le hype continu (une photo par-ci, une petite phrase par-là) et les éléments de communication que Nvidia essaye de mettre en place signifient : le GF100 est en retard et ce n’est pas par ses performances pures dans les jeux actuels qu’il démarrera une révolution. Le lien avec le lancement du GeForce FX est ici évident, mais cela ne veut pas dire que le résultat sera le même. La presse est aujourd’hui bien plus attentive qu’à l’époque et il serait suicidaire de tenter de nous bluffer. Par ailleurs, et toujours contrairement à l’époque, nous avons pu avoir accès directement aux architectes de la puce pour répondre à de nombreuses questions techniques et ainsi pouvoir nous faire une idée relativement précise de l’architecture, des ses points forts mais également de ses points faibles.


Page 2 - Le GF100

Le GF100
Nous ne reviendrons pas en détails sur le côté « compute » de l’architecture, celui-ci ayant déjà été traité en long et en large dans l’article consacré à Fermi, le nom de l’architecture, GF100 étant son implémentation.

Pour rappel, les G8x, G9x et GT2xx étaient basés sur des structures appelées TPCs pour Texture Processing Clusters qui englobaient 2 ou 3 SMs (Streaming Multiprocessors) et un groupe de 8 unités de texturing (avec limitations pour le G80). Le GT200 dispose par exemple de 10 TPCs de 3 SMs qui se partagent 8 unités de texturing. Ces TPCs sont pilotés par un ensemble unique d’unités spécialisées dans la préparation des tâches, le setup des triangles, la rastérisation etc.


Le GF100 est de son côté composé de 4 gros blocs, les GPCs pour Graphics Processing Clusters. Toutes les unités spécialisées se retrouvent cette fois au niveau des GPCs et des SMs. Le GF100 est ainsi le premier GPU à pouvoir traiter plus d’un triangle par cycle ! Nous reviendrons sur ce point. Chaque GPC englobe 4 SMs pour un total de 16 dans le GPU. Un autre changement important prend place avec des unités de texturing qui ne se situent plus au niveau de la structure principale mais bien au niveau du SM. C’est pour ces raisons que Nvidia a dû abandonner le nom TPC au profit de GPC. Chaque SM dispose dans le GF100 de 4 unités de texturing qui lui sont dédiées. Les groupes de SMs ne doivent donc plus se partager des unités de texturing ce qui simplifie le design et permet de gagner en efficacité.

Opter pour des unités de texturing découplées (AMD du R520 au RV670) ou semi-découplées (Nvidia du G80 ou GT200) était sur le papier une idée élégante qui permettait de faire évoluer l’architecture facilement vers un ratio puissance de calcul / puissance de texturing plus élevé, d’isoler une fonction fixe du core programmable et de maximiser le rendement en permettant à toutes les unités d’être utilisées là où le GPU en a besoin. En pratique il s’est cependant avéré que ce gain de rendement n’était pas aussi utile que cela et ne compensait pas la perte d’efficacité due à une complexification du design. AMD est donc revenu en arrière avec les Radeon HD 4000 et Nvidia en fait de même aujourd’hui, ce qui démontre au passage qu’une évolution architecturale peut être contre productive.


Chaque SM est donc composé d’un double scheduler qui peut, à chaque cycle, envoyer une instruction à 2 de ces 5 blocs d’exécution :

- unité SIMD0 16-way (les « cores ») : 16 FMA FP32, 16 ADD INT32, 16 MUL INT32
- unité SIMD1 16-way (les « cores ») : 16 FMA FP32, 16 ADD INT32
- unité SFU quadruple : 4 fonctions spéciales FP32 ou 16 interpolations
- unité Load/Store 16-way 32 bits
- unités de texturing

La latence et le débit de chaque instruction est différent, mais le tout est découplé, ce qui veut dire par exemple qu’une fonction spéciale qui prend plusieurs cycles ne va pas empêcher le scheduler d’envoyer une instruction à un autre bloc d’exécution. A un moment donné ils peuvent donc tous être au travail. Notez que nous laissons ici de côté le FMA FP64 qui utilise les unités SIMD0 et SIMD1 et n’est pas utilisé en rendu graphique.

Notez que la notion de « core » est rendue encore plus complexe avec le GPC. Quelle structure devrait recevoir ce qualificatif ? Le GPC ? Le SM ? Chaque voie d’une unité SIMD ? Nvidia préfère bien entendu cette dernière option et parler de 512 « CUDA Cores ». De notre côté nous penchons plus pour le SM. Un GF100 serait ainsi composé de 16 cores.


Page 3 - Fréquences, architecture mémoire

Fréquences
Une autre différence importante introduite avec le GF100 concerne les domaines de fréquence. Depuis le G80, 3 domaines principaux existent : la fréquence GPU, la fréquence des SMs/schedulers et la fréquence des unités de calcul. Ces deux dernières fréquences sont liées puisque les unités de calcul fonctionnent grossièrement à la manière des unités dual pumped du Pentium 4 et donc à une fréquence double par rapport au scheduler, aux registres etc. Du G80 au GT200, les fréquences importantes étaient uniquement celles du GPU et des unités de calcul. Les unités de texturing, les ROPs, le setup / rasterizer étaient tous dans le domaine du GPU.

Avec le GF100, cela change. Tout ce qui est dans le GPC fonctionne à la fréquence des SMs/schedulers. Autrement dit, en termes d’unités d’exécution, il ne reste que les ROPs dans le domaine de la fréquence GPU. Nvidia n’a pas voulu parler des fréquences pour le GF100 mais si nous nous basons sur l’architecture actuelle, cela apporterait un gain à de nombreuses unités. Cela facilite également la synchronisation entre tout ce petit monde, ce qui devrait améliorer le rendement et/ou simplifier le design.


Architecture mémoire
Le GF100 dispose tout d’abord de nombreux registres généraux, 32768 de 32 bits par SM, d’une structure de caches généralistes avec un cache L1 de 16 Ko par SM (possibilité de 48 Ko en mode compute uniquement), un texture cache de 12 Ko per SM (lecture uniquement) et un cache L2 global de 768 Ko. Ce dernier se connecte, ou plutôt fait partie des 6 contrôleurs mémoire de 64 bits qui forment le bus de 384 bits.


Les caches L1 et de texture partagent les mêmes ports vers le cache L2 en lecture. La bande passante entre le L1 et le L2 est au total de 384 octets per cycle, soit de +/- 270 Go/s suivant la fréquence qui sera retenue, et ce, dans chaque direction.

Si le nombre de registres de 32768 peut paraître élevé, il est en réalité en baisse par rapport au nombre d’unités de calcul, ce qui veut dire que les longues latences seront moins bien masquées par le nombre de threads. Par contre la structure de cache permettra de réduire les longues latences et de pouvoir étendre l’espace registre à travers le L1 pour conserver plus de threads dans les SMs quand la pression sur les registres généraux est forte.

Il est difficile de savoir à quel point l’architecture de cache généraliste choisie par Nvidia sera efficace. Certes elle est plus flexible et va permettre de faire de nouvelles choses, mais elle remplace une série de caches dédiés très efficaces dont elle devra se charger de tout le travail.


Si vous avez suivi la présentation compute de l’architecture Fermi, vous vous souvenez probablement que le cache L1 et la mémoire partagée (qui permet aux threads d’un même groupe de communiquer entre eux) sont liés. Ils se partagent 64 Ko de cette manière : 16 Ko pour l’un et 48 Ko pour l’autre. Dans un sens ou dans l’autre, ce qui laisse 2 possibilités. En mode graphique ce sera toujours 16 Ko de L1 et 48 Ko de mémoire partagée, le L1 n’étant réellement utile que lors de calculs peu prédictibles, ce qui est le contraire du rendu 3D.

Direct3D 11 exige le support d’une mémoire partagée de 32 Ko partagée entre maximum 1024 threads (1536 threads maximum dans un SM du GF100). Si le GF100 peut donc aller au-delà, en pratique il est en général recommandé de conserver au moins 2 groupes de threads par SM. Autrement dit pour de meilleures performances il faudra en général se contenter de 768 threads et de 24 Ko de mémoire partagée ou de 512 threads et de 16 Ko de mémoire partagée. Cette dernière option étant préférable puisqu’il s’agit d’un dénominateur commun avec l’architecture des Radeon HD 5000.


Page 4 - 4 setup engines !

4 setup engines !
Avec le GF100, Nvidia est le premier concepteur de GPU à briser la limite d’un triangle par cycle. Par le passé nous avons vu les setup engines gagner en performance, en passant par exemple de 0.5 à 1 triangle par cycle, mais jamais être parallélisés. Le GF100 voit toute cette partie du pipeline graphique être dispersée et passer de la structure globale du GPU au GPC et au SM.

Toute la partie qui concerne le traitement des vertices/triangles prend place dans le Polymorph Engine qui prend place lui-même dans chaque SM. Globalement cela revient à placer une multitude de petites unités au lieu d’une plus grosse. Au niveau des débits théoriques du Polymorph Engine, nous ne savons pas s’il y a un gain par rapport à la solution précédente. Par contre cela permet de paralléliser ces tâches et plus particulièrement la tessellation qui fait son apparition dans ce Polymorph Engine. A ce sujet, Nvidia nous a précisé qu’elle était effectuée dans un bloc d’unités dédiées et non dans les unités d’exécutions globales du SM. Notez cependant que la tessellation en elle-même est une tâche très simple. La complexité repose plutôt dans les Hull et Domain Shader. Nous vous invitons à consulter notre explication détaillée du pipeline de Direct3D 11 et de la tessellation dans le test de la Radeon HD 5800.


Globalement le Polymorph Engine contrôle toutes les étapes successives du pipeline de traitement des vertices : vertex fetch, envoi des vertices dans le SM pour les vertex et hull shaders, tessellation, envoi dans le SM pour les domain et geometry shaders, correction de perspective et optionnellement le stream output qui permet d’enregistrer en mémoire les données géométriques traitées.

Notez que tous les Polymorph Engines sont connectés entre eux et que les primitives qu’ils créent peuvent se déplacer d’un à l’autre et donc d’un SM à l’autre, via le cache L2.


Une fois le traitement de la géométrie terminé, il reste à décomposer les primitives, en général des triangles, en pixels. Cela se passe dans les Raster Engine des GPCs qui prennent en charge, chacun, un triangle par cycle. Lors du setup les équations du triangle sont calculées et les triangles qui tournent le dos à la caméra sont éjectés. Le rasterizer utilise les équations des triangles pour le décomposer en pixels ou en samples si l’antialiasing est activé. Chaque rasterizer peut débiter jusqu’à 8 pixels par cycle ou 64 samples en antialiasing 8x. Ensuite chaque tile (groupe de pixels/samples) est testée pour vérifier si elle n’est pas masquée. Si elle l’est totalement, elle est éjectée par l’unité Z-Cull.

Les 4 Raster Engines sont connectés entre eux ce qui permet de synchroniser leur travail, probablement de partager les informations utilisées au niveau du Z-Cull et de faire découper les très gros triangles par les 4 rasterizers. Précisons à ce sujet que les pixels doivent rester dans le GPC qui contient le rasterizer dont ils sont issus.

Il est intéressant de noter que si le débit en triangle du GF100 est multiplié par 4, son débit au niveau de la rastérisation reste identique à celui du GT200 ou des Radeon HD 5800 : 32 pixels par cycle en tout ou 256 samples en antialiasing 4x. Si les triangles font plus de 8 pixels, ils seront rastérisés en plusieurs cycles. Cela revient au même donc ? Pas vraiment puisque le GF100 va être jusqu’à 4x plus rapide avec des petits triangles. Il disposera également automatiquement d’un Z-Cull plus efficace puisque de plus petits zones seront testées pour la visibilité.

Cette efficacité avec les petits triangles est importante quand la tessellation est utilisée. Cependant nous devons préciser qu’elle est surtout importante avec une implémentation basique de la tessellation qui produit de nombreux petits triangles inutiles. L’avantage bien que toujours présent sera probablement moins important avec des algorithmes adaptatifs qui éviteront justement de créer trop de petits triangles à l’arrière plan pour se concentrer d’ajouter des détails et donc des triangles moins petits à l’avant plan.


Page 5 - 64 unités de texturing et 48 ROPs

64 unités de texturing
Alors que le GT200 affiche 80 unités de texturing à son compteur, le GF100 voit ce chiffre tomber à 64. Bien qu’elles passent à une fréquence que nous supposons légèrement plus élevée, le débit théorique restera inférieur à celui du GT200 dans sa version GTX 285. Avec le GF100, Nvidia a donc décidé d’augmenter uniquement la puissance de calcul de la même manière qu’AMD l’a fiat il y a quelques temps déjà. Plus d’unités de texturing veut généralement dire plus de performances dans les jeux du moment et anciens. Le nombre relativement élevé d’unités de filtrage des textures avait été un point déterminant dans le succès du G80 qui affichait des performances excellentes dès son lancement.

Nvidia a donc essayé de tirer le maximum de ses unités et devra en faire de même au niveau des pilotes, un travail important puisque toutes les optimisations actuelles devront être revues. Au niveau hardware, l’intégration dans le SM permet selon Nvidia d’améliorer l’efficacité. Les unités de textures conservent un cache dédié en lecture de 12 Ko ce qui est similaire à l’architecture précédente qui disposait de 24 Ko mais pour des groupes de 8 unités.

Au niveau des débits, elles restent globalement similaires aux unités de l’architecture précédente lorsque le filtrage, quel qu’il soit, est utilisé : 4x INT8 en 1 cycle, 4x FP16 en 2 cycles, 4x FP32 en 4 cycles. Par contre sans filtrage, le FP16 et l’INT16 passent à pleine vitesse, Nvidia ayant remarqué que le chargement de textures non filtrées (ou qui ont besoin d’un filtre spécial réalisé dans le shader) devenait plus courant. Une optimisation peu coûteuse en termes de transistors mais qui peut donc doubler les débits dans certains cas. Par contre les formats HDR basse qualité, en 32 bits, tels que le R9G9B9E5 et le R10G10B10A2 sont toujours traités à la même vitesse que le FP16 alors que d’après nos résultats, AMD a modifié ses unités avec les Radeon HD 5000 pour les traiter à pleine vitesse.


Enfin, Nvidia a implémenté l’instruction Gather4 avec offsets en hardware. Cette instruction permet de récupérer dans un vecteur 4 samples d’une texture en une seule instruction. La version avec offset permet de ne pas récupérer simplement les 4 samples adjacents mais d’en sélectionner 4 dans une grille de 128x128 texels centrée sur l’adresse. Cela permet d’ajouter de l’aléatoire dans certains filtres. Accéder à 4 adresses différentes étant compliqué, l’implémentation basique de Gather4 avec offset consiste en la décomposer en 4 instructions simples. De son côté, Nvidia est capable de la gérer nativement mais à demi-vitesse, ce qui reste deux fois plus rapide que l’implémentation basique, et annonce ainsi un net avantage sur les Radeon HD 5000. Notez pour être complet que l’utilisation de l’offset entraîne beaucoup plus de « cache miss » et que le GF100 dispose ici d’un autre avantage avec un texture cache de 12 Ko contre 8 Ko pour les dernières Radeon.


48 ROPs
Le GF100 utilise 6 partitions de ROPs contre 8 dans le GT200, ce qui est lié à son bus mémoire de 384 bits. Par contre chaque partition dispose maintenant de 8 ROPs au lieu de 4, ce qui en porte le nombre total à 48 contre 32 pour le GT200. Ils conservent des spécificités identiques si ce n’est que le CSAA 32x (MSAA 8x + coverage 24x) fait son apparition et que Nvidia indique avoir amélioré quelque peu la compression en MSAA 8x et rendu possible dans les pilotes l'utilisation des coverage samples du CSAA pour les surfaces rendues en alpha-to-coverage, ce qui va donc permettre au transparency antialiasing de gagner en qualité.

Sans antialiasing, ces 48 ROPs ne pourront cependant pas être complètement utilisés. Attendez-vous donc à un fillrate qui correspondra à peu près à 32 ROPs. Il n’y a cependant pas d’entourloupe sur les spécifications. Rappelez-vous, les 4 rasterizers, ensemble, produisent 32 pixels par cycle, il n’est donc pas possible d’en écrire 48 par cycle en mémoire. Nous précisons « à peu près » puisque les rasterizers et les ROPs ne fonctionnent pas à la même fréquence.

Quel intérêt ont ces 48 ROPs donc ? En plus de permettre l’existence du bus mémoire de 384 bits (sans quoi il serait limité à 256 bits), ils seront utiles pour garantir de bonnes performances avec antialiasing. Sa compression ne pouvant pas être maximale (ce qui voudrait dire qu’il ne sert à rien), l’antialiasing ajoute une charge supplémentaire sur les ROPs qui auront plus de données à écrire en mémoire.


Page 6 - Quelques chiffres

Quelques chiffres
Lors de la présentation du GF100, Nvidia nous a donné plusieurs chiffres théoriques, mais sans savoir exactement ce qu’ils représentent nous préférons ne pas les publier. Il est en effet facile de faire dire à des tests spécifiques ce qu’on a envie qu’ils disent.

Nvidia a également exécuté 3 tests de performances devant nous. Le premier est un benchmark de Far Cry 2, le second un benchmark de Dark Void et enfin le troisième un benchmark de raytracing.



Far Cry 2 – 1920x1200 – AA4X
GTX 285 : 50.5 fps
GF100 : 83.9 fps

La carte équipée du GF100 dont nous ne connaissons pas les fréquences s’est montrée ici 66% plus véloce. Pour comparaison, lors de notre dernier test nous avions obtenu 50.8 fps pour la GTX 285 et 66 fps pour la Radeon HD 5870. Attention cependant, Far Cry 2 est l’un des seuls jeux où les Radeon HD 5000 sont peu efficaces avec antialiasing.

Dark Void – 1920x1200 – AA4x – PhysX
GTX 285 : 38.3
GF100 : 77.6

Cette fois la carte GF100 est 2x plus rapide que la GeForce GTX 285, ce qui met en avant les capacités au niveau du computing du nouveau GPU qui peut traiter plus efficacement le travail lié à PhysX.

Raytracing Optix - 1920x1200
GTX 285 : 0.232 fps
GF100 : 0.633 fps

Ici la carte GF100 qui effectue en rendu en raytracing via CUDA est 2.7x plus rapide que la GeForce GTX 285.

Attention cependant pour tous ces résultats et plus particulièrement pour Dark Void et le raytracing : la carte GF100 est équipée de 1.5 Go de mémoire contre 1 Go pour la GTX 285. Il suffit que la mémoire de celle-ci soit dépassée pour entraîner une grosse différence. Etant donné que nous ne maîtrisions pas les conditions de test il est difficile de savoir si la quantité de mémoire a joué un rôle et de quel ordre il est.


Spécifications
Nous avons récapitulé les spécifications du GF100 pour les comparer aux autres GPUs. Nous avons également calculé les débits maximum en prenant en compte des fréquences de 725 MHz pour le GPU, 1400 MHz pour les unités de calcul (et donc 700 MHz pour les setup engines et les unités de texturing) et 1200 MHz (2400 MHz au niveau du transfert des données) pour la GDDR5.


Comme vous pouvez le remarquer le point fort du GF100 est son débit en triangles alors que son point faible se trouve au niveau du débit en textures filtrées.

Quant à la puissance de calcul elle reste nettement inférieure à celle de la Radeon HD 5870. Par contre l’organisation des unités est très différente et permet une meilleure efficacité du côté de Nvidia. Reste que l’organisation a changé depuis le G80 et le GT200, il restera donc à vérifier à quel niveau elle se situe du côté du GF100. Bien qu’il est évident qu’elle soit dans tous les cas plus importante que du côté des Radeon compte tenu du comportement scalaire, il faudra s’assurer que le double scheduler permet de maintenir une efficacité du même niveau que celle des GeForce précédentes.


Page 7 - Conclusion

Conclusion
Que penser de ce GF100 ? Va-t-il représenter une révolution ? Un flop ? Des réactions mitigées ? De notre côté nous opterons plutôt pour cette dernière option principalement parce que 6 mois après les Radeon HD 5800, les attentes seront importantes et ce dans les jeux actuels, ce qui est logique. AMD a placé le niveau de performances très haut, un niveau difficile à égaler lorsque de nombreuses innovations architecturales sont mises en place. Elles demandent en général quelques petites adaptations et surtout un travail important au niveau de l’optimisation des pilotes.


La manière dont Nvidia prépare le terrain ainsi que les informations qui sont dévoilées aujourd’hui nous laissent penser qu’en moyenne le dérivé haut de gamme du GF100 devrait afficher des performances du même ordre que la Radeon HD 5870, probablement quelques points au-dessus, Nvidia va s’en assurer en fixant les fréquences. En soit ce n’est pas un mauvais résultat, mais 6 mois après, cela risque de décevoir certains.

Le GF100 sera probablement battu dans les jeux aux moteurs les plus simples mais s’en sortira mieux dans d’autres. Depuis les GeForce 8, Nvidia disposait systématiquement d’un avantage au niveau de la puissance de filtrage des textures qui lui permettait d’afficher un gain de performances énorme dès le lancement de ses nouveaux GPUs. Cette fois, l’orientation va clairement vers des moteurs qui vont faire un usage plus important de la puissance de calcul et d’une géométrie très détaillée à travers la tessellation. Un retournement de situation complet dans l’opposition classique entre les GeForce et les Radeon. Le GF100 aura besoin de l’utilisation de PhysX et de jeux DirectX 11 qui exploitent la tessellation pour s’afficher sous son plus beau jour. Des promesses donc, ce que Nvidia a paradoxalement régulièrement reproché à AMD par le passé.

Les 4 setup engines, le nouveau sous-système mémoire et toutes les évolutions apportées à l’aspect « compute » sont sur le papier les points forts de cette architecture et, dans l’absolu, des avancées très importantes dans l’évolution du GPU. Plus Nvidia en dévoile sur le GF100, plus nous avons de questions à son sujet et sommes donc impatients de pouvoir tester tout cela en pratique, y compris bien entendu le comportement dans les jeux de cette architecture géométrique innovante.


Restera la problématique du positionnement tarifaire et des nuisances. Le GF100 et ses 3 milliards de transistors représente un défi en terme de production, ce qui entraîne des coûts élevés et une commercialisation tardive. Ce n’est pas un problème pour le marché Tesla, mais c’en est un pour le marché GeForce. Compte tenu de la disponibilité qui devrait rester faible il est probable que Nvidia n’attaque pas AMD sur le rapport performances/prix puisque dans tous les cas les GeForce GF100 intéresseront un public autre que les joueurs passionnés et fortunés qui seront prêt à mettre le prix pour les promesses de Fermi. Quant à la consommation et aux nuisances sonores, elles devraient plutôt se placer dans la catégorie Radeon HD 5970 que 5870 ce qui ne manquera pas d’alimenter d’autres débats.

Enfin terminons par les problèmes liés à une arrivée tardive sur une nouvelle génération de Direct3D. L’histoire nous a montré que le premier arrivé avait toujours raison et le second toujours tort. Cela va-t-il affecter le GF100 et l’utilisation des avantages de son architecture ? Difficile à dire, mais Nvidia compte bien sur ses relations privilégiées avec de nombreux développeurs pour contredire l’histoire et a dans ses poches un atout très important : Nexus. Présenté tout d’abord comme un environnement destiné au débogage du code CUDA, intégré à Visual Studio 2008, il s’agit en fait d’un outil de développement beaucoup plus complet qui intègre tout ce dont un développeur peut rêver au niveau de l’analyse et du profilage du rendu 3D. Associé à un GF100 dont les avancées au niveau computing facilitent le débogage, Nexus pourrait bien devenir incontournable pour les développeurs et ainsi effacer le retard de Nvidia sur Direct3D 11.


Copyright © 1997-2024 HardWare.fr. Tous droits réservés.