« Les cartes graphiques/Les processeurs de shaders » : différence entre les versions

Un livre de Wikilivres.
Contenu supprimé Contenu ajouté
m →‎La hiérarchie mémoire : Déplacement de la section dans un chapitre séparé
typo
Ligne 3 : Ligne 3 :
==Jeu d'instruction==
==Jeu d'instruction==


Les shaders sont souvent écrits dans un langage de haut-niveau : le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Ils sont traduits (compilés) à la volée 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 à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant. Les premiers processeurs de shaders disposaient de peu d'instructions. On trouvait uniquement des instructions de calcul 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ées sur :
Les shaders sont souvent écrits dans un langage de haut-niveau : le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Ils sont traduits (compilés) à la volée 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 à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant. Les premiers processeurs de shaders disposaient de peu d'instructions. On trouvait uniquement des instructions de calcul 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 ;
* le nombre de registres ;
Ligne 70 : Ligne 70 :
|}
|}


Comme on le voit, ces instructions sont presque toutes des instructions arithmétiques : multiplications, additions, exponentielles, logarithmes, racines carrées, etc. À coté, on trouve des comparaisons (SDE, SLT), une instruction MOV qui déplace le contenu d'un registre dans un autre, et une instruction de calcul d'adresse. Fait intéressant, toutes ces instructions peuvent s’exécuter en un seul cycle d'horloge. On remarque que parmi toutes ces instructions arithmétiques, la division est absente. Il faut dire que la contrainte qui veut que toutes ces instructions s’exécutent en un cycle d'horloge pose quelques problèmes avec la division, qui est une opération plutôt lourde en hardware. À la place, on trouve l'instruction RCP, capable de calculer 1/x, avec x un flottant. Cela permet ainsi de simuler une division : pour obtenir Y/X, il suffit de calculer 1/X avec RCP, et de multiplier le résultat par Y.
Comme on le voit, ces instructions sont presque toutes des instructions arithmétiques : multiplications, additions, exponentielles, logarithmes, racines carrées, etc. À côté, on trouve des comparaisons (SDE, SLT), une instruction MOV qui déplace le contenu d'un registre dans un autre, et une instruction de calcul d'adresse. Fait intéressant, toutes ces instructions peuvent s’exécuter en un seul cycle d'horloge. On remarque que parmi toutes ces instructions arithmétiques, la division est absente. Il faut dire que la contrainte qui veut que toutes ces instructions s’exécutent en un cycle d'horloge pose quelques problèmes avec la division, qui est une opération plutôt lourde en hardware. À la place, on trouve l'instruction RCP, capable de calculer 1/x, avec x un flottant. Cela permet ainsi de simuler une division : pour obtenir Y/X, il suffit de calculer 1/X avec RCP, et de multiplier le résultat par Y.


S'il n'y avait aucune instruction d'accès à la mémoire sur le processeur de la Geforce 3, la situation a changé depuis : les cartes graphiques récentes peuvent aller lire certaines données depuis la mémoire vidéo. Généralement, les shaders lisent des textures en mémoire vidéo, textures qui servent à colorier les pixels ou à configurer les calculs d'éclairage. Et la plupart des cartes graphiques suivant la Geforce 2 incorporait des instructions de lecture de texture. Les écritures, plus rares, sont venues après, afin de faciliter certaines techniques de rendu dont je ne parlerais pas ici.
S'il n'y avait aucune instruction d'accès à la mémoire sur le processeur de la Geforce 3, la situation a changé depuis : les cartes graphiques récentes peuvent aller lire certaines données depuis la mémoire vidéo. Généralement, les shaders lisent des textures en mémoire vidéo, textures qui servent à colorier les pixels ou à configurer les calculs d'éclairage. Et la plupart des cartes graphiques suivant la Geforce 2 incorporait des instructions de lecture de texture. Les écritures, plus rares, sont venues après, afin de faciliter certaines techniques de rendu dont je ne parlerais pas ici.
Ligne 83 : Ligne 83 :
====Processeurs VLIW====
====Processeurs VLIW====


Sur les processeurs VLIW, les instructions sont regroupées dans ce qu'on appelle des Bundles, des sortes de super-instructions. Les instructions d'un bundle peuvent s'exécuter en parallèle sur différentes unités de calcul, mais le bundle est chargé en une seule fois depuis la mémoire. Chaque instruction d'un faisceau doit expliciter quelle unité de calcul doit la prendre en charge. Vu que chaque instruction sera attribué à une unité de calcul différente, le compilateur peut se débrouiller pour que les instructions dans un bundle soient indépendantes. Mais il se peut que le compilateur ne puisse pas remplir tout le bundle avec des instructions indépendantes. Sur les anciens processeurs VLIW, les bundles étaient de taille fixe, ce qui forcait le compilateur à remplir d'éventuels vides avec des NOP (des instructions qui ne font rien), diminuant la densité de code. La majorité des processeurs VLIW récents utilise des bundles de longueur variable, supprimant ces NOP.
Sur les processeurs VLIW, les instructions sont regroupées dans ce qu'on appelle des Bundles, des sortes de super-instructions. Les instructions d'un bundle peuvent s'exécuter en parallèle sur différentes unités de calcul, mais le bundle est chargé en une seule fois depuis la mémoire. Chaque instruction d'un faisceau doit expliciter quelle unité de calcul doit la prendre en charge. Vu que chaque instruction sera attribué à une unité de calcul différente, le compilateur peut se débrouiller pour que les instructions dans un bundle soient indépendantes. Mais il se peut que le compilateur ne puisse pas remplir tout le bundle avec des instructions indépendantes. Sur les anciens processeurs VLIW, les bundles étaient de taille fixe, ce qui forçait le compilateur à remplir d'éventuels vides avec des NOP (des instructions qui ne font rien), diminuant la densité de code. La majorité des processeurs VLIW récents utilise des bundles de longueur variable, supprimant ces NOP.


Dans la majorité des cas, ces unités VLIW sont capables de traiter deux instructions arithmétiques en parallèles : 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'''.
Dans la majorité des cas, ces unités VLIW sont capables de traiter deux instructions arithmétiques en parallèles : 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'''.
Ligne 89 : Ligne 89 :
===Jeu de registres===
===Jeu de registres===


Un processeur de shaders contient beaucoup de registres, sans quoi il ne pourrait pas faire son travail efficacement. Sur les processeurs de vertices des anciennes cartes 3D, il existait un grand nombre de registres spécialisés. Certains registres étaient spécialisés dans le stockage des vertices, d'autres dans le stockage des résultats de calculs, d'autres dans le stockage de constante, etc. Il y avait bien quelques registres généraux, sans fonction préétablie, mais ils étaient secondés par un grand nombre de registres spécialisés assez nombreux. De nos jours, ce n'est plus le cas : tous les registres sont banalisés et peuvent stocker toute donnée utile. Les registres spécialisés ont disparus. Le fait est que l'usage de registres spécialisés a perdu de son intérêt avec l'unification des ''shaders'', certains registres n'ayant de sens que pour les vertices et rien d'autre.
Un processeur de shaders contient beaucoup de registres, sans quoi il ne pourrait pas faire son travail efficacement. Sur les processeurs de vertices des anciennes cartes 3D, il existait un grand nombre de registres spécialisés. Certains registres étaient spécialisés dans le stockage des vertices, d'autres dans le stockage des résultats de calculs, d'autres dans le stockage de constante, etc. Il y avait bien quelques registres généraux, sans fonction préétablie, mais ils étaient secondés par un grand nombre de registres spécialisés assez nombreux. De nos jours, ce n'est plus le cas : tous les registres sont banalisés et peuvent stocker toute donnée utile. Les registres spécialisés ont disparu. Le fait est que l'usage de registres spécialisés a perdu de son intérêt avec l'unification des ''shaders'', certains registres n'ayant de sens que pour les vertices et rien d'autre.


Les registres des processeurs de vertices peuvent se classer en plusieurs types :
Les registres des processeurs de vertices peuvent se classer en plusieurs types :
Ligne 108 : Ligne 108 :
Les cartes graphiques sont des architectures massivement parallèles, à savoir qu'elles sont capables de faire un très grand nombre de calculs simultanés, durant le même cycle d'horloge. Il faut dire que chaque vertice ou pixel peut être traité indépendamment des autres, ce qui rend le traitement 3D fortement parallèle. Cela a quelques conséquences sur le nombre de processeurs et d'unités de calcul, ainsi que sur la hiérarchie mémoire. L'architecture doit être conçue pour pouvoir effectuer un maximum de calculs en parallèle, quitte à simplifier fortement la puissance pour des calculs séquentiels (ceux qu'effectue un processeur). La hiérarchie mémoire doit aussi gérer un grand nombre d'accès mémoire simultanés : qui dit plein d'instructions en parallèle qui travaillent sur des données indépendantes dit aussi plein de données indépendantes à lire ou écrire !
Les cartes graphiques sont des architectures massivement parallèles, à savoir qu'elles sont capables de faire un très grand nombre de calculs simultanés, durant le même cycle d'horloge. Il faut dire que chaque vertice ou pixel peut être traité indépendamment des autres, ce qui rend le traitement 3D fortement parallèle. Cela a quelques conséquences sur le nombre de processeurs et d'unités de calcul, ainsi que sur la hiérarchie mémoire. L'architecture doit être conçue pour pouvoir effectuer un maximum de calculs en parallèle, quitte à simplifier fortement la puissance pour des calculs séquentiels (ceux qu'effectue un processeur). La hiérarchie mémoire doit aussi gérer un grand nombre d'accès mémoire simultanés : qui dit plein d'instructions en parallèle qui travaillent sur des données indépendantes dit aussi plein de données indépendantes à lire ou écrire !


L'architecture d'une carte grahique récente est illustrée ci-dessous. On y voit plusieurs caractèristiques typiques : un grand nombre de processeurs/ceurs, un grand nombre d'unités de calculs par coeur, et une hiérarchie mémoire assez étagée avec des mémoires locales en complément de la mémoire vidéo principale.
L'architecture d'une carte grahique récente est illustrée ci-dessous. On y voit plusieurs caractéristiques typiques : un grand nombre de processeurs/cœurs, un grand nombre d'unités de calculs par cœur, et une hiérarchie mémoire assez étagée avec des mémoires locales en complément de la mémoire vidéo principale.


[[File:NVIDIA GPU Accelerator Block Diagram.png|centre|vignette|upright=2.0|Ce schéma illustre l'architecture d'un GPU en utilisant la terminologie NVIDIA. Comme on le voit, la carte graphique contient plusieurs cœurs de processeur distincts. Chacun d'entre eux contient plusieurs unités de calcul généralistes, appelées processeurs de threads, qui s'occupent de calculs simples (en bleu). D'autres calculs plus complexes sont pris en charge par une unité de calcul spécialisée (en rouge). Ces cœurs sont alimentés en instructions par le processeur de commandes, ici appelé ''Thread Execution Control Unit'', qui répartit les différents shaders sur chaque cœur. Enfin, on voit que chaque cœur a accès à une mémoire locale dédiée, en plus d'une mémoire vidéo partagée entre tous les cœurs.]]
[[File:NVIDIA GPU Accelerator Block Diagram.png|centre|vignette|upright=2.0|Ce schéma illustre l'architecture d'un GPU en utilisant la terminologie NVIDIA. Comme on le voit, la carte graphique contient plusieurs cœurs de processeur distincts. Chacun d'entre eux contient plusieurs unités de calcul généralistes, appelées processeurs de threads, qui s'occupent de calculs simples (en bleu). D'autres calculs plus complexes sont pris en charge par une unité de calcul spécialisée (en rouge). Ces cœurs sont alimentés en instructions par le processeur de commandes, ici appelé ''Thread Execution Control Unit'', qui répartit les différents shaders sur chaque cœur. Enfin, on voit que chaque cœur a accès à une mémoire locale dédiée, en plus d'une mémoire vidéo partagée entre tous les cœurs.]]
Ligne 118 : Ligne 118 :
Pour profiter au mieux des opportunités de parallélisme, une carte graphique contient de nombreux processeurs, qui eux-mêmes contiennent plusieurs unités de calcul. Savoir combien de cœurs contient une carte graphique est cependant compliqué, les services marketing gardant un certain flou sur le sujet. Il n'est pas rare que ceux-ci appellent cœurs ou processeurs de simples unités de calcul, histoire de gonfler les chiffres. Et on peut généraliser à la majorité de la terminologie utilisée par les fabricants, que ce soit pour les termes ''warps processor'', ou autre, qui ne sont pas aisés à interpréter. D'ordinaire, ce qui est appelé processeur de thread sur une carte graphique correspond en réalité à une unité de calcul.
Pour profiter au mieux des opportunités de parallélisme, une carte graphique contient de nombreux processeurs, qui eux-mêmes contiennent plusieurs unités de calcul. Savoir combien de cœurs contient une carte graphique est cependant compliqué, les services marketing gardant un certain flou sur le sujet. Il n'est pas rare que ceux-ci appellent cœurs ou processeurs de simples unités de calcul, histoire de gonfler les chiffres. Et on peut généraliser à la majorité de la terminologie utilisée par les fabricants, que ce soit pour les termes ''warps processor'', ou autre, qui ne sont pas aisés à interpréter. D'ordinaire, ce qui est appelé processeur de thread sur une carte graphique correspond en réalité à une unité de calcul.


Vu le grand nombre d'unités de calcul, les autres circuits ne peuvent pas trop prendre de place. En conséquence, les unités de décodage et/ou de contrôle sont relativement simples, peu complexes. Leurs fonctionnalités sont limitées au strict minimum, avec cependant quelques optimisations sur les cartes graphiques récentes. On n'y retrouve pas les fioritures des CPU modernes, tant utiles pour du calculs séquentiels : pas d’exécution dans le désordre, de renommage de registres, et autres techniques avancées.
Vu le grand nombre d'unités de calcul, les autres circuits ne peuvent pas trop prendre de place. En conséquence, les unités de décodage et/ou de contrôle sont relativement simples, peu complexes. Leurs fonctionnalités sont limitées au strict minimum, avec cependant quelques optimisations sur les cartes graphiques récentes. On n'y retrouve pas les fioritures des CPU modernes, tant utiles pour du calcul séquentiel : pas d’exécution dans le désordre, de renommage de registres, et autres techniques avancées.


[[File:Cpu-gpu.svg|centre|vignette|upright=2.0|Comparaison entre l'architecture d'un processeur généraliste et d'un processeur de shaders.]]
[[File:Cpu-gpu.svg|centre|vignette|upright=2.0|Comparaison entre l'architecture d'un processeur généraliste et d'un processeur de shaders.]]
Ligne 124 : Ligne 124 :
===Des unités de calcul autrefois spécialisée, puis devenus banalisées===
===Des unités de calcul autrefois spécialisée, puis devenus banalisées===


Même les premiers processeurs de ''shaders'' disposaient de plusieurs unités de calculs séparées, capables de faire des calculs en parallèle. Un bon exemple est le processeur de vertices de la Geforce 6800, illustré ci-dessous. On voit que le processeur contient trois unités de calculs séparées : une unité généraliste de calcul sur les vertices, une unité pour les opérations mathématiques complexes (division, racine carrée, racine carrée inverse, autres) et enfin une unité pour le calcul ''Multiply-And-Add'' (une multiplication suivie d'une addition, opération très courante en 3D). On voit que les unités de calculs sont assez spécialisées, avec une ou plusieurs unités généralistes, secondée par des unités capable de faire des calculs spécialisés.
Même les premiers processeurs de ''shaders'' disposaient de plusieurs unités de calculs séparées, capables de faire des calculs en parallèle. Un bon exemple est le processeur de vertices de la Geforce 6800, illustré ci-dessous. On voit que le processeur contient trois unités de calculs séparées : une unité généraliste de calcul sur les vertices, une unité pour les opérations mathématiques complexes (division, racine carrée, racine carrée inverse, autres) et enfin une unité pour le calcul ''Multiply-And-Add'' (une multiplication suivie d'une addition, opération très courante en 3D). On voit que les unités de calculs sont assez spécialisées, avec une ou plusieurs unités généralistes, secondée par des unités capables de faire des calculs spécialisés.


[[File:GeForce 6800 Vertex processor block.png|centre|vignette|upright=2.0|Processeur de shader (vertex shader) d'une GeForce 6800. On voit clairement que celui-ci contient, outre les traditionnelles unités de calcul et registres temporaires, un "cache" d'instructions, des registres d'entrée et de sortie, ainsi que des registres de constante.]]
[[File:GeForce 6800 Vertex processor block.png|centre|vignette|upright=2.0|Processeur de shader (vertex shader) d'une GeForce 6800. On voit clairement que celui-ci contient, outre les traditionnelles unités de calcul et registres temporaires, un "cache" d'instructions, des registres d'entrée et de sortie, ainsi que des registres de constante.]]


Cela n'a pas changé avec l'unification des ''shaders'', si ce n'est que les unités de calcul ne sont pas aussi spécialisées que dans l'exemple précédent. De nos jours, les unités de calculs dédiées à des opérations bien précises sont plus rares. On ne trouve plus d'unité spécialisé pour les opérations complexes, comme dans l'exemple précédent, de telles opérations pouvant être émulées par une suite d'opérations plus simples. Au lieu de mettre une unité spécialisée utile pour une opération sur 10/20, autant mettre une unité généraliste pour accélérer les calculs simples et fréquents, quitte à émuler les calculs complexes. De plus, les unités de calculs sont devenues beaucoup plus nombreuses.
Cela n'a pas changé avec l'unification des ''shaders'', si ce n'est que les unités de calcul ne sont pas aussi spécialisées que dans l'exemple précédent. De nos jours, les unités de calculs dédiées à des opérations bien précises sont plus rares. On ne trouve plus d'unité spécialisée pour les opérations complexes, comme dans l'exemple précédent, de telles opérations pouvant être émulées par une suite d'opérations plus simples. Au lieu de mettre une unité spécialisée utile pour une opération sur 10/20, autant mettre une unité généraliste pour accélérer les calculs simples et fréquents, quitte à émuler les calculs complexes. De plus, les unités de calculs sont devenues beaucoup plus nombreuses.


Les GPU modernes disposent d'une flopée d'unités de calcul SIMD identiques, à savoir qu'elles calculent des instructions SIMD complètes, chaque pixel étant traité en parallèle.
Les GPU modernes disposent d'une flopée d'unités de calcul SIMD identiques, à savoir qu'elles calculent des instructions SIMD complètes, chaque pixel étant traité en parallèle.
Ligne 140 : Ligne 140 :
====Une forme limitée d’exécution dans le désordre====
====Une forme limitée d’exécution dans le désordre====


L'unité de texture est située dans le processeur de shaders, à coté des unités de calcul. L'unité de texture peut fonctionner en parallèle des unités de calcul, comme toute unité d'accès mémoire. Ainsi, on peut poursuivre l’exécution du shader en parallèle de l'accès mémoire, à condition que les calculs soient indépendants de la donnée lue. Dans ces conditions, un shader peut masquer a latence de l'acccès mémoire en exécutant une grande quantité d'instructions à exécuter en parallèle : si un accès mémoire dure 200 cycles d'horloge, le processeur de shader doit disposer de 200 instructions à exécuter pour masquer totalement l'accès à la texture. De plus, le shader effectue souvent plusieurs accès mémoire assez rapprochés : si l'unité de texture ne peut pas gérer plusieurs lectures en parallèle, la lecture la plus récente est mise en attente et bloque toutes les instructions qui la suivent.
L'unité de texture est située dans le processeur de shaders, à côté des unités de calcul. L'unité de texture peut fonctionner en parallèle des unités de calcul, comme toute unité d'accès mémoire. Ainsi, on peut poursuivre l’exécution du shader en parallèle de l'accès mémoire, à condition que les calculs soient indépendants de la donnée lue. Dans ces conditions, un shader peut masquer a latence de l'acccès mémoire en exécutant une grande quantité d'instructions à exécuter en parallèle : si un accès mémoire dure 200 cycles d'horloge, le processeur de shader doit disposer de 200 instructions à exécuter pour masquer totalement l'accès à la texture. De plus, le shader effectue souvent plusieurs accès mémoire assez rapprochés : si l'unité de texture ne peut pas gérer plusieurs lectures en parallèle, la lecture la plus récente est mise en attente et bloque toutes les instructions qui la suivent.


====Multi-threading matériel====
====Multi-threading matériel====

Version du 27 mai 2020 à 13:49

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 géométriques, autrefois câblées, sont devenues des unités programmables. Les unités de traitement de la géométrie deviennent donc des processeurs indépendants, capable d’exécuter des programmes sur des vertices. Ces programmes sont appelés des Vertex Shaders. Par la suite, 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 seconde série d'unités a alors été ajoutée dans nos cartes graphiques : les processeurs de pixels shaders. Ils fonctionnent sur le même principe que les processeurs de vertex shaders, mais leur jeu d'instruction était quelque peu différent. Les premières cartes graphiques avaient des jeux d'instructions séparés pour les unités de vertex shader et les unités de pixel shader et les processeurs étaient séparés. Depuis DirectX 10, ce n'est plus le cas : le jeu d'instructions a été unifié entre les vertex shaders et les pixels shaders.

Jeu d'instruction

Les shaders sont souvent écrits dans un langage de haut-niveau : le HLSL pour les shaders Direct X et le GLSL pour les shaders Open Gl. Ils sont traduits (compilés) à la volée 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 à chaque version de Direct X ou d'Open Gl, et le matériel en a fait autant. Les premiers processeurs de shaders disposaient de peu d'instructions. On trouvait uniquement des instructions de calcul 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 fonction ;
  • 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.

Jeu d'instruction

Sur tous les processeurs de traitement de vertices, il est possible de traiter plusieurs morceaux de vertices à la fois. Même chose pour les processeurs de pixels shaders, qui peuvent traiter plusieurs pixels à la fois. Ces processeurs sont dit parallèles, à savoir qu'ils peuvent faire plusieurs calculs en parallèle dans des unités de calcul séparées. Il existe plusieurs types de processeurs de shaders, qui se distingue par la manière dont les calculs sont faits en parallèle :

  • les processeurs SIMD et VLIW, avec un parallélisme au niveau du jeu d'instruction ;
  • les processeurs scalaires, sans parallélisme (du moins, au niveau du jeu d'instruction).

Les processeurs VLIW étaient autrefois utilisés sur les anciennes RADEON d'AMD, mais ne sont plus vraiment utilisées aujourd'hui, la mode étant aux processeurs SIMD ou scalaires. Nous parlerons des processeurs SIMT dans la section sur la microarchitecture, ceux-ci ayant un jeu d'instruction non-parallèle, mais convertissent les instructions séries en instructions parallèles à la volée.

Processeurs SIMD

Les instructions des processeurs SIMD sont des instructions vectorielles : elles travaillent sur des vecteurs, des ensembles de plusieurs nombres entiers ou nombres flottants placés les uns à côté des autres, le tout ayant une taille fixe. 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 placer le résultat dans un autre vecteur, à 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.

Instructions SIMD

La première carte graphique commerciale destinée aux gamers à disposer d'une unité de vertex programmable est la Geforce 3. Celui-ci respectait le format de vertex shader 1.1. L'ensemble des informations à savoir sur cette unité est disponible dans l'article "A user programmable vertex engine", disponible sur le net. Le processeur de cette carte était capable de gérer un seul type de données : les nombres flottants de norme IEEE754. Toutes les informations concernant la coordonnée d'une vertice, voire ses différentes couleurs, doivent être encodées en utilisant ces flottants. De nos jours, les processeurs de vertices sont capables de gérer des nombres entiers, et les instructions qui vont avec. Ce processeur est capable d’exécuter 17 instructions différentes. Voici la liste de ces instructions :

OpCode Nom Description
MOV Move vector -> vector
MUL Multiply vector -> vector
ADD Add vector -> vector
MAD Multiply and add vector -> vector
DST Distance vector -> vector
MIN Minimum vector -> vector
MAX Maximum vector -> vector
SLT Set on less than vector -> vector
SGE Set on greater or equal vector -> vector
RCP Reciprocal scalar-> replicated scalar
RSQ Reciprocal square root scalar-> replicated scalar
DP3 3 term dot product vector-> replicated scalar
DP4 4 term dot product vector-> replicated scalar
LOG Log base 2 miscellaneous
EXP Exp base 2 miscellaneous
LIT Phong lighting miscellaneous
ARL Address register load miscellaneous

Comme on le voit, ces instructions sont presque toutes des instructions arithmétiques : multiplications, additions, exponentielles, logarithmes, racines carrées, etc. À côté, on trouve des comparaisons (SDE, SLT), une instruction MOV qui déplace le contenu d'un registre dans un autre, et une instruction de calcul d'adresse. Fait intéressant, toutes ces instructions peuvent s’exécuter en un seul cycle d'horloge. On remarque que parmi toutes ces instructions arithmétiques, la division est absente. Il faut dire que la contrainte qui veut que toutes ces instructions s’exécutent en un cycle d'horloge pose quelques problèmes avec la division, qui est une opération plutôt lourde en hardware. À la place, on trouve l'instruction RCP, capable de calculer 1/x, avec x un flottant. Cela permet ainsi de simuler une division : pour obtenir Y/X, il suffit de calculer 1/X avec RCP, et de multiplier le résultat par Y.

S'il n'y avait aucune instruction d'accès à la mémoire sur le processeur de la Geforce 3, la situation a changé depuis : les cartes graphiques récentes peuvent aller lire certaines données depuis la mémoire vidéo. Généralement, les shaders lisent des textures en mémoire vidéo, textures qui servent à colorier les pixels ou à configurer les calculs d'éclairage. Et la plupart des cartes graphiques suivant la Geforce 2 incorporait des instructions de lecture de texture. Les écritures, plus rares, sont venues après, afin de faciliter certaines techniques de rendu dont je ne parlerais pas ici.

Autre manque : les instructions de branchement. C'est un fait, ce processeur ne peut pas effectuer de branchements. À la place, il doit simuler ceux-ci en utilisant des instructions arithmétiques. C'est très complexe, et cela limite un peu les possibilités de programmation. À l'époque, ces branchements n'étaient pas utiles, sans compter que les environnements de programmation ne permettaient pas d'utiliser de branchements lors de l'écriture de shaders. De nos jours, les cartes graphiques récentes peuvent effectuer des branchements, ou du moins, des instructions similaires. On pourrait croire que l’absence de branchements pose problème, mais les concepteurs de processeur ont implémenté diverses solutions pour palier ce manque.

  • Certains processeurs utilisent des instructions à prédicats, des instructions "annulables" qui ne s’exécutent que si une condition est remplie.
  • D'autres instructions ne modifient un élément d'un vecteur que si celui-ci remplit une condition. Pour cela, le processeur de traitement de vertices contient un Vector Mask Register. Celui-ci permet de stocker 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 Vector Mask Register va stocker un bit pour chaque flottant présent dans le vecteur à traiter, bit qui indique s'il faut appliquer l'instruction sur ce flottant. 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.
Vector mask register

Processeurs VLIW

Sur les processeurs VLIW, les instructions sont regroupées dans ce qu'on appelle des Bundles, des sortes de super-instructions. Les instructions d'un bundle peuvent s'exécuter en parallèle sur différentes unités de calcul, mais le bundle est chargé en une seule fois depuis la mémoire. Chaque instruction d'un faisceau doit expliciter quelle unité de calcul doit la prendre en charge. Vu que chaque instruction sera attribué à une unité de calcul différente, le compilateur peut se débrouiller pour que les instructions dans un bundle soient indépendantes. Mais il se peut que le compilateur ne puisse pas remplir tout le bundle avec des instructions indépendantes. Sur les anciens processeurs VLIW, les bundles étaient de taille fixe, ce qui forçait le compilateur à remplir d'éventuels vides avec des NOP (des instructions qui ne font rien), diminuant la densité de code. La majorité des processeurs VLIW récents utilise des bundles de longueur variable, supprimant ces NOP.

Dans la majorité des cas, ces unités VLIW sont capables de traiter deux instructions arithmétiques en parallèles : 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.

Jeu de registres

Un processeur de shaders contient beaucoup de registres, sans quoi il ne pourrait pas faire son travail efficacement. Sur les processeurs de vertices des anciennes cartes 3D, il existait un grand nombre de registres spécialisés. Certains registres étaient spécialisés dans le stockage des vertices, d'autres dans le stockage des résultats de calculs, d'autres dans le stockage de constante, etc. Il y avait bien quelques registres généraux, sans fonction préétablie, mais ils étaient secondés par un grand nombre de registres spécialisés assez nombreux. De nos jours, ce n'est plus le cas : tous les registres sont banalisés et peuvent stocker toute donnée utile. Les registres spécialisés ont disparu. Le fait est que l'usage de registres spécialisés a perdu de son intérêt avec l'unification des shaders, certains registres n'ayant de sens que pour les vertices et rien d'autre.

Les registres des processeurs de vertices peuvent se classer en plusieurs types :

  • des registres généraux, qui peuvent mémoriser tout type de données ;
  • des registres d'entrée, qui réceptionnent les vertices ou pixels ;
  • des registres de sortie, dans lesquelles le processeur stocke ses résultats finaux ;
  • des registres de constantes qui, comme leur nom l'indique, servent à stocker des constantes.

Un processeur de vertices contenait, en plus des registres généraux, des registres de constantes pour stocker les matrices servant aux différentes étapes de transformation ou d'éclairage. 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 du registre de constante à utiliser s'effectue en utilisant un 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.

Architecture d'un processeur de shaders avec accès aux textures.

Microarchitecture

Outre le jeu d’instruction, la conception interne (aussi appelée microarchitecture) des processeurs de shaders possède quelques particularités idiosyncratiques. Rien de bien déroutant pou qui a déjà étudié les architectures à parallélisme de données, mais quelques rappels ou explications ne peuvent pas faire de mal.

Les cartes graphiques sont des architectures massivement parallèles, à savoir qu'elles sont capables de faire un très grand nombre de calculs simultanés, durant le même cycle d'horloge. Il faut dire que chaque vertice ou pixel peut être traité indépendamment des autres, ce qui rend le traitement 3D fortement parallèle. Cela a quelques conséquences sur le nombre de processeurs et d'unités de calcul, ainsi que sur la hiérarchie mémoire. L'architecture doit être conçue pour pouvoir effectuer un maximum de calculs en parallèle, quitte à simplifier fortement la puissance pour des calculs séquentiels (ceux qu'effectue un processeur). La hiérarchie mémoire doit aussi gérer un grand nombre d'accès mémoire simultanés : qui dit plein d'instructions en parallèle qui travaillent sur des données indépendantes dit aussi plein de données indépendantes à lire ou écrire !

L'architecture d'une carte grahique récente est illustrée ci-dessous. On y voit plusieurs caractéristiques typiques : un grand nombre de processeurs/cœurs, un grand nombre d'unités de calculs par cœur, et une hiérarchie mémoire assez étagée avec des mémoires locales en complément de la mémoire vidéo principale.

Ce schéma illustre l'architecture d'un GPU en utilisant la terminologie NVIDIA. Comme on le voit, la carte graphique contient plusieurs cœurs de processeur distincts. Chacun d'entre eux contient plusieurs unités de calcul généralistes, appelées processeurs de threads, qui s'occupent de calculs simples (en bleu). D'autres calculs plus complexes sont pris en charge par une unité de calcul spécialisée (en rouge). Ces cœurs sont alimentés en instructions par le processeur de commandes, ici appelé Thread Execution Control Unit, qui répartit les différents shaders sur chaque cœur. Enfin, on voit que chaque cœur a accès à une mémoire locale dédiée, en plus d'une mémoire vidéo partagée entre tous les cœurs.

Un grand nombre de processeurs et d'unités de calculs

Comparaison du nombre de processeurs et de cœurs entre CPU et GPU.

Pour profiter au mieux des opportunités de parallélisme, une carte graphique contient de nombreux processeurs, qui eux-mêmes contiennent plusieurs unités de calcul. Savoir combien de cœurs contient une carte graphique est cependant compliqué, les services marketing gardant un certain flou sur le sujet. Il n'est pas rare que ceux-ci appellent cœurs ou processeurs de simples unités de calcul, histoire de gonfler les chiffres. Et on peut généraliser à la majorité de la terminologie utilisée par les fabricants, que ce soit pour les termes warps processor, ou autre, qui ne sont pas aisés à interpréter. D'ordinaire, ce qui est appelé processeur de thread sur une carte graphique correspond en réalité à une unité de calcul.

Vu le grand nombre d'unités de calcul, les autres circuits ne peuvent pas trop prendre de place. En conséquence, les unités de décodage et/ou de contrôle sont relativement simples, peu complexes. Leurs fonctionnalités sont limitées au strict minimum, avec cependant quelques optimisations sur les cartes graphiques récentes. On n'y retrouve pas les fioritures des CPU modernes, tant utiles pour du calcul séquentiel : pas d’exécution dans le désordre, de renommage de registres, et autres techniques avancées.

Comparaison entre l'architecture d'un processeur généraliste et d'un processeur de shaders.

Des unités de calcul autrefois spécialisée, puis devenus banalisées

Même les premiers processeurs de shaders disposaient de plusieurs unités de calculs séparées, capables de faire des calculs en parallèle. Un bon exemple est le processeur de vertices de la Geforce 6800, illustré ci-dessous. On voit que le processeur contient trois unités de calculs séparées : une unité généraliste de calcul sur les vertices, une unité pour les opérations mathématiques complexes (division, racine carrée, racine carrée inverse, autres) et enfin une unité pour le calcul Multiply-And-Add (une multiplication suivie d'une addition, opération très courante en 3D). On voit que les unités de calculs sont assez spécialisées, avec une ou plusieurs unités généralistes, secondée par des unités capables de faire des calculs spécialisés.

Processeur de shader (vertex shader) d'une GeForce 6800. On voit clairement que celui-ci contient, outre les traditionnelles unités de calcul et registres temporaires, un "cache" d'instructions, des registres d'entrée et de sortie, ainsi que des registres de constante.

Cela n'a pas changé avec l'unification des shaders, si ce n'est que les unités de calcul ne sont pas aussi spécialisées que dans l'exemple précédent. De nos jours, les unités de calculs dédiées à des opérations bien précises sont plus rares. On ne trouve plus d'unité spécialisée pour les opérations complexes, comme dans l'exemple précédent, de telles opérations pouvant être émulées par une suite d'opérations plus simples. Au lieu de mettre une unité spécialisée utile pour une opération sur 10/20, autant mettre une unité généraliste pour accélérer les calculs simples et fréquents, quitte à émuler les calculs complexes. De plus, les unités de calculs sont devenues beaucoup plus nombreuses.

Les GPU modernes disposent d'une flopée d'unités de calcul SIMD identiques, à savoir qu'elles calculent des instructions SIMD complètes, chaque pixel étant traité en parallèle.

Unités de calculs SIMD.

Mitigation de la latence mémoire

Tous les pixels doivent accéder à une texture pour être coloriés, certains traitements devant être effectués ensuite par un pixel shader. Mais un accès à une texture, c'est long : une bonne centaine de cycles d'horloges lors d'un accès à une texture est un minimum si celle-ci est lue depuis la mémoire vidéo. Pour éviter que le processeur de shaders attende la mémoire, celui-ci dispose de techniques élaborées.

Une forme limitée d’exécution dans le désordre

L'unité de texture est située dans le processeur de shaders, à côté des unités de calcul. L'unité de texture peut fonctionner en parallèle des unités de calcul, comme toute unité d'accès mémoire. Ainsi, on peut poursuivre l’exécution du shader en parallèle de l'accès mémoire, à condition que les calculs soient indépendants de la donnée lue. Dans ces conditions, un shader peut masquer a latence de l'acccès mémoire en exécutant une grande quantité d'instructions à exécuter en parallèle : si un accès mémoire dure 200 cycles d'horloge, le processeur de shader doit disposer de 200 instructions à exécuter pour masquer totalement l'accès à la texture. De plus, le shader effectue souvent plusieurs accès mémoire assez rapprochés : si l'unité de texture ne peut pas gérer plusieurs lectures en parallèle, la lecture la plus récente est mise en attente et bloque toutes les instructions qui la suivent.

Multi-threading matériel

Trouver suffisamment d’instructions indépendantes d'une lecture dans un shader n'est donc pas une chose facile. Les améliorations au niveau du compilateur de shaders des drivers peuvent aider, mais la marge est vraiment limitée. Pour trouver des instructions indépendantes d'une lecture en mémoire, le mieux est encore d'aller chercher dans d'autres shaders… Sans la technique qui va suivre, chaque shader correspond à un programme qui s’exécute sur toute une image. Avec les techniques de multi-threading matériel, chaque shader est dupliqué en plusieurs copies indépendantes, des threads, qui traitent chacun un morceau de l'image. Un processeur de shader peut traiter plusieurs threads, et répartir les instructions de ces threads sur l'unité de calcul suivant les besoins : si un thread attend la mémoire, il laisse l'unité de calcul libre pour un autre.

SIMT

Les processeurs plus récents fonctionnent comme des processeurs SIMD au niveau de l'unité de calcul, mais ce fonctionnement est masqué au niveau du jeu d'instruction. Ces processeurs poussent la logique des threads jusqu'au bout : chaque instance de shader (thread) ne manipule qu'un seul pixel ou vertex. Ces threads sont rassemblés en groupes de 16 à 32 threads qui exécutent la même instruction, en même temps, mais sur des pixels différents. En clair, ces processeurs vont découvrir à l’exécution qu'ils peuvent exécuter la même instruction sur des pixels différents, et fusionner leurs instructions en instructions vectorielles. L'instruction vectorielle née de cette fusion est appelée un warp. On parle de Single Instruction Multiple Threads.

Chaque thread se voit attribuer un Program Counter, des registres, et un identifiant qui permet de l'identifier parmi tous les autres. Un circuit spécialisé fusionne les pixels des threads en vecteurs qu'il distribue aux unités de calcul. Sur certaines cartes graphiques récentes, le processeur peut démarrer l'exécution de plusieurs warps à la fois. Il faut noter que si un branchement ne donne pas le même résultat dans différents threads d'un même warp, le processeur se charge d'effectuer la prédication en interne : il utilise quelque chose qui fait le même travail que des instructions de prédication qui utilisent vector mask register. Dans ce cas, chaque thread est traité un par un par l'unité de calcul. Ce mécanisme se base sur une pile matérielle qui mémorise les threads à exécuter, dans un certain ordre.