Nvidia GeForce GF100 : la révolution géométrique ?

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.