Accueil » Dossier » Doom III : Behind the scenes » Page 5

Doom III : Behind the scenes

1 : Introduction, historique 2 : Historique, suite 3 : Technologie : les Shadow Volumes 4 : Technologie : le Per Pixel Lighting 6 : Conclusion

Les code path

S’il est une partie de ce nouveau moteur 3D à avoir bénéficié de toutes les attentions de la part de John Carmack c’est le Renderer. Qu’est ce que le Renderer ? Expliqué simplement le Renderer contrôle tout ce qui est affiché à l’écran, en fait plus exactement le Renderer contrôle tout ce qui a une influence sur le rendu à l’écran : une lumière par exemple n’est pas affichée directement mais va influencer la façon dont sont rendus les autres éléments. Le Renderer de Doom III est codé en OpenGL et il en existe différentes versions adaptées aux capacitées des diverses cartes 3D.
La raison pour laquelle Carmack a été obligé d’écrire plusieurs versions de son Renderer est simple : OpenGL est, comme son nom l’indique, un standard ouvert gouverné par un consortium de sociétés connu sous le nom d’ARB (Architecture Review Board). Contrairement à DirectX qui est contrôlé uniquement par Microsoft, qui décide à chaque nouvelle version de l’API de ce qui y sera ajouté, c’est l’ARB (et donc l’ensemble de ses membres) qui décide des évolutions d’OpenGL. Comme vous vous en doutez, parvenir à mettre d’accord un ensemble de sociétés (dont certaines en concurrence directe) n’est pas une chose aisée ! Par conséquent OpenGL ne connaît pas des nouvelles versions aussi fréquentes que DirectX, heureusement un mécanisme a été créé pour pallier ce genre de problèmes : chaque société peut offrir des extensions à l’API pour permettre aux programmeurs d’utiliser les nouvelles capacités de son hardware.
En pratique OpenGL évolue donc plus rapidement que DirectX et bride moins les fabricants de hardware en leur permettant de dévoiler toutes les capacités de leur puce. Le gros inconvénient c’est qu’à chaque nouveau processeur graphique le fabriquant apporte sa propre collection d’extensions évidemment incompatibles avec les autres. Ainsi pour supporter deux hardwares différents il faut écrire deux versions du code différentes, tout du moins jusqu’à ce que l’ARB se mette d’accord sur une extension officielle. Ainsi Carmack a du prévoir plusieurs versions de son Renderer c’est ce qu’il évoque dans ses .plan sous le terme de « code path ». Voici les principaux code path disponibles :

  • NV10
    Il s’agit du premier code path sur lequel John Carmack a commencé à travailler, cette version est utilisée par toutes les cartes basées sur les puces GeForce/GeForce2/GeForce4 MX. Elle s’appuie sur l’extension GL_NV_register_combiners pour effectuer les calculs d’éclairage par pixel, et utilise un maximum de deux textures par passe (ce qui nécessite 5 passes en moyenne pour gérer l’ensemble des interactions lumière / surface).

  • NV20
    C’est le code path utilisé par les cartes basées sur les puces GeForce3 et GeForce4 Ti. Cette version utilisait initialement l’extension GL_NV_vertex_program qui depuis a été remplacée par la version officielle de l’ARB : GL_ARB_vertex_program. Les Vertex Program sont utilisés pour les calculs préalables au bump mapping, et servent également lors de la génération de la silhouette même si la majeure partie du travail à ce niveau reste effectuée par le CPU. Au niveau de la rastérisation on retrouve l’extension GL_NV_register_combiners, mais désormais utilisant un maximum de 4 textures par passe permettant de réduire le nombre de passes à 2 ou 3 en moyenne. J’aimerais également éclaircir un point à ce sujet : les Pixels Shaders lancés à grands renforts de marketting sur la GF3 par Nvidia n’apportent rien à Doom III, techniquement les Pixels Shaders ne sont en fait qu’une version étendue des Registers Combiners apparus avec le NV10. Les chips NV2x permettent d’utiliser 4 textures par passe et 8 combiners au lieu de 2 textures et 2 combiners mais le principe reste le même (d’ailleurs l’extension OpenGL utilisée est identique). La grosse nouveauté offerte par les Pixels Shaders sur les Registers Combiners concerne l’adressage de texture qui peut désormais être contrôlé (au moyen d’une nouvelle extension GL_NV_texture_shader) permettant ce que l’on appelle des lectures de textures dépendants. Cette fonctionalité n’est absolument pas utilisée par Doom III, par conséquent le seul apport des NV2x à ce niveau concerne une diminution du nombre de passes.

  • NV30
    Cette version du Renderer a été spécialement créée pour les puces GeForceFX. Techniquement ces dernières auraient pu utiliser le code path ARB2, mais en pratique celui ci s’est avéré trop lent sur la dernière architecture d’Nvidia. Cela peut s’expliquer pour diverses raisons : drivers encore mal optimisés mais aussi et surtout parce que le code path ARB2 utilise la précision maximale offerte par la puce, en l’occurence le FP32 (32 bits flottants par composantes RGBA) sur cette architecture. Or les premières implémentations de l’architecture (NV30, NV31 et NV34) ne disposaient pas vraiment de capacités flottantes à la hauteur et l’utilisation du FP32 ne faisait rien pour arranger les choses. John Carmack a donc programmé un mode spécifique en utilisant l’extension GL_NV_fragment_program qui permet d’utiliser le mode FP16 propre à Nvidia et nettement plus rapide. Nvidia promet que le NV35 sera aussi rapide en utilisant le code path ARB2, on ne demande qu’à les croire mais il ne fonctionnait pas avec les premiers drivers utilisés lors des tests de la carte. Cependant cela semble plausible vu les améliorations apportées à cette nouvelle puce dans le domaine du calcul flottant. L’ensemble des interactions lumière / surface sont gérées en une seule passe avec ce code path.

  • R200
    Le calvaire de John Carmack : en effet ce code path destiné aux carte Radeon 8500/9000/9100/9200 lui a donné bien des soucis. Lors des premiers tests il s’est avéré que le driver OpenGL était catastrophique et ne supportait même pas le mode OpenGL standard (c’est à dire la version n’utilisant aucune extension qui n’est là qu’à titre de compatibilité). Cette première expérience a refroidi Carmack qui mit de côté cette version du Renderer. Devant l’insistance d’ATI il finit par s’y replonger quelques mois plus tard et cette fois les choses se passèrent bien mieux, et ATI fit preuve de beaucoup de réactivité pour corriger les bugs qui ne manquèrent pas d’apparaître. Cette version utilisait initialement l’extension GL_EXT_vertex_shader qui a depuis été remplacée par l’extension officielle de l’ARB : GL_ARB_vertex_program. Au niveau de la rastérisation l’extension GL_ATI_fragment_shader a été utilisée, elle permet de tirer profit des fonctionnalités plus flexibles d’ATI à ce niveau pour permettre un rendu quasiment toujours en une seule passe.

  • ARB2
    Là je dois avouer que je ne comprends pas le choix de Carmack en ce qui concerne le nom de ce code path : ARB2 ? Je préfère être clair : ce mode utilise les extensions officielles de l’ARB : GL_ARB_vertex_program et GL_ARB_fragment_program et n’a strictement rien à voir avec OpenGL2 ! En fait il y a peut être une explication très simple à ce fameux 2 source de bien des confusions : il y aurait tout bêtement un code path ARB ! Et effectivement cela coïncide avec les différents propos de Carmack dans ses .plan : ce code path ARB serait en fait la version OpenGL standard n’utilisant aucune extension. Cette version comme je l’ai déjà dit plus haut n’est là qu’à titre de compatibilité et n’est pas supportée officiellement. Toujours est il que le nom de ce code path aura embrouillé pas mal de monde alors je préfère insister : OpenGL2 est encore à l’étude, les spécifications ne sont pas définitives et par conséquent ne sont supportées dans aucun driver de cartes graphiques. Il y a bien 3DLabs qui offre un premier prototype de driver GL2 avec sa gamme de cartes Wildcat VP mais c’est tout pour l’instant. Sinon ce code path est utilisé par défaut sur les Radeon 9500/9600/9700/9800 et peut être utilisé sur les GeForceFX (même si comme je l’ai dit cela ne fonctionne pas actuellement avec les derniers drivers). Le rendu avec ce code path est toujours effectué en une seule passe.

Sommaire :

  1. Introduction, historique
  2. Historique, suite
  3. Technologie : les Shadow Volumes
  4. Technologie : le Per Pixel Lighting
  5. Les code path
  6. Conclusion