Je ne sais pas si vous êtes au courant mais d'ici quelques semaines sortira le jeu Half-Life 2. Ce jeu intègrera de nombreuses technologies novatrices dont le fameux pixel shader 2.0. En fait ce ne sera pas le premier jeu à l'utiliser, Tomb Raider : Angel of Darkness l'a précédé. L'utilisation du pixel shader 2.0 va se généraliser, car il apporte de nombreuses possibilités graphiques comme le depth of field (DOF : capacité à générer un flou sur les objets distants accentuant la présence des objets et surtout personnages de premier plan). Ces nouvelles possibilités graphiques ne sont pas toujours reproductibles avec des cartes graphiques n'en disposant pas. En fait le fossé que creuse cette technologie est suffisamment important pour considérer qu'il y a deux types de cartes : celles disposant du pixel shader 2.0 et les autres. Pour en disposer il faut avoir une carte graphique conforme aux spécifications DirectX 9.0.

Certains me diront qu'on pourra dire la même chose des pixels shaders 3.0, à savoir que cela crée un fossé avec les anciennes générations de cartes, mais ce n'est pas pareil. Le pixel shader 2.0 implique de profondes modifications dans l'architecture des processeurs graphiques (modifications sur lesquelles se baseront les pixels shaders 3.0) et ce n'est pas parce que ATI a su passer le cap avec un semblant de facilité que ça l'est ! NVidia, avec sa série FX5800 et FX5900, éprouve les plus grandes difficultés, et un jeu comme Tomb Raider préfère désactiver les pixels shaders 2.0 lorsqu'il détecte une de ces cartes (en mode réglage automatique). Bref les pixels shaders 2.0 sont un pas important dans le monde graphique et il est urgent de comprendre ce qui se cache derrière cette technologie et comment elle fonctionne.

Bonne lecture :)

Pixel et fragment : Pixel shader est un terme avant tout destiné aux utilisateurs, les développeurs parlent quant à eux de fragment shader. C'est la même chose, seul le point de vue change. Un pixel est un point de couleur à l'écran (ce que voit l'utilisateur). Il est le résultat d'un calcul associant des points provenant de différentes textures (fragments) et d'opérations mathématiques. Les développeurs travaillent avec des fragments et le résultat est un pixel, ce que voit l'utilisateur. Par exemple si vous regardez dans une pièce à travers une fenêtre les couleurs ne seront pas tout à fait les mêmes si elle est ouverte ou fermée. On va associer les fragments de la fenêtre avec ceux des objet de la pièce pour produire le pixel final. En OpenGL les pixels shaders se nomment les fragments shaders.

Texel et fragment : Vous n'avez peut-être jamais rencontré le terme de fragment et vous êtes tenté de penser qu'il s'agit d'un texel. Ce serait une erreur. Un texel est un point appartenant à une texture avant son application à un triangle. Ce triangle appartient à la géométrie (représentation en fil de fer) d'un objet ou personnage. Pour appliquer une texture à ce triangle, il faut la déformer puis appliquer un filtrage (voir article : filtrage des textures) pour éviter d'avoir des effets visuels indésirables. Il n'y a donc plus de correspondance directe entre les texels (point de la texture) et les points du triangle texturé, qu'on nomme fragment. Les fragments ne sont pas issus directement des textures stockées en mémoire.

Shader : Les shaders sont de petits programmes envoyés au processeur graphique et exécutés par lui. Attention c'est bien le processeur graphique qui va exécuter le programme et non le microprocesseur principal. Pour créer ces programmes on utilise un langage de programmation des shaders. Il en existe deux : Cg (C for Graphics) développé par NVidia et HLSL (High Level Shader Language) développé par Microsoft. En fait Cg et HLSL sont assez semblables, la raison c'est qu'il y a eu une coopération entre NVidia et Microsoft pour élaborer ces compilateurs.

Différence entre Cg et HLSL : Cg produit du code pour les API DirectX ou OpenGL, tandis que HLSL uniquement pour DirectX. Une deuxième différence importante existe et cela concerne les utilisateurs ! Cg optimise pour utiliser le moins de buffers possible et HLSL le moins d'instructions possible sans prendre en compte le nombre de buffers nécessaires. C'est quoi ces buffers et pourquoi sont-ils si importants ? Les buffers dont on parle ici sont des mémoires internes au processeur graphique qui permettent de stocker des valeurs provisoires lors de l'exécution d'un shader. Si le nombre de buffers est insuffisant, le processeur devra stocker ces informations provisoires dans la mémoire de la carte graphique, ce qui peut considérablement ralentir leur vitesse d'exécution. Les spécifications de DirectX 9 mentionnent la nécessité d'avoir 12 buffers au moins pour les shaders. Les FX 5800 et FX5900 n'en possèdent que 2 spécifiques aux shader, les autres provenant de la mémoire de la carte graphique et donc lent d'accès (note : ces cartes respectent donc bien les spécifications DX9 sur le nombre de buffers, leur vitesse n'étant pas précisée par DX9). Ceci explique pourquoi le Cg compile les programmes de shaders dans la seule optique de limiter le nombre de buffers nécessaires et donc d'utiliser le plus souvent les 2 buffers spécifiques aux shaders. La conséquence est que le Cg optimise pour les cartes graphiques NVidia, comme l'a montré un test du site Beyond3D sur le jeu Tomb Raider. Lorsque les shaders du pixel shader 2.0 sont compilés avec le Cg, les performances des cartes ATI et NVidia sont du même ordre. Lorsqu'ils ont été compilés avec HLSL, les ATI se montrent deux fois plus rapides, et les scores des NVidia baissent d'environ 10%. Conclusion il faut espérer que les développeurs utilisent HLSL pour les pixels shaders 2.0 de leur jeux.

Pas de problème, les programmes de jeux disposent de 'path', c'est-à-dire de chemins d'exécution différents pour chaque carte graphique. Quand le jeu est installé, il détecte automatiquement le type de processeur de votre carte graphique. Grâce à une table intégrée dans le programme, il sait pour chaque processeur graphique quelles sont les possibilités graphiques (en terme de technologie) dont il dispose. A partir de là, lorsqu'il y a un effet graphique à faire, le programme de jeu exécute la fonction gérant cet effet en fonction de votre processeur. Bien sûr cela n'implique pas forcément que l'effet soit aussi joli que si vous disposiez d'une carte graphique compatible DirectX 7, 8 ou 9.

Les pixels shaders s'occupent du rendu d'une image et travaillent sur les couleurs. Les vertex shaders travaillent sur la géométrie des objets. Physiquement dans le processeur graphique, les unités de calculs du vertex shader se situent avant celles des pixels shaders. Ce qui signifie qu'on effectue les calculs de géométrie avant les calculs de rendu d'image.

Cela fait des années qu'on parle de pixel shader et on en parlera encore pendant un bout de temps. C'est la technologie qu'attendaient de nombreux développeurs car c'est elle qui permettra de donner un rendu réaliste aux animations 3D. D'un point de vue conception des processeurs graphiques, on peut dire que les vertex shaders sont une technologie qui est ajoutée, tandis que les pixels shaders s'intègrent à ce qui est déjà existant et modifient la manière dont est fait le traitement des textures. Cela pose des problèmes complexes comme conserver la compatibilité avec les anciens jeux et donc les anciennes technologies.

Pixel shader 1.1 : La première carte graphique à avoir utilisé les pixels shaders 1.1 était la GeForce 3. Bien qu'on puisse trouver des traces de pixels shaders dans les Radeon 1 et même les GeForce 2 (à l'état embrionnaire), on considère que l'histoire des pixels shaders commence avec la GeForce 3 et DirectX 8.0 qui en établissait les spécifications. Les pixels shaders 1.1 sont dont la première technologie permettant véritablement la programmation d'effets de rendu et donc d'opérations mathématiques complexes sur les couleurs.

Pixel shader 1.4 : Il apporte avant tout une souplesse d'utilisation qui étend les possibilités du pixel shader 1.1 comme le nombre simultané de textures pouvant être gérées par le shader. C'est ATI qui proposa la première carte (Radeon 8500) intégrant totalement les pixels shaders 1.4. C'est DirectX 8.1 qui en établissait les spécifications. Il existe des versions intermédiaires 1.2 et 1.3, mais elles sont très semblables à la version 1.1. Donc les deux étapes à retenir pour les pixels shaders version 1 sont 1.1 et 1.4.

Pixel shader 2.0 : Deux différences essentielles sont à noter face aux anciennes versions. La première concerne la taille des shaders (programmes). On dit que le pixel shader 2.0 permet de gérer des shaders longs. Bien que le nombre d'instructions maximum que peut contenir un shader varie d'une carte graphique à une autre (sur ce point les constructeurs ont tendance à augmenter les spécifications définies par DirectX), l'ordre de grandeur entre les pixels shaders 1.1, 1.4 et 2.0 est de plusieurs dizaines à plusieurs centaines. A partir d'une centaine on peut déjà réaliser des shaders basés sur des algorithmes mathématiques très complexes permettant des simulations sophistiquées d'effets de lumière sur des matières aussi diverses que l'eau ou la mousse de l'écorce des arbres. La seconde différence se situe dans l'utilisation de nombres flottants (ou réels), au lieu de nombres entiers. C'est important pour le pixel shader 2.0 d'en disposer car plus un shader est long (autrement dit plus un programme a d'instructions) plus il risque de générer des calculs intermédiaires. Or l'ordinateur ne calcule pas avec une précision infinie, ce qui fait qu'à chaque opération mathématique, il y a un risque d'une petite perte de précision. Evidemment plus il y a de calculs plus cette perte va s'accumuler. Si les problèmes de précision pouvaient être tolérés avec les pixel shader 1.1 et 1.4 dans la mesure où il ne pouvait gérer que de petits shaders, il n'en plus de même pour les pixels shaders 2.0, d'où l'introduction des nombres flottants. Il faut donc bien se rendre compte que l'utilisation des nombres flottants va de pair avec l'augmentation de taille des shaders que le processeur graphique peut gérer. Cela est encore plus vrai si on sait qu'un processeur comme le R350 (ATI 9800) intègre une technologie nommée F-buffer qui permet de gérer des shaders de taille infinie !

Bien que les spécifications ne soient pas encore fixées, beaucoup de développeurs parlent de l'intégration d'instructions permettant un contrôle plus avancé des shaders. Les shaders s'exécutent actuellement de manière assez linéaire. Avec les pixels shaders 3.0, il sera possible, grâce au branchement conditionnel (if then else), de dire au processeur graphique d'exécuter telle ou telle partie de programme en fonction de valeurs de calculs. D'un point de vue pratique, cela va permettre par exemple d'intégrer des variations dans des motifs répétitifs.

En OpenGL les pixels shaders se nomment les fragments shaders. En version 1.5, il n'y a pas de gestion des fragments shaders de type pixel shader 2.0. Toutefois les constructeurs mettent à la disposition des développeurs OpenGL des extensions (fonctions spécifiques à un constructeur) qui leur permettent de les utiliser. Toutefois ces extensions n'étant pas compatibles entre elles, cela implique de devoir écrire un 'path' différent pour chaque carte graphique.

Pour OpenGL 2.0 qui est a commencé da faire son apparation il y a quelques mois et qui est supporté par la dernière génération de cartes graphiques il n'y a pas de problème.Enfin presque. Effectivement le hardware ne suffit pas, il faut aussi que les drivers supportent totalement cette nouvelle version or ce n'est pas totalement le cas. Mais je vous rassure ce n'est pas sur les points principaux.

Le fillrate c'est quoi ? : Le fillrate c'est la quantité de pixels que peut produire/envoyer à l'écran le processeur graphique, mais celui-ci varie en fonction de l'utilisation. Le fillrate absolu dépendant de la fréquence du GPU, de son architecture. On distingue aussi le fillrate en mode single-texturing et multi-texturing, mais : dans le cas où on utilise des shaders c'est le mode single-texturing qui nous intéresse. On utilise pour cela la formule :

Fillrate absolu = Fréquence du microprocesseur * nombre de pipes

Un pipe étant une unité de production de pixel. La FX5900Ultra dispose de 4 pipes et a une fréquence de 450 MHz (soit 1800 MPixel/s) et la 9800Pro de 8 pipes à 380 MHz (soit 3040 Mpixel/s).

Le fillrate des pixels shaders 2.0 : Quand on utilise les pixels shaders 2.0, le fillrate dépend de ce que fait le shader (le programme). Toutefois en généralisant le principe de fonctionnement d'un shader 2.0 on peut se faire une idée. Un shader va contenir des instructions vectorielles (instructions manipulant les trois composantes couleurs) et des instructions scalaires (instructions manipulant généralement la valeur de transparence). Ces instructions travaillent / appellent un certain nombre de textures. Le fillrate d'une carte graphique utilisant les pixels shaders 2.0 dépend du fillrate absolu, divisé par une variable qui correspond aux capacités de l'architecture du processeur graphique à manipuler les instructions et les textures définies par le shader.On obtient la formule suivante :

Fillrate pixel shader = Fillrate absolu / X

Déterminons X pour la 9800Pro contre FX5900Ultra : La 9800Pro sait calculer simultanément une instruction vectorielle avec une instruction scalaire ou une texture. Comme le nombre d'instructions vectorielles dépasse normalement le nombre d'instructions scalaires et le nombre de textures utilisées, la valeur X pour la 9800Pro est égal au nombre d'instructions vectorielles. Pour la FX5900 c'est plus complexe. Cette carte ne sait pas gérer simultanément les instructions vectorielles, scalaires et de texturing. X sera donc égal au moins à la somme de toutes les instructions utilisées. Donc X sera toujours plus grand pour la FX5900Ultra que pour la 9800Pro. Mais même égale l'équation du fillrate pixel shader sera toujours favorable à la 9800Pro ! (pour voir un exemple détaillé de ce calcul lisez l'article de Damien Triolet - voir ci-dessous).

Ce long mini-article fait suite à la parution d'un article fait par Damien Triolet du site TT-hardware. Son article, qui faisait réfèrence lui-même au test comparatif pixel shader 2.0 basé sur le jeu Tomb Raider du site beyond3D, expliquait de manière détaillée les raisons des faibles performances des cartes FX5900 en pixel shader 2.0 comparé aux ATI 9800. Son article contient une telle richesse d'informations que je trouvais dommage qu'il ne puisse être compris par un grand nombre de lecteurs. J'ai donc pris contact avec lui et après l'avoir harcelé de questions j'écrivais mon propre article visant à présenter les éléments de base du pixel shader 2.0. Je tiens donc à remercier Damien pour son aide précieuse :).

L'avenir est au pixel et vertex shaders, c'est-à-dire à la programmabilité de fonctions. Mais outre la possibilité de faire des choses plus complexes les shaders apportent parfois la possibilité de faire des choses avant même qu'elles ne soient intégrées au GPU. Les shaders permettent donc d'anticiper dans la mesuredu possible des techniques 3D très récente ou d'améliorer des techniques existantes.

Du point de vue matériel (hardware) deux directions s'opposent actuellement entre ATI et Nvidia. ATI est pour la fusion des pipelines de pixel et vertex shaders. On perd en spécialisation, mais on gagne en souplesse de distribution des tâches. Pour Nvidia, la fusion n'est pas à l'ordre du jour et rien ne dit qu'elle le sera pour eux un jour. Dans cette optique Nvidia continue à faire des processeurs aux pipelines bien spécialisés et cela leur réussi assez bien. L'avenir nous dira qui d'ATI ou de Nvidia a raison, mais je dois reconnaître que j'ai un petit penchant pour l'aspect élégant que présente la notion de fusion des pipelines des pixels et vertex shaders.