Architecture (suite)

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

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.

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.