Le futur, conclusion

Par l’intermédiaire de cet article je viens de retracer trois années d’évolution des cartes 3D en détaillant les trois principales versions de shaders qui se sont succédées durant cette période. Je tiens à préciser que j’ai préféré éviter de parler des versions intermédiaires afin de ne pas alourdir encore davantage le propos. Je suis donc passé rapidement sur les versions 1.4 ou 2.x qui ont pourtant présenté des améliorations intéressantes mais ces dernières se sont bien souvent retrouvées intégrées dans la version suivante. Maintenant que peut on retenir de tout ça ? La première chose, fondamentale à mes yeux, c’est qu’en 3 ans des progrès énormes ont été faits en terme de programmabilité et de flexibilité des modèles. On est ainsi passé d’une architecture que je qualifierais de configurable, pour les premières versions de Pixel Shaders, à un modèle réellement programmable. On dispose ainsi désormais d’un pipeline évolué, tant au niveau des sommets que des fragments, autorisant un nombre d’instructions élevé allié à un support complet des branchements.

Pour conclure cette discussion il peut être intéressant de s’intéresser à ce que l’on peut attendre pour les prochaines générations de GPU (R500/NV50). Maintenant que les deux modèles ont atteint un niveau de fonctionnalités satisfaisant et similaire, sur quoi vont porter les prochaines améliorations ? Difficile à dire dans un domaine évoluant aussi rapidement que la 3D temps réel, je vais quand même me risquer à donner quelques pistes que la plupart des spécialistes du sujet considèrent comme raisonnables. La première chose je pense est que la convergence des Vertex et des Pixel Shaders va se poursuivre. Je m’explique car je pense que ce n’est pas forcément un concept évident à saisir au premier abord. Comme nous l’avons vu initialement Vertex et Pixel Shaders étaient deux mondes à part : chacun avait ses propres instructions, chacun opérait sur des données de formats différents et de précision distincte. Aujourd’hui les deux modèles sont très proches, travaillant sur des données similaires : des vecteurs de 4 nombre flottants simple précision. D’un point de vue théorique plus grand-chose ne les sépare ! On peut donc imaginer les prochains GPU comme des pools d’unités vectorielles placées sous le contrôle d’un ordonnanceur qui allouerait les ressources en fonction de la charge, soit au traitement des sommets, soit au traitement des fragments. On se rapprocherait ainsi encore plus d’un CPU sans toutefois tomber dans l’excès de généralité qui s’avérerait pénalisant d’un point de vue des performances. Ceci n’est qu’une vision possible des choses, l’avenir nous réserve sans doute bien des surprises.

Une autre évolution éventuelle des GPU consisterait à ajouter une nouvelle unité programmable en amont des Vertex Shaders. Un processeur de primitives qui aurait l’avantage d’avoir accès aux informations topologiques des meshs. Une telle solution serait extrêmement utile pour des algorithmes de type Shadow Volume dans lesquels le CPU doit encore assister le GPU. Ce processeur de primitives aurait évidemment la possibilité de créer ou de supprimer des sommets ce qui permettrait d’implémenter des algorithmes complexes de niveau de détails directement sur le GPU. Cette solution aurait également le mérite d’offrir un support vraiment flexible des HOS apparues sur la GF3 (RT-patchs) et la Radeon 8500 (N-patchs) et retirées depuis des GPU devant le peu d’enthousiasme des développeurs pour de telles solutions spécifiques.

A terme il est probable que l’évolution des GPU tende à se rapprocher de celle des CPU. Il ne faudra donc plus s’attendre à une « révolution » à chaque génération mais à des raffinements successifs d’une architecture stable pour en tirer davantage de performances. Mais nous n’en sommes pas encore là…

Avant de mettre un terme à cet article j’aimerais revenir sur un petit détail. Vous l’aurez peut être remarqué, j’ai mis un point d’interrogation à côté du R420 dans la partie dédiées aux shaders 3.0. Pour en expliquer la raison je vais devoir faire une entorse à la règle que j’ai moi-même établie dans l’introduction et devoir me résoudre à parler d’une rumeur circulant actuellement. En effet certaines sources semblent indiquer l’absence de support des Pixels Shaders 3.0 dans le R420, ATI se tournant plutôt vers des Pixel Shaders 2.x très performants. Ce que l’on peut dire à ce sujet c’est tout d’abord que la rumeur est crédible : on sait que le R420 tel que nous le connaissons est un dérivé de l’architecture R3x0. Le véritable R400 prévu initialement se voit repoussé pour sortir en même temps que la prochaine grosse évolution de DirectX. On peut donc supposer en effet qu’ATI déjà engagé sur un projet ambitieux n’ait pas eu le temps ou les ressources de refondre entièrement son pipeline pour s’adapter à la nouvelle version des Pixel Shaders. Car c’est bien de ça qu’il est question comme nous l’avions supposé dans cet article.

Mettre à jour son pipeline, se séparer d’une structure figée et offrir un support complet pour les branchements n’est pas chose aisée, comme en témoigne les difficultés qu’a connu nVidia pour mettre au point l’architecture de sa GeForce FX. En contrepartie la firme californienne se trouve désormais en bonne position pour ajouter le support de la 3ème version des Pixel Shaders, l’essentiel des fonctionnalités étant déjà supporté. Mais la question que l’on se pose c’est finalement si cela va changer quelque chose. Car c’est bien beau de parler de Pixel Shaders 3.0 mais les jeux exploitant les 2.0 ne sont déjà pas nombreux, alors est ce que les quelques fonctionnalités en plus sont vraiment nécessaires ? Il est clair que le saut était plus important lors du passage à la version 2.0, principalement parce qu’on partait de beaucoup plus bas ;). Les Pixel Shaders 2.0 constituent d’ores et déjà une base de travail satisfaisante, cependant ils ne sont pas dénués de limites qui peuvent s’avérer frustrantes. Les Pixel Shaders 3.0 permettent de s’en affranchir. En revanche un problème qui semble bien plus important à mes yeux concerne le support des Vertex Shaders 3.0. En effet de part leur mode de fonctionnement les versions 3.0 des shaders sont extrêmement liées. Autrement dit il est nécessaire d’associer un Vertex Shader 3.0 à un Pixel Shader 3.0 contrairement aux versions précédentes. La raison vient du nouveau mode de déclaration qui oblige à spécifier des sémantiques pour les différents registres et évidemment les sémantiques des registres de sortie du Vertex Shader doivent coïncider avec ceux d’entrée du Pixel Shader. Se priver des Pixels Shaders 3.0 reviendrait donc à se priver également des Vertex Shaders 3.0 et là c’est d’ores et déjà plus grave ne serait ce que pour le support du Vertex Texturing. Mais je rappelle que tout ceci ne reste que des suppositions !

Si cette rumeur s’avère finalement exacte il sera toujours possible de débattre sur la pertinence des choix de chacun des deux concurrents. Une chose est sûre il y a du pour et du contre dans les deux approches mais pour l’instant juger est inutile tant que l’on n’en sait pas plus. Nous serons de toutes façon fixés d’ici quelques jours maintenant…