Les cartes graphiques

Au fur et à mesure que les procédés de fabrication devenaient de plus en plus étoffés, les cartes graphiques pouvaient incorporer un plus grand nombre de circuits. Les unités de traitement de la géométrie étaient autrefois câblées : elles ne pouvaient effectuer qu'un éclairage de type Phong, rien de plus. Alors certes, il était possible de configurer certains paramètres pour obtenir un éclairage proche de celui voulu, mais le type d'éclairage restait le même.

Par la suite, les unités de traitement de la géométrie sont devenues des unités programmables. Par programmable, on veut dire qu'il est possible de spécifier leur comportement via un programme informatique. Cela permet une grande flexibilité : changer le comportement ne nécessite pas de recâbler tout le circuit (ce qui est souvent impossible) : il suffit de changer la suite d'instructions à exécuter. Nos unités de traitement de la géométrie deviennent donc des processeurs indépendants, capables d'effectuer un certain nombre d'instructions sur les données de nos sommets.

Ces processeurs sont donc capables d'exécuter des programmes sur des sommets. Ces programmes sont appelés des vertex shaders. Ils sont souvent écrits dans un langage de haut niveau, le HLSL ou le GLSL, et sont traduits (compilés) par les pilotes de la carte graphique, pour les rendre compatibles avec le processeur de vertex shaders. Au début, ces langages, ainsi que le matériel, supportaient uniquement des programmes simples. Au fil du temps, les spécifications de ces langages sont devenues de plus en plus riches et le matériel en a fait autant.

L'étape de traitement des pixels est elle aussi devenue programmable. Des programmes capables de traiter des pixels, les pixels shaders, ont fait leur apparition. Une deuxième série d'unités a alors été ajoutée dans nos cartes graphiques : les processeurs de pixels shaders. Les processeurs de pixels shaders fonctionnent sur le même principe que les processeurs de vertex shaders.

Les premières cartes graphiques avaient des jeux d'instructions séparés pour les unités de vertex et les unités de pixel shaders. Et les processeurs de vertex shaders et de pixels shaders étaient séparés. Pour donner un exemple, c'était le cas de la Geforce 6800. Depuis DirectX 10, ce n'est plus le cas. Depuis, le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders.

Les premiers processeurs de shaders disposaient de peu d'instructions. On trouvait uniquement des instructions de calculs arithmétiques, dont certaines étaient assez complexes (logarithmes, racines carrées, etc.). Depuis, d'autres versions de vertex shaders ont vu le jour. Pour résumer, les améliorations ont porté sur :

• le nombre de registres ;
• la taille de la mémoire qui stocke les shaders ;
• le support des branchements ;
• l'ajout d'instructions d'appel de fonctions ;
• le support de fonctions imbriquées ;
• l'ajout d'instructions de lecture/écriture en mémoire centrale ;
• l'ajout d'instructions capables de traiter des nombres entiers ;
• l'ajout d'instructions bit à bit.

Un processeur de shaders contient évidemment des registres. Il dispose notamment de registres généraux, qui servent à stocker des résultats temporaires de calcul. À côté, on trouve des registres qui servent à stocker des constantes. Ils permettent de stocker les matrices servant aux différentes étapes de transformation, de stocker les positions des sources de lumière pour l'éclairage, etc. Ces constantes sont placées dans ces registres lors du chargement du vertex shader dans la mémoire vidéo : les constantes sont chargées un peu après. Toutefois, le vertex shader peut écrire dans ces registres, au prix d'une perte de performance particulièrement violente.

Le choix de la constante à utiliser dans une instruction s'effectue en utilisant un registre : le registre d'adresse de constante. Celui-ci va permettre de préciser quel est le registre de constante à sélectionner dans une instruction. Une instruction peut ainsi lire une constante depuis les registres constants et l'utiliser dans ses calculs.

Sur tous les processeurs de traitement de sommets, il est possible de traiter plusieurs morceaux de sommets à la fois. Pour cela, les processeurs de traitement de sommets utilisent des instructions spécialisées, qui peuvent manipuler un grand nombre de données simultanées. Il existe deux techniques  :

• les instructions vectorielles ;
• les instructions VLIW.

Les instructions sont vectorielles : elles travaillent sur un ensemble de données de même taille et de même type. Ces données sont rassemblées dans des espèces de blocs de données, d'une taille fixe, qu'on appelle vecteurs. Ces vecteurs contiennent plusieurs nombres entiers ou nombres flottants placés les uns à côté des autres.

Une instruction de calcul vectoriel va traiter chacune des données du vecteur indépendamment des autres. Par exemple, une instruction d'addition vectorielle va additionner ensemble les données qui sont à la même place dans deux vecteurs et mettre le résultat dans un autre vecteur, toujours à la même place. Quand on exécute une instruction sur un vecteur, les données présentes dans ce vecteur sont traitées simultanément.

Elles sont utilisées dans la quasi-totalité des cartes graphiques Nvidia et dans les cartes AMD/ATI récentes. Seules les vieilles cartes graphiques AMD utilisaient du VLIW.

II-A. Geforce 3▲

II-B. Instructions à prédicats▲

Ces instructions vectorielles sont très utiles quand on doit effectuer un traitement identique sur un ensemble de données similaires. Mais dès que le traitement à effectuer sur nos données varie suivant le résultat d'un test ou d'un branchement, les choses se gâtent. Mine de rien, avec une instruction vectorielle, on est obligé de calculer et de modifier tous les éléments d'un paquet : il est impossible de zapper certains éléments d'un paquet dans certaines conditions. Par exemple, imaginons que je veuille additionner ensemble les éléments d'un paquet seulement s'ils sont positifs : je ne peux pas le faire avec une instruction vectorielle « normale ». Du moins, pas sans aide.

Pour résoudre ce problème, certains processeurs de traitement de sommets utilisent des instructions à prédicats. Pour faire simple, ces instructions sont des instructions « annulables ». Elles ne modifient un élément d'un vecteur que si celui-ci remplit une condition. Pour cela, notre processeur de traitement de sommets contient un registre masque de sommet (vector mask register). Celui-ci stocke des informations qui permettront de sélectionner certaines données et pas d'autres pour faire notre calcul. Il est mis à jour par des instructions de comparaison.

Ce registre masque de sommet va stocker des bits pour chaque flottant présent dans le vecteur à traiter. Si ce bit est à 1, notre instruction doit s'exécuter sur la donnée associée à ce bit. Sinon, notre instruction ne doit pas la modifier. On peut ainsi traiter seulement une partie des registres stockant des vecteurs SIMD.

Autre solution : faire de nos streams processors des processeurs VLIW. Sur ces processeurs VLIW, nos instructions sont regroupées dans ce qu'on appelle des paquets, des sortes de super-instructions. Ces paquets sont découpés en morceaux de taille bien précise, dans lesquels il va venir placer les instructions élémentaires à faire exécuter.

Chaque tranche sera attribuée à une unité de calcul bien précise. Par exemple, la première tranche sera attribuée à la première ALU, la deuxième à une autre ALU, la troisième à la FPU, etc. Ainsi, l'unité de calcul exécutant l'instruction sera précisée via la place de l'instruction élémentaire, la tranche dans laquelle elle se trouve.

Qui plus est, vu que chaque tranche sera attribuée à une unité de calcul différente, le compilateur peut se débrouiller pour que chaque instruction dans un paquet soit indépendante de toutes les autres instructions dans ce paquet. Lorsqu'on exécute un paquet, il sera décomposé par le séquenceur en petites instructions élémentaires qui seront chacune attribuées à l'unité de calcul précisée par la tranche qu'elles occupent. Pour simplifier la tâche du décodage, on fait en sorte que chaque tranche ait une taille fixe.

Dans la majorité des cas, ces unités VLIW sont capables de traiter deux instructions arithmétiques en parallèle : une qui sera appliquée aux couleurs R, G et B, et une autre qui sera appliquée à la couleur de transparence. Cette possibilité s'appelle la co-issue.

De nos jours, les processeurs de sommets ou de pixels sont tous identiques, et peuvent servir à faire aussi bien des calculs graphiques que des calculs sur des données quelconques. Ces processeurs sont ce qu'on appelle des streams processors, des processeurs spécialement conçus pour exécuter des suites d'instructions sur un grand nombre de données.

Sur ces processeurs, des programmes, nommés kernels, sont appliqués entièrement à un tableau de données que l'on appelle un stream. Dans nos cartes graphiques actuelles, ce stream est découpé en morceaux qui seront chacun traités sur un stream processor. Chacun de ces morceaux est appelé un thread. Vous remarquerez que le terme thread est ici utilisé dans un sens différent de celui utilisé précédemment. Faites attention ! Quoi qu'il en soit, ces processeurs ressemblent fortement aux processeurs vectoriels ou aux processeurs utilisant des instructions SIMD.

Un GPU actuel est souvent composé de plusieurs de ces streams processors, placés ensemble sur une même puce, avec quelques autres circuits annexes, utilisés dans les tâches de rendu 3D. Ces streams processors sont alors pilotés par un gros microcontrôleur qui se charge de découper le stream à traiter en threads, avant de les répartir sur les différents streams processors de la puce.

Le découpage du stream en threads se fait à l'exécution. En clair : on envoie à notre carte 3D des informations sur le tableau à manipuler et celle-ci se débrouille toute seule pour le découper en morceaux et les répartir sur les processeurs disponibles.

IV-A. Streams processors▲

Ces streams processors sont comme les processeurs de sommets ou de pixels normaux. Plus précisément, il s'agit de processeurs SIMD, comme on l'a vu dans le chapitre précédent. Ils traitent donc des vecteurs de taille fixe. La différence avec un simple processeur SIMD vient toutefois de leur communication avec la mémoire, et de l'organisation des registres.

À première vue, les schémas ci-dessus ne ressemblent à rien de connu. Et pourtant, on peut déjà faire quelques remarques assez intéressantes.

IV-B. Register files▲

Sur un processeur, les registres sont tous regroupés dans de grosses mémoires RAM qu'on appelle des fichiers de registres (register files). On en trouve dans des tas de processeurs et pas seulement dans des streams processors. Dans nos streams processors, on remarque que l'on en a plusieurs. On trouve d'abord quelques fichiers de registres locaux. Ceux-ci sont directement connectés aux unités de calcul. C'est dans ces fichiers de registres locaux que nos unités de calcul vont aller chercher les données qu'elles doivent manipuler. Plus bas, ces fichiers de registres locaux sont reliés à un fichier de registres plus gros, le fichier de registres global, lui-même relié à la mémoire.

C'est très différent de ce qu'on trouve sur les processeurs plus habituels. D'habitude, on ne dispose pas de plusieurs couches de registres. Alors pourquoi en trouve-on plusieurs ici ? Le fait est que nos streams processors et nos GPU disposent d'une grande quantité d'unités de calcul. Et cela peut facilement monter à plus d'une centaine ou d'un millier d'ALU ! Si on devait relier toutes ces unités de calcul à un gros fichier de registres, cela poserait pas mal de problèmes. Si on faisait ça, on se retrouverait avec un fichier de registres énorme, lent, et qui chaufferait beaucoup trop.

Pour garder un fichier de registres rapide et pratique, on est obligé de limiter le nombre d'unités de calcul connectées dessus, ainsi que le nombre de registres contenus dans le fichier de registres. La solution est donc de casser notre gros fichier de registres en plusieurs plus petits, reliés à un fichier de registres plus gros, capable de communiquer avec la mémoire. Ainsi, nos unités de calcul vont aller lire ou écrire dans un fichier de registres local très rapide.

Notre fichier de registres global va en quelque sorte servir d'intermédiaire entre la mémoire RAM et le fichier de registres local. Un peu comme une mémoire cache. La différence entre ce fichier global de registres et un cache vient du fait que les caches sont souvent gérés par le matériel, tandis que ces fichiers de registres sont gérés via des instructions-machine. Le processeur dispose ainsi d'instructions pour transférer des données entre les fichiers de registres ou ceux-ci et la mémoire. Leur gestion peut donc être déléguée au logiciel, qui saura les utiliser au mieux.

Notre fichier de registres global va servir à stocker un ou plusieurs threads destinés à être traités par notre stream processor. Il peut aussi servir à transférer des données entre les fichiers de registres locaux ou à stocker des données globales, utilisées par des Clusters d'ALU différents. Quant à nos fichiers de registres locaux, ils vont servir à stocker des morceaux de threads en cours de traitement : tous les résultats temporaires vont aller dans ce fichier de registres local, afin d'être lus ou écrits le plus rapidement possible.