processeurs graphiques et pipeline

I M N 6 3 8 – C H A P I T R E 2 M O D U L E 1 PROCESSEURS GRAPHIQUES ET PIPELINE Automne 2014 – Université de Sherbrooke Olivier Vaillancourt, Olivier Godin 2014-­‐09-­‐26 1 2014-­‐09-­‐26 PROCESSEURS GRAPHIQUES ET PIPELINE Sommaire •  Introduc1on •  Concept de pipeline •  Étude détaillée du pipeline graphique •  Ges1on de la mémoire vidéo •  Architectures graphiques •  Étude de cas 2 2014-­‐09-­‐26 Ce chapitre porte sur l’étude détaillée des composantes bas niveau d’un système de rendu. On pense donc à l’étude du fonc1onnement précis d’un pipeline graphique, l’étude des mécanismes et systèmes matériels impliqués dans le rendu 3D en temps réel, et l’étude des diverses architectures graphiques u1lisées pour le rendu en temps réel. Comprendre le fonc1onnement interne d’un disposi1f de rendu en temps réel est primordial pour pouvoir construire et maintenir des applica1ons 3D interac1ves performantes, efficaces et durables. Dans ceNe op1que, comprendre les technologies de base qui cons1tuent ces disposi1fs devrait devenir un réflexe pour tout programmeur spécialisé en rendu 3D. 3 PROCESSEURS GRAPHIQUES ET PIPELINE IntroducJon CONCEPT DE PIPELINE 2014-­‐09-­‐26 4 2014-­‐09-­‐26 Le pipeline de rendu est considéré comme étant le chemin directeur et central d’un système de rendu en temps réel. La fonc1on principale du pipeline est de générer, ou rendre une image bidimensionnelle à par1r d’informa1ons géométriques tridimensionnelle ou bidimensionnelle. On parle souvent de pipeline de rendu en faisant référence aux étapes qui le cons1tuent sans nécessairement s’aNarder au concept théorique d’un pipeline. Ceci étant dit, le choix d’une architecture en pipeline demeure un élément déterminant qui affecte toutes les étapes du rendu. Les no1ons propres à un pipeline deviennent aussi intéressantes à étudier dans la mesure où ces dernières permeNent de mieux comprendre les contraintes et faiblesses d’un processus de rendu en temps réel. En combinant les no1ons de pipeline à une compréhension matérielle des systèmes de rendu 3D, il devient facile d’analyser un logiciel afin de déterminer où l’effort d’op1misa1on doit être concentré afin de garan1r des rendus complexes en temps interac1f. 5 PROCESSEURS GRAPHIQUES ET PIPELINE Concept de pipeline 2014-­‐09-­‐26 Le concept de pipeline n’est pas uniquement raNaché à l’infographie. En effet, plusieurs exemples de pipeline peuvent être trouvés dans la vie de tous les jours, notamment dans les chaînes d’assemblage en usine ou dans les canalisa1ons de transport d’hydrocarbure. En tout et pour tout, un pipeline, au sens théorique, est une chaîne de traitement ou de transport consJtuée de plusieurs étapes travaillant simultanément sur des instances séparées d’un produit similaire. En prenant, par exemple, un pipeline de construc1on de voiture (une chaîne d’assemblage), la voiture à la première étape de construc1on se déplace à la deuxième étape lorsque la voiture de la deuxième étape est prête à passer à la troisième étape, et ainsi de suite. À tout moment, dans le pipeline de montage, plusieurs voitures sont en construc1on, même si seulement un nombre réduit d’entre elles sort à chaque moment de la chaîne. 6 PROCESSEURS GRAPHIQUES ET PIPELINE Concept de pipeline 2014-­‐09-­‐26 Dans un processus chaîné sans pipeline, le désavantage principal est que le système doit aNendre qu’un élément ait traversé chaque étape avant d’y faire entrer un nouvel élément. Le temps de construc1on d’un nombre n d’éléments est donc équivalent à la somme des durées de chaque étape mul1pliées par n. Par exemple, si nous avons un système de construc1on possédant 3 étapes et que c h a q u e é t a p e p r e n d exactement 1 minute à être réalisée, un item sera produit toutes les 3 minutes. 7 PROCESSEURS GRAPHIQUES ET PIPELINE Concept de pipeline 2014-­‐09-­‐26 L’avantage principal d’un système en pipeline est que chaque étape, bien qu’effectuée séquen1ellement, demeure effectuée parallèlement aux autres étapes. Autrement dit, il n’est pas nécessaire d’aNendre qu’un élément soit sor1 de la chaine avant d’en insérer un nouveau. Dès qu’une étape se libère et qu’un item peut être envoyé à ceNe étape, celle-­‐ci se remet à fonc1onner. Si on reprend l’exemple précédent, chaque étape dure une minute . Après une période d’ini1alisa1on de durée équivalente à la s o m m e d e t e m p s d e chaque étape, le pipeline arrive à sor1r un item chaque minute. 8 PROCESSEURS GRAPHIQUES ET PIPELINE7 Concept de pipeline 2014-­‐09-­‐26 PROCESSEURS GRAPHIQUES ET PIPELINE Concept de pipeline Dans un pipeline, l’étape la plus lente détermine la vitesse globale du pipeline. Par exemple, si un pipeline possède 3 étapes où la première prend 1 minute, la deuxième 2 minutes et la troisième 1 minute, la deuxième étape ne fournira pas suffisamment d’items à la troisième. Elle bloquera aussi la première étape qui devra aNendre que l’item de la deuxième étape soit traité avant de pouvoir envoyer son propre item vers l’étape suivante. Dans un pipeline, une étape ne traitant aucun item, car elle est en aNente d’une étape précédente est dite en famine. Une étape ralen1ssant les étapes précédentes par sa lenteur est appelée un goulot d’étranglement. Dans l’exemple ci-­‐contre, l’étape 2 prends 2 m i n u t e s , c e c i c r é e u n g o u l o t d’étranglement et place l’étape 3 en famine 50% du temps. Le système ne produit plus qu’un seul item toutes les 2 minutes. 9 2014-­‐09-­‐26 Il existe différentes méthodes pour absorber ou éliminer l’effet des goulots d’étranglement. Une technique courante, et c’est celle u1lisée dans un pipeline graphique, est de paralléliser la ou les étapes les plus lentes pour que plusieurs instances de ces mêmes étapes s’effectuent simultanément sur des instances différentes d’items. Une autre méthode pour réduire les famines et les goulots d’étranglement est de placer des « tampons » pouvant accumuler temporairement des items en traitement et ainsi éviter la stagna1on d’étapes plus rapide. Ceci ne fait cependant que reporter le problème plus loin dans le pipeline, mais devient u1le lorsqu’une étape peut changer de fonc1on si elle est en aNente. 10 PROCESSEURS GRAPHIQUES ET PIPELINE Concept de pipeline 2014-­‐09-­‐26 Les considéra1ons précédemment présentées pour un pipeline se traduisent telles quelles dans un contexte de pipeline graphique. Dans un pipeline graphique, les différentes étapes du pipeline traitent de l’informa1on de géométrie ou de couleur. Le produit du pipeline est une couleur donnée pour un pixel par1culier. Au même 1tre que tout pipeline, un pipeline graphique possède des goulots d’étranglement, des potenJels de famine et certaines étapes de traitement effectuées en parallèle. L’étape la plus lente du pipeline graphique déterminera la vitesse d’exécuJon du rendu, soit le nombre d’images par secondes produites par votre carte graphique. Ce goulot d’étranglement peut se trouver à différents endroits dans le pipeline selon le type de scène rendue et l’architecture du processeur graphique. Savoir isoler l’emplacement du goulot d’étranglement dans le pipeline permeNra souvent d’augmenter conséquemment les performances de rendu. 11 PROCESSEURS GRAPHIQUES ET PIPELINE Concept de pipeline ÉTUDE DÉTAILLÉE DU PIPELINE GRAPHIQUE 2014-­‐09-­‐26 12 2014-­‐09-­‐26 Le pipeline graphique d’une carte vidéo moderne possède en moyenne entre 110 et 150 étapes de traitement différentes (ce nombre d’étapes peut monter à plusieurs milliers dans les systèmes de rendus dédiés). La plupart de ces étapes étant triviales et complètement transparentes au développeur, on divise habituellement le pipeline graphique en étapes conceptuelles, ces dernières englobant une série d’étapes foncJonnelles, qui elles englobent les étapes réelles du pipeline. Ces dernières sont abstraites, car trop nombreuses et différentes d’une carte à l’autre pour être détaillée dans un temps raisonnable. Étapes conceptuelles du pipeline graphique, respec1vement : étape d’applica1on, étape de géométrie, étape de rastérisa1on (RTR3, p.13, 2008) 13 PROCESSEURS GRAPHIQUES ET PIPELINE Étude détaillée du pipeline graphique 2014-­‐09-­‐26 •  ApplicaJon : L’étape d’applica1on s’exécute sur le processeur central de l’ordinateur. C’est dans ceNe étape que le développeur fournit à la carte graphique, via l’API de programma1on et les pilotes vidéos, l’informaJon géométrique à rendre et la configuraJon des états de la carte vidéo. Le pilote vidéo est une couche logicielle permeNant le passage entre l’étape d’applica1on et l’étape de géométrie. •  Géométrie : L’étape de géométrie est exécutée à l’intérieur du processeur graphique. Elle est cons1tuée des manipula1ons et transforma1ons géométriques effectuées sur chaque vertex envoyé à la carte graphique. •  RastérisaJon : L’étape de rastérisa1on est aussi effectuée à l’intérieur du processeur graphique. Elle consiste à converJr l’informaJon vectorielle (vertex, normales, coordonnées de textures) en fragments et en pixels pour obtenir un rendu final. 14 PROCESSEURS GRAPHIQUES ET PIPELINE Étapes conceptuelles du pipeline graphique 2014-­‐09-­‐26 Les acétates qui suivent effectueront une étude détaillée des différentes étapes du pipeline graphique. La théorie générale d’un pipeline graphique a déjà été vue dans le cours IMN428 (infographie), certaines étapes seront donc très brièvement résumées. Certaines étapes, plus complexes, seront abordées avec une plus grande précision. Notons que l’étape conceptuelle d’applica1on a déjà été abordée en détail en IMN428 (infographie), nous débuterons donc directement à l’étape de géométrie. 15 PROCESSEURS GRAPHIQUES ET PIPELINE Étude détaillée du pipeline graphique 2014-­‐09-­‐26 L’étape de géométrie du pipeline se divise en 5 étapes fonc1onnelles, soit : •  Transforma1on modèle-­‐vue •  Éclairage et teinte des vertex •  Projec1on •  Tronquage (clipping) de vision •  Conversion en coordonnées fenêtres Étapes de fonc1onnelles du pipeline géométrique. (Real-­‐Time rendering 3, p.16, 2008) 16 PROCESSEURS GRAPHIQUES ET PIPELINE Étude détaillée du pipeline graphique 2014-­‐09-­‐26 TransformaJon modèle-­‐vue : CeNe étape consiste simplement à mul1plier chaque vertex envoyé au processeur graphique par la matrice modèle-­‐vue spécifiée au moment de l’entrée du vertex dans la carte vidéo. Notons que la matrice modèle-­‐
vue est la combinaison de la matrice « modèle », permeNant de passer de l’espace objet à l’espace monde, et de la matrice « vue », représentant le mouvement de la caméra (permeNant de passer de l’espace monde à l’espace caméra). Note: Ces matrices sont purement conceptuelles même si elles sont groupées dans un contexte de pipeline de rendu fixe. La no1on de matrice modèle-­‐vue disparaît dans un pipeline programmable. Éclairage et teinte des vertex: CeNe étape consiste à appliquer le calcul des informa1ons par vertex qui seront interpolées lors de la rastérisa1on. Ces informa1ons englobent, par exemple, l’éclairage, la couleur du vertex ou le calcul des coordonnées de texture. 17 PROCESSEURS GRAPHIQUES ET PIPELINE Étude détaillée du pipeline graphique : étape de géométrie 2014-­‐09-­‐26 ProjecJon : La projec1on consiste à prendre les vertex en espace caméra (transformés à l’étape de la transforma1on modèle-­‐vue) et de les transformer, à l’aide de la matrice de projec1on, vers un espace normalisé cubique. Les limites de cet espace sont de (-­‐1,-­‐1,-­‐1) à (1,1,1) sous OpenGL et (-­‐1,-­‐1,0) à (1,1,1) sous Direct3D. Après la transforma1on de projec1on, les coordonnées des vertex sont dites être en coordonnées normalisées d’affichage. Notons aussi que la projec1on doit idéalement tenir compte de la dimension du canevas d’affichage en pixels afin de s’assurer que le passage des vertex en fragments, plus tard dans le pipeline, correspondra aux bonnes coordonnées pixel. Dans tous les cas, la sorJe de cebe étape demeure une coordonnée homogène, ce n’est qu’à l’étape de conversion en coordonnées fenêtres que les composantes inu1les des vertex sont enlevées.les trois premières étapes géométriques Notons que les trois étapes précédentes sont des étapes dites programmables, car elles peuvent être remplacées par un nuanceur (shader). Plus d’informa1on sur les nuanceurs seront données au chapitre suivant. 18 PROCESSEURS GRAPHIQUES ET PIPELINE Étude détaillée du pipeline graphique : étape de géométrie 2014-­‐09-­‐26 Tronquage de vision : CeNe étape consiste à éliminer tous les éléments situés à l’extérieur du cube unitaire créé à l’étape de projec1on. En effet, la totalité des éléments que l’u1lisateur pourra voir dans la scène se trouve dans ce volume en par1culier. Les éléments à l’extérieur n’ont pas besoin d’être rendus, car ils se trouvent à l’extérieur du champ de vision. On tronque donc les éléments en ques1on. Plus important encore, notons que le tronquage de vision s’effectue à ce moment dans le pipeline graphique parce qu’il permet de rendre le problème de tronquage consistant. En effet, le tronquage est toujours effectué par rapport à un cube de vision unitaire, ce qui permet un calcul plus rapide du tronquage que s’il était effectué plus tôt dans le pipeline. (Les calculs sont op1misés du fait qu’on travaille toujours avec un volume unitaire ou demi-­‐unitaire aligné.) Notons aussi qu’il ne peut être effectué avant dans une carte vidéo moderne puisque le nuanceur (shader) de vertex peut modifier la posi1on de ceux-­‐ci dans l’espace, ce qui modifierait aussi leur posi1on dans le volume de vision normalisé, modifiant par le fait même le tronquage. 19 PROCESSEURS GRAPHIQUES ET PIPELINE Étude détaillée du pipeline graphique : étape de géométrie 2014-­‐09-­‐26 Conversion en coordonnées fenêtre : La conversion en coordonnées fenêtre consiste simplement à prendre le volume de vision et à faire correspondre chaque vertex du volume de projec1on normalisé à un pixel. Pour ce faire, on prend la coordonnée x et y normalisée qu’on associe au bon pixel en tenant compte des dimensions du canevas d’affichage. La coordonnée en z est ignorée pour ceNe étape, mais sera u1lisée pour l’inscrip1on de la profondeur dans le tampon-­‐z. Un élément intéressant à étudier au niveau de la conversion en coordonnées fenêtres est la règle u1lisée pour faire correspondre une posi1on (x,y) normalisée à un pixel en par1culier. En effet, la conven1on change d’une librairie graphique à l’autre, ce qui en fait un détail important à aborder dans un contexte de 3D en temps réel. 20 PROCESSEURS GRAPHIQUES ET PIPELINE Étude détaillée du pipeline graphique : étape de géométrie 2014-­‐09-­‐26 Sous D3D9 et les versions précédentes de Direct3D, le système de coordonnées d’un pixel est centré à (0,0). Autrement dit, un pixel est défini de (-­‐0.5,-­‐0.5) à (0.5,0.5), le centre étant (0,0). Ceci signifie qu’une série de pixels allant de [0,9] englobera les vertex du volume de vision allant de la coordonnée [-­‐0.5,9.5] en espace fenêtre. La même conven1on existe aussi pour l’applica1on des textures. Pour appliquer une texture au pixel près sur les coins d’un polygone, il faut donc calculer ½ pixel de décalage aux extrémités dans les coordonnées uv (0.5 × 1/dimension). Par exemple, une texture de 4 × 4 pixels projetée sur un carré doit avoir une coordonnée uv de son coin supérieur gauche à (0.125,0.125) pour être correctement associée et aligné avec le vertex supérieur gauche. 21 PROCESSEURS GRAPHIQUES ET PIPELINE Étude détaillée du pipeline graphique : étape de géométrie Conversion en coordonnées fenêtres pour Direct3D 9 et ses prédécesseurs : 2014-­‐09-­‐26 Dans le cas d’OpenGL, D3D10 et ses successeurs, la coordonnée (0,0) d’un pixel correspond au coin supérieur gauche de celui-­‐ci. Un pixel va donc de la coordonnée (0,0) à la coordonnée (1,1). Notre même série de pixels allant de [0,9] correspondra donc à l’intervalle [0,10] dans notre système de rendu. En va de même pour les textures, ce qui évite le calcul décrit à l’acétate précédent. 22 PROCESSEURS GRAPHIQUES ET PIPELINE Étude détaillée du pipeline graphique : étape de géométrie Conversion en coordonnées fenêtre pour OpenGL, Direct3D 10 et ses successeurs : 2014-­‐09-­‐26 L’étape conceptuelle de rastérisaJon se divise quant à elle en quatre étapes fonc1onnelles : •  Prépara1on des triangles •  Rastérisa1on des triangles •  Colora1on des pixels •  Combinaison Étapes fonc1onnelles du pipeline de rastérisa1on. (Real-­‐Time Rendering, p22, 2008) 23 PROCESSEURS GRAPHIQUES ET PIPELINE Étude détaillée du pipeline graphique : étape de rastérisaJon 2014-­‐09-­‐26 PréparaJon des triangles : CeNe étape sert à générer des données d’interpola1on et à précalculer des données u1lisées dans l’étape qui suivra. Elle est complètement intégrée au matériel du processeur graphique et s’effectue automa1quement. Elle dépend énormément de la structure interne du processeur graphique et de l’organisa1on de ses tampons de mémoire temporaires. De ce fait, elle dépend donc beaucoup du modèle et du constructeur du processeur graphique. Le développeur n’a naturellement pas de contrôle sur ceNe étape et elle demeure transparente à celui-­‐ci. RastérisaJon : La rastérisa1on des triangles consiste à prendre les triangles et à les conver1r en fragments. Pour chaque fragment généré, on lui associe les données des vertex correspondants après les avoir interpolées. (Coordonnées textures, normale, couleur, etc.) Ces informa1ons seront u1lisées à l’étape suivante. Note: On parle ici de fragments plutôt que de pixels, car l’écriture de ces derniers dans le tampon image n’est pas encore garan1e. 24 PROCESSEURS GRAPHIQUES ET PIPELINE Étude détaillée du pipeline graphique : étape de rastérisaJon 2014-­‐09-­‐26 ColoraJon des pixels : Les deux étapes précédentes sont directement intégrées et effectuées dans les circuits imprimés dédiés du processeur graphique. Contrairement à ces dernières, la colora1on des pixels est habituellement programmable et s’effectue à l’aide d’un nuanceur de fragment (fragment shader). C’est à ceNe étape que s’effectue la colora1on finale du pixel, en fonc1on des données fournies par la rastérisa1on, par les textures, etc. Note: Malgré le nom de l’étape, on parle encore ici de fragments plutôt que de pixels. 25 PROCESSEURS GRAPHIQUES ET PIPELINE Étude détaillée du pipeline graphique : étape de rastérisaJon 2014-­‐09-­‐26 Combinaison : La dernière et plus importante étape du pipeline de rastérisa1on est l’étape de combinaison. Dans ceNe étape se résolvent plusieurs éléments au niveau de la visibilité et de l’affichage, et s’inscrivent plusieurs informa1ons dans les différents tampons de mémoire de la carte vidéo. On compte notamment : •  Test pochoir et écriture dans le tampon pochoir (stencil buffer). •  Test de visibilité et écriture dans le tampon-­‐z (Z-­‐buffer) •  Mélange de couleur et écriture dans le tampon de couleur (blending). •  Écriture dans le canal de couleur de transparence si applicable. Si un fragment passe les tests pochoir et le test de visibilité du tampon-­‐z, il est écrit dans le tampon de couleur. C’est uniquement à ce moment que le fragment devient un pixel. Avant de poursuivre, regardons en détail les possibilités d’u1lisa1on des éléments précédents. 26 PROCESSEURS GRAPHIQUES ET PIPELINE Étude détaillée du pipeline graphique : étape de rastérisaJon 2014-­‐09-­‐26 Comme il a été vu en infographie, le Tampon-­‐Z sert à stocker l’informa1on de profondeur de chaque pixel déjà rendu. Si un nouveau pixel à rendre échoue le test de profondeur, il ne sera simplement pas rendu. Si le pixel à rendre réussit ce même test, il sera rendu en fonc1on des paramètres de mélange fournis à la carte vidéo. L’u1lisa1on du Tampon-­‐Z pour la 3D en temps réel peut être configurée de trois manières différentes : 1.  Ac1va1on/Désac1va1on du test de profondeur 2.  Ac1va1on/Désac1va1on de l’écriture dans le tampon-­‐z 3.  Modifica1on de la condi1on de passa1on du test de profondeur (plus grand que, égal, jamais, toujours, etc.) En jouant avec ces op1ons de configura1on, il est possible d’obtenir différents effets lors du rendu. Notons que le tampon-­‐z peut être reconfiguré de différentes façons à l’intérieur du rendu d’une même image. 27 PROCESSEURS GRAPHIQUES ET PIPELINE Encart : Tampon-­‐Z (Z-­‐Buffer) 2014-­‐09-­‐26 à notre scène. Tous les autres éléments de la scène doivent être rendus par-­‐dessus la texture d’arrière-­‐plan. SoluJon : 1.  Réini1aliser le tampon-­‐z. 2.  Désac1ver l’écriture dans le tampon-­‐z et le test de profondeur. 3.  Rendre la texture de fond. 4.  Réac1ver l’écriture dans le tampon-­‐z et le test de profondeur 5.  Rendre le reste de la scène. ExplicaJon : Le tampon-­‐z reste ini1alisé à 0 même à l’écriture de l’arrière-­‐plan. Tous les éléments rendus par la suite, même avec le test et l’écriture ac1vés sont donc rendus devant l’arrière-­‐plan. De plus, le fait de laisser le tampon-­‐z ini1alisé à 0 permet certaines op1misa1ons du test de profondeur qui ne seraient pas possibles si l’arrière-­‐plan avait été précédemment rendu avec une profondeur élevée. 28 PROCESSEURS GRAPHIQUES ET PIPELINE Encart : Tampon-­‐Z (Z-­‐Buffer) 1 -­‐ Exemple d’uJlisaJon avancée du tampon-­‐z : On souhaite rendre un arrière-­‐plan 2014-­‐09-­‐26 par1cules transparentes superposées dans un ordre quelconque tout en s’assurant que les objets opaques situés devant les par1cules les cachent bien. SoluJon : 1.  Ac1ver l’écriture dans le tampon-­‐z et le test de profondeur 2.  Rendre les objets opaques de la scène. 3.  Désac1ver l’écriture dans le tampon-­‐z mais garder le test de profondeur ac1vé. 4.  Ac1ver un mélanger addi1f des couleurs (couleur finale = couleur source + couleur des1na1on) 5.  Rendre les par1cules transparentes. ExplicaJons : Les par1cules se mélangent les unes aux autres indépendamment de leur profondeur puisque l’écriture dans le tampon-­‐z est désac1vée pour leur rendu. Elles sont néanmoins cachées par les éléments opaques puisque le test de profondeur demeure ac1vé et que les éléments opaques ont été précédemment rendus dans le tampon-­‐z. 29 PROCESSEURS GRAPHIQUES ET PIPELINE Encart : Tampon-­‐Z (Z-­‐Buffer) 2-­‐ Exemple d’uJlisaJon avancée du tampon-­‐z : On souhaite mélanger plusieurs 2014-­‐09-­‐26 Le mélange de couleur (blending) est une étape non programmable du pipeline graphique qui demeure néanmoins extrêmement flexible et configurable. Globalement, les op1ons de mélange de couleurs permeNent de configurer comment seront écrites les couleurs dans le tampon de couleur (frame buffer ou color buffer) par rapport aux couleurs qui y sont déjà présentes. Avant de se pencher sur le mélange en soit, il est important de garder en mémoire qu’un pixel, s’il échoue le test de profondeur, ne sera jamais rendu. Le mélange de couleur, dans un tel cas, ne sera pas effectué. Autrement dit, si un pixel est déjà présent dans le tampon de couleur avec une certaine transparence, et qu’un autre pixel doit être inscrit derrière celui-­‐ci, le pixel à inscrire échouera le test de profondeur et ne sera pas écrit, même si le pixel déjà présent est transparent. Dans ceNe op1que, les éléments transparents d’une scène doivent donc toujours être rendus après les éléments opaques, en partant de l’élément transparent le plus loin vers l’élément transparent le plus proche pour éviter des problèmes dans l’ordre de rendu. 30 PROCESSEURS GRAPHIQUES ET PIPELINE Encart : Mélange de couleur et écriture dans le tampon de couleurs 2014-­‐09-­‐26 qu’on rend un pixel bleu semi-­‐transparent en premier avec une certaine profondeur, il sera combiné avec le fond (par exemple noir). Si on tente par la suite de rendre un pixel non transparent derrière celui-­‐ci, à une profondeur plus grande, ce pixel ne sera jamais rendu, car il échouera le test de profondeur. Pour remédier à ce problème, on inverse l’ordre de rendu pour que le pixel transparent soit rendu après le pixel opaque. 31 PROCESSEURS GRAPHIQUES ET PIPELINE Encart : Mélange de couleur et écriture dans le tampon de couleurs Par exemple, si notre test de profondeur est de type « plus pe1t que » (less-­‐than), et 2014-­‐09-­‐26 Lorsque le mélange de couleur est ac1vé, le développeur possède un certain contrôle sur le type de mélange qu’il souhaite effectuer en spécifiant comment seront combinées les couleurs déjà dans le tampon de couleur (couleurs de des1na1on) et celles à écrire dans celui-­‐ci (couleurs sources). La formule générale pour déterminer quelle sera la couleur dans le tampon de couleur se définit telle que : Couleurs ∗ Facteurs + Couleurd ∗ Facteurd = CouleurFinale
Où Facteur et Couleur sont des vecteurs à 4 dimensions. L’astérisque (*) dénote une mul1plica1on point à point. 32 PROCESSEURS GRAPHIQUES ET PIPELINE Encart : Mélange de couleur et écriture dans le tampon de couleurs 2014-­‐09-­‐26 arbitrairement définis. Une série de facteurs disponibles est habituellement préconfigurée dans le processeur graphique et accessible au développeur via les API graphiques et le pilote vidéo. Des exemples de facteurs disponibles sont : •  (0,0,0,0) •  (1,1,1,1) •  (SrcR,SrcG,SrcB,SrcA) •  (DestR,DestG,DestB,DestA) •  (1-­‐SrcR,1-­‐SrcG,1-­‐SrcB,1-­‐SrcA) •  (SrcA,SrcA,SrcA,SrcA) •  etc. Par défaut, lorsque les objets opaques sont rendus et que le mélange est désac1vé, le facteur de la source est mis à (1,1,1,1) et le facteur de la des1na1on à (0,0,0,0), de ceNe façon, si un pixel passe le test de profondeur, sa couleur remplace automa1quement la couleur précédemment inscrite dans le tampon de couleur 33 PROCESSEURS GRAPHIQUES ET PIPELINE Encart : Mélange de couleur et écriture dans le tampon de couleurs Pour des raisons de performance, les facteurs de mélange ne peuvent être 2014-­‐09-­‐26 Le tampon pochoir est un ou1l très puissant servant dans l’accomplissement d’une mul1tude d’effets en infographie temps réel. Globalement, le tampon pochoir est un tampon similaire au tampon-­‐z contenant des en1ers posi1fs. Chaque fois qu’un pixel est prêt à être affiché, il est soumis à un test pochoir. Si le pixel échoue le test, il n’est pas envoyé au test de profondeur et n’est jamais affiché. Chaque fois qu’un pixel passe ou échoue le test pochoir, une opéra1on de mise à jour sur le tampon pochoir peut être effectuée, selon le succès ou l’échec. Il est aussi possible de configurer le tampon pochoir de manière à ce qu’il soit modifié lorsque le pixel passe ou échoue le test de profondeur. Le succès ou l’échec du test pochoir dépend du test pochoir effectué, de l’informa1on contenue dans le tampon pochoir à ce moment et d’une variable de référence (numérique) configurée dans le code. Rappelons que les tests et mises à jour du tampon pochoir sont effectués de manière indépendante, pixel par pixel, comme c’est le cas pour le tampon-­‐z. 34 PROCESSEURS GRAPHIQUES ET PIPELINE Encart : Tampon pochoir (Stencil Buffer) 2014-­‐09-­‐26 fixée par le développeur via l’API graphique. Les tests sont effectués pour chaque pixel à rendre, au début de l’étape de combinaison. Les tests possibles sont : •  Jamais (toujours échouer le test) •  Toujours (toujours passer le test) •  Plus pe1t (passe le test si la valeur dans le tampon pochoir est plus pe1te que la valeur de référence) •  Plus pe1t ou égal (passe le test si la valeur dans le tampon pochoir est plus pe1te ou égale à la valeur de référence) •  Égal (passe le test si la valeur dans le tampon pochoir est égale à la valeur de référence) •  Plus grand ou égal, Plus grand, Non égal, etc. Notons que lors de la spécifica1on du test, le développeur peut aussi spécifier un masque qui sera appliqué avec un « et » (and) binaire sur la valeur de référence et la valeur courante. Les valeurs comparées lors du test sont les valeurs sur lesquelles le masque a été appliqué. Le masque possède normalement une valeur de 0xffffffff par défaut et n’a donc pas d’effet lorsque laissé tel quel. 35 PROCESSEURS GRAPHIQUES ET PIPELINE Encart : Tampon pochoir (Stencil Buffer) Les tests pochoirs sont effectués en fonc1on d’une valeur de référence numérique 2014-­‐09-­‐26 En fonc1on du résultat du test, les pixels du tampon pochoir peuvent op1onnellement être mis à jour. Les différentes opéra1ons possibles à effectuer sur celui-­‐ci sont : •  Conserver (la valeur du tampon pochoir reste la même) •  Zéro (la valeur du tampon pochoir est remise à 0) •  Remplacer (la valeur du tampon pochoir est mise à la valeur de référence) •  Incrémenter (la valeur du tampon pochoir est incrémentée pour le pixel courant) •  Décrémenter (la valeur du tampon pochoir est décrémentée pour le pixel courant) •  Inverser (une inversion binaire est effectuée pour la valeur du pixel) 36 PROCESSEURS GRAPHIQUES ET PIPELINE Encart : Tampon pochoir (Stencil Buffer) 2014-­‐09-­‐26 configurées différemment pour les différentes issues possibles du test pochoir. Il existe trois issues possibles pour le test pochoir. Remarquons que ces issues 1ennent aussi compte du tampon-­‐z, ce qui devient extrêmement u1le pour certains algorithmes de rendu avancé. Les opéraJons peuvent être configurées en foncJon de 3 issues possibles : •  Si le test pochoir est passé et le test de profondeur est passé. •  Si le test pochoir est passé et le test de profondeur a échoué. •  Si le test pochoir a échoué. 37 PROCESSEURS GRAPHIQUES ET PIPELINE Encart : Tampon pochoir (Stencil Buffer) Finalement, notons que les opéra1ons de l’acétate précédent peuvent être 2014-­‐09-­‐26 On souhaite effectuer le rendu d’une scène 3D uniquement dans un cercle au milieu de notre fenêtre de rendu et laisser le reste de l’image noir. Étapes : 1.  Réini1aliser le tampon-­‐z et le tampon pochoir à 0. 2.  Désac1ver l’écriture au tampon-­‐z. 3.  Configurer le tampon pochoir pour toujours faire passer le test pochoir et incrémenter la valeur du tampon pochoir de 1 où le test passe. 4.  Rendre un cercle rempli où on souhaite que le rendu final apparaisse (le tampon pochoir sera alors à 1 où le cercle a été rendu et 0 dans le reste de l’image) 5.  Réac1ver l’écriture du tampon-­‐z. 6.  Changer le test du tampon pochoir pour réussir seulement si la valeur du pochoir est égale à la valeur de référence 1. 7.  MeNre l’opéra1on de mise à jour du tampon pochoir à « conserver » pour éviter que sa valeur ne soit subséquemment modifiée. 8.  Rendre la scène. (La scène s’affiche alors uniquement où le cercle avait été rendu.) 38 PROCESSEURS GRAPHIQUES ET PIPELINE Encart : Tampon pochoir (Stencil Buffer) Exemple d’uJlisaJon simple du tampon pochoir : 2014-­‐09-­‐26 affichés, les autres pixels resterons noirs, car ils ne seront pas affichés suite à l’échec du test pochoir. Nous verrons des exemples d’u1lisa1on beaucoup plus complexe du tampon pochoir dans les chapitres à venir. 39 PROCESSEURS GRAPHIQUES ET PIPELINE Encart : Tampon pochoir (Stencil Buffer) Seulement les pixels de la scène où le pochoir avait préalablement été mis à 1 seront 2014-­‐09-­‐26 PROCESSEURS GRAPHIQUES ET PIPELINE Étude détaillée du pipeline graphique : étape de rastérisaJon Somme toute, on remarque que l’étape de combinaison fait appel à plusieurs types de tampons mémoires différents et soumet chaque fragment à différents tests avant qu’ils ne soient inscrits dans le tampon de couleur. Dans l’ordre, les ac1ons effectuées sont : 1.  Test pochoir 2.  Test de profondeur 3.  Écriture dans le tampon-­‐z 4.  Écriture dans le pochoir 5.  Calcul du mélange de couleur 6.  Écriture dans le tampon de couleurs Ces étapes effectuées, le pipeline a été complètement traversé et notre image peut maintenant être affichée. Représenta1on schéma1que de l’étape fonc1onnelle de combinaison des fragments. 40 GESTION DE LA MÉMOIRE VIDÉO 2014-­‐09-­‐26 41 2014-­‐09-­‐26 Il y a à peine 15 ans, les cartes vidéos ne possédaient pas de mémoire dédiée au rendu. La totalité de l’informa1on cons1tuant la scène à rendre devait être transférée de la mémoire vive principale de l’ordinateur vers le processeur graphique à chaque image rendue. Dans un tel contexte, le transfert d’informa1on entre la mémoire vive et le processeur graphique impliquait un passage par le bus mémoire, le contrôleur mémoire, le bus interne, le contrôleur d’entrée sor1e puis le bus AGP (PCI n’existait pas à l’époque). Naturellement, le transfert était extrêmement lent, ce qui avait un impact néga1f non négligeable sur la vitesse du rendu. Pour remédier à ce problème, les cartes vidéo modernes possèdent maintenant leur propre mémoire graphique embarquée, ce qui permet de stocker de l’informaJon uJle au rendu directement sur la carte vidéo. Si ceNe informa1on est réu1lisée sur plusieurs images, on gagne en performance, car le transfert mémoire n’a pas à être effectué. Dans les systèmes de rendu modernes, le goulot d’étranglement principal pour les performances de rendu demeure encore l’accès à la mémoire, qui cons1tue une opéra1on lente. Comprendre comment et où est stockée l’informa1on devient important afin d’en op1miser le placement mémoire et, par le fait même, op1miser le rendu. Dans ceNe sec1on, nous nous pencherons donc sur la ques1on de l’alloca1on de la mémoire vidéo. 42 PROCESSEURS GRAPHIQUES ET PIPELINE GesJon de la mémoire vidéo 2014-­‐09-­‐26 En faisant abstrac1on des ports et divers systèmes de contrôle électroniques, une carte vidéo moderne est, en pra1que, cons1tuée de deux composantes principales: •  Des unités de mémoire vidéo •  Un processeur graphique La mémoire vidéo se trouve donc généralement directement sur la carte, à proximité (d’un point de vue électronique), du processeur graphique. Elle sert à stocker de l’informa1on u1le et réu1lisable dans le contexte du rendu, alors que le processeur graphique s’occupe de faire les calculs requis pour un rendu 3D. CeNe mémoire, dite « VRAM » (pour Video Ram), s’accède relaJvement rapidement en lecture et en écriture à parJr du processeur graphique. 43 PROCESSEURS GRAPHIQUES ET PIPELINE Mémoire vidéo et mémoire vive 2014-­‐09-­‐26 Ceci étant dit, il faut cependant placer certains bémols quant à la vitesse de lecture et écriture de la mémoire vidéo. Généralement, l’informa1on de rendu peut être stockée sur la mémoire vidéo ou sur la mémoire vive de l’ordinateur. La carte vidéo peut donc lire et écrire sur la mémoire vidéo et sur la mémoire vive. En ordre de vitesse (plus rapide au plus lent), les opéra1ons mémoires effectuées par la carte vidéo sont les suivantes : 1.  Lecture de la mémoire vidéo. 2.  Écriture dans la mémoire vidéo à par1r du processeur graphique. 3.  Lecture de la mémoire vive. 4.  Écriture dans la mémoire vidéo à par1r de la mémoire vive. (requiers l’écriture dans la mémoire vive pour ensuite transférer vers la mémoire vidéo) 5.  Écriture dans la mémoire vive à par1r de la mémoire vidéo. (requiers l’écriture dans la mémoire vidéo pour ensuite transférer vers la mémoire vive) Ceci étant dit, il faut garder en tête que l’informa1on lue sur la carte vidéo a souvent préalablement été écrite dans ceNe dernière à par1r de la mémoire vive. La lecture de la mémoire vidéo est donc plus rapide que la lecture dans la mémoire vive seulement si l’informaJon lue n’a pas besoin d’être mise à jour (réécrite) à parJr de la mémoire vive trop souvent. 44 PROCESSEURS GRAPHIQUES ET PIPELINE Mémoire vidéo et mémoire vive 2014-­‐09-­‐26 Un exemple classique de cas où l’ordre de performance précédent ne s’applique pas est le transfert d’une vidéo vers la carte graphique. En effet, pour afficher une vidéo en u1lisant un processeur graphique, une texture doit être remplie et affichée pour chaque image de la vidéo. La texture est donc très souvent réécrite. Dans ce contexte, l’op1on de transférer la texture vers la mémoire vidéo à chaque image, pour ensuite la relire de la mémoire vidéo à l’affichage serait moins performante que de simplement laisser la texture en mémoire vive et indiquer au processeur graphique d’aller la lire en mémoire vive directement. Il serait donc plus op1mal d’indiquer au pilote, dans cet exemple, que la texture contenant les images de la vidéo devrait rester en mémoire vive pour augmenter les performances de rendu et diminuer les délais d’écriture en mémoire vidéo. Cet exemple introduit des concepts importants en gesJon de la mémoire vidéo, soit le dynamisme et le type d’accès de l’informaJon uJlisée pour le rendu. 45 PROCESSEURS GRAPHIQUES ET PIPELINE Mémoire vidéo et mémoire vive 2014-­‐09-­‐26 ges1on de mémoire permeNant de suggérer au pilote vidéo où stocker l’informa1on à l’aide d’indices sur son u1lisa1on. En spécifiant correctement le dynamisme et le type d’accès à l’informa1on, le pilote vidéo arrive à op1miser automa1quement le placement de l’informa1on en mémoire afin de maximiser les performances d’accès. Le dynamisme de l’informaJon de rendu se divise en deux catégories : •  InformaJon volaJle (ou dynamique) : informa1on qui change très souvent (1 fois ou plus toutes les 1 ou 2 images). •  InformaJon staJque : informa1on de rendu qui change peu souvent et reste constante sur plusieurs images rendues. Les types d’accès en mémoire se divisent quant à eux en trois catégories : •  Lecture seule •  Écriture seule •  Lecture et écriture Le type d’accès en mémoire représente le type d’accès aux données par l’applicaJon et non par le processeur graphique. 46 PROCESSEURS GRAPHIQUES ET PIPELINE Mémoire vidéo et mémoire vive Le dynamisme et le type d’accès de l’informa1on de rendu sont des concepts de 2014-­‐09-­‐26 Selon le type d’informa1on et son dynamisme, le pilote de la carte vidéo décidera où placer l’informa1on. Une informaJon dynamique sera habituellement placée dans la mémoire vive et lue par la carte vidéo. Ceci se jus1fie par le fait que lire la mémoire vive à par1r de la carte vidéo demeure plus rapide que de devoir écrire dans la mémoire vidéo puis subséquemment la lire. Dans la mesure où l’informa1on dynamique change souvent, il est préférable d’éviter l’écriture dans la mémoire vidéo. Une informaJon staJque sera quant à elle habituellement placée en mémoire vidéo directement, car elle n’aura pas besoin d’être accédée directement par l’applica1on après y avoir été inscrite. Certaines excep1ons persistent cependant, en fonc1on du type d’accès. Par exemple, des données en mémoire placée en écriture et lecture seront habituellement automa1quement placées en mémoire vidéo, indépendamment du dynamisme puisque le processeur graphique doit préalablement écrire en mémoire vidéo avant d’envoyer vers la mémoire vive. Les données seront alors écrites en mémoire vive exclusivement lorsque demandées par l’u1lisateur. 47 PROCESSEURS GRAPHIQUES ET PIPELINE Mémoire vidéo et mémoire vive 2014-­‐09-­‐26 Le dynamisme et le type d’accès en mémoire permeNent différentes op1misa1ons. Voici quelques exemples d’op1misa1ons courantes effectuées dans le pilote vidéo : 1.  Texture dynamique envoyée en écriture seule : Le pilote vidéo sait que le développeur n’a pas à lire les informa1ons de texture. Il peut donc directement envoyer un espace de mémoire quelconque à remplir plutôt que de devoir aNendre que l’espace de texture ciblé soit inu1lisé afin d’être ouvert à l’écriture/
lecture. Le nouvel espace mémoire remplacera par la suite l’ancien. 2.  Données de vertex staJques envoyés en écriture/lecture : Le pilote vidéo stocke les données en mémoire vidéo puisqu’elle est sta1que, mais garde aussi une copie en mémoire vive. Lorsqu’elle doit être mise à jour, la copie en mémoire vive est u1lisée puis transférée vers la copie en mémoire vidéo de manière asynchrone dans un moment opportun de la boucle de rendu. 48 PROCESSEURS GRAPHIQUES ET PIPELINE Mémoire vidéo et mémoire vive 2014-­‐09-­‐26 Sans étudier en détail les algorithmes de mise en cache des processeurs graphiques, notons que ces derniers, au même 1tre que les processeurs centraux, mebent en cache des intervalles de mémoire afin de limiter le nombre d’accès à la mémoire vidéo ou à la mémoire vive lors du rendu. Par exemple, si un processeur graphique doit accéder à un pixel d’une texture, il placera habituellement en cache plusieurs pixels environnants de ceNe même texture. Le processeur 1ent alors pour acquis que les données à proximité en mémoire seront elles aussi u1lisées dans un court délai. CeNe méthode de fonc1onnement devient importante à considérer dans la mesure où la cache du processeur vidéo est souvent libérée lorsque celui-­‐ci change d’état de rendu. La cache doit alors être reconstruite au fil du rendu. Il est donc important de limiter les changements d’état inuJles afin de préserver la cohérence de la cache le plus longtemps possible. Par exemple, permuter deux textures a souvent pour effet de libérer une très grande par1e de la cache. Regrouper toutes les primi1ves ayant la même texture afin de réduire les permuta1ons permet d’augmenter les performances de manière conséquente. 49 PROCESSEURS GRAPHIQUES ET PIPELINE Mémoire cache vidéo ARCHITECTURES GRAPHIQUES 2014-­‐09-­‐26 50 2014-­‐09-­‐26 Jusqu’à présent, nous avons étudié une représenta1on abstraite pouvant être perçue comme le dénominateur commun entre les différentes architectures graphiques existantes pour le rendu en temps réel. CeNe représenta1on débute par une étape d’applica1on, suivie d’une étape de géométrie puis terminant avec la rastérisa1on. Pour garan1r des performances adéquates, les étapes de géométrie et de rastérisaJon sont habituellement parallélisées grâce à une série d’unités de calculs fonc1onnant en parallèle. Ces unités peuvent être perçues comme de pe1ts processeurs indépendants contenus dans le processeur graphique. Modèle simplifié d’une architecture de rendu (Real-­‐Time Rendering 3, p.842, 2008) 51 PROCESSEURS GRAPHIQUES ET PIPELINE Architecture générale 2014-­‐09-­‐26 Chaque unité de calcul d’un processeur graphique fonc1onne indépendamment des autres et possède une très pe1te mémoire cache dédiée à l’unité. Elle a aussi accès à une mémoire cache beaucoup plus grande qui est commune à un groupe cons1tué de quelques dizaines d’unités de calcul. Pour opJmiser le rendu, il est important de s’assurer que les divers groupes d’unités de calcul travaillent sensiblement sur les mêmes données, afin de garan1r une meilleure cohérence de la cache et donc une meilleure performance. Similairement, le processeur graphique tente aussi de s’assurer que les divers groupes d’unité ont un travail équivalent, afin d’éviter que certains groupes soient en surcharge de travail alors que d’autres sont en famine. Dans ceNe op1que, le processeur graphique tente de diviser et réparJr le travail entre les groupes de calcul de manière à opJmiser l’uJlisaJon de cache et la charge de travail entre chaque groupe. Bien entendu, cebe réparJJon possède un coût de performance non négligeable. L’effectuer à chaque étape du processus (avant la géométrie et avant la rastérisa1on) finirait par annuler le gain de performance qu’elle permet. 52 PROCESSEURS GRAPHIQUES ET PIPELINE Architecture générale 2014-­‐09-­‐26 Placer l’étape de répar11on à divers endroits dans le pipeline permet d’obtenir des gains de performances différents, et de diviser le travail différemment au niveau du processeur graphique et des unités de calcul. C’est donc l’emplacement du disposiJf de réparJJon dans le pipeline qui détermine le type d’architecture d’un processeur graphique. Molnar et al. ont présenté une classifica1on des architectures de rendu en les classant en fonc1on de l’emplacement de la phase de répar11on au sein du pipeline. On compte donc quatre familles d’architectures différentes : •  Architecture de répar11on première. •  Architecture de répar11on intermédiaire. •  Architecture de répar11on de fin au niveau du fragment. •  Architecture de répar11on de fin au niveau de l’image. 53 PROCESSEURS GRAPHIQUES ET PIPELINE Architectures graphiques 2014-­‐09-­‐26 Les quatre architectures sont représentées dans l’image suivante : De gauche à droite : Répar11on première, répar11on intermédiaire, répar11on de fin au niveau du fragment, répar11on de fin au niveau de l’image. (Real-­‐Time Rendering 3, p.843, 2008) Notons que les unités de rastérisa1on sont ici divisées en 2 sous-­‐unités. Soit la sous-­‐
unité de généra1on des fragments (FG), qui s’occupe de la rastérisa1on en soit, et la sous-­‐unité de mélange des fragments (FM), qui s’occupe du mélange de couleurs (l’étape de combinaison). 54 PROCESSEURS GRAPHIQUES ET PIPELINE Architectures graphiques 2014-­‐09-­‐26 FoncJonnement : 1.  L’informa1on u1le au rendu est envoyée par l’applica1on 2.  On effectue le strict minimum de calcul requis sur les vertex pour les emmener en espace image. 3.  On divise l’image en tuiles et on associe un groupe de calcul à chaque tuile. 4.  On envoie chaque triangle aux unités de calcul correspondant aux tuiles où ils sont affichés. On y effectue le reste de l’étape de géométrie et la rastérisa1on. 5.  Lorsqu’une unité de calcul a fini de rendre sa tuile, elle renvoie ceNe dernière à une unité centrale qui s’occupe de posi1onner les tuiles dans l’image. 55 PROCESSEURS GRAPHIQUES ET PIPELINE Architecture de réparJJon première 2014-­‐09-­‐26 FoncJonnement : 1.  L’informa1on u1le au rendu est envoyée par l’applica1on. 2.  On effectue la totalité du traitement de la géométrie. (Offre une meilleure balance de charge pour ceNe par1e, mais cause une perte d’efficacité sur des systèmes ayant plusieurs cartes graphiques séparées. Ceci demeure néanmoins u1le pour des systèmes à une carte vidéo et u1lisé en pra1que pour les systèmes mul1cartes.) 3.  On divise l’image en tuiles et on associe une unité de calcul de rastérisa1on à chaque tuile. 4.  On envoie chaque triangle déjà transformé, en coordonnée fenêtre, aux unités de calcul de rastérisa1on correspondant aux tuiles où ils sont affichés. 5.  Lorsqu’une unité de calcul a fini de rendre sa tuile, elle renvoie ceNe dernière à une unité centrale qui s’occupe de posi1onner les tuiles de manière à former une image complète. 56 PROCESSEURS GRAPHIQUES ET PIPELINE Architecture de réparJJon intermédiaire 2014-­‐09-­‐26 réparJJon intermédiaire sont peu u1lisées dans un contexte d’ordinateur simple avec une seule carte vidéo. On u1lise surtout ces architectures pour des cas où le rendu est distribué sur plusieurs cartes vidéos puisque la division en tuile se porte bien à une telle situa1on. Dans un tel cas, chaque carte se charge d’afficher un certain nombre de tuiles (une par1e de l’image) et se divise le travail de ceNe façon. Les tuiles sont ensuite envoyées à une des deux cartes qui s’occupe de former l’image. Notons d’ailleurs que les configura1ons mul1cartes (Sli pour Nvidia et CrossFire pour ATI) u1lisaient originalement ces architectures pour distribuer le rendu sur plusieurs cartes. Dans ces cas, chaque carte vidéo débutait le rendu de la même image au même moment en laissant tomber les primi1ves transformées ne figurant pas dans la zone d’écran a~trée à la carte en ques1on. L’étape de géométrie était alors effectuée en double, ce qui créait une surcharge diminuant les performances de telles configura1ons. Maintenant, les configura1ons mul1cartes fonc1onnent avec un système d’alternance pour le rendu des images. 57 PROCESSEURS GRAPHIQUES ET PIPELINE Architectures de réparJJon première et intermédiaire Notons que les deux architectures précédentes, soient la réparJJon première et la 2014-­‐09-­‐26 Représenta1on du rendu en tuiles des architectures de réparJJon première et réparJJon intermédiaire. [Equalizergraphics.com, 2009] 58 PROCESSEURS GRAPHIQUES ET PIPELINE Architectures de réparJJon première et intermédiaire 2014-­‐09-­‐26 FoncJonnement : 1.  On envoie les informa1ons à rendre de l’applica1on. 2.  On effectue la totalité de la par1e géométrique du pipeline. 3.  On génère les fragments par rastérisa1on. 4.  L’espace 3D du volume canonique de vision est divisé en différentes régions. On associe un groupe de calcul pour le « shading » et le mélange de chaque région. 5.  Tous les fragments se trouvant dans une certaine région spa1ale sont envoyés à l’unité de calcul associée à ceNe région. (Chaque unité de calcul possède son propre tampon de couleurs (frame buffer) et son propre tampon-­‐z (z-­‐buffer)). 6.  Une fois tous les fragments générés, on combine les images produites à l’aide des tampons de couleur et des tampon-­‐z générés dans chaque image. (On se sert de ceux-­‐ci pour résoudre la visibilité si des fragments sont superposés.) 59 PROCESSEURS GRAPHIQUES ET PIPELINE Architecture de réparJJon de fin au niveau du fragment 2014-­‐09-­‐26 Représenta1on de la réparJJon de fin au niveau du fragment : Exemple réel d’une architecture de répar11on de fin au niveau du fragment. L’espace de vision canonique est divisié en différents blocs qui sont rendus par différents processeurs graphiques puis recombinés dans un processeur graphique central (écran du bas au centre) [Equalizergraphics.com, 2009] [Equalizergraphics.com, 2009] Ce type d’architecture est avantageux dans la mesure où il garan1t une bonne balance de charge jusqu’à très tard dans le pipeline. Il demande cependant une bande passante très importante au niveau du groupe de calcul central où les images sont recombinées. 60 PROCESSEURS GRAPHIQUES ET PIPELINE Architecture de réparJJon de fin au niveau du fragment 2014-­‐09-­‐26 FoncJonnement : 1.  On envoie les informa1ons à rendre à l’unité de calcul la moins chargée. Chaque unité de calcul con1ent un pipeline complet (géométrie et rastérisa1on) complètement indépendant et non communicant avec les pipelines des autres unités de calcul. Les données lorsqu’elles entrent dans un pipeline restent dans celui-­‐ci jusqu’à la produc1on du pixel final. 2.  On procède au rendu complet pour chaque unité de calcul. 3.  Chaque unité de calcul possède son propre tampon image (frame buffer) et écrit dans celui-­‐ci de manière désordonnée. Comme pour l’architecture précédente, chaque unité possède son propre tampon-­‐z. 4.  On combine les images en les superposant et en tenant compte de la profondeur via le tampon-­‐z préservé de chaque image. 61 PROCESSEURS GRAPHIQUES ET PIPELINE Architecture de réparJJon de fin au niveau de l’image 2014-­‐09-­‐26 ReprésentaJon de la réparJJon de fin au niveau de l’image : [VirtualGL, 2006] Notons que la répar11on de fin au niveau de l’image demande une quan1té très élevée de mémoire, car elle nécessite autant de tampon image (frame buffer) et de tampon-­‐z (z-­‐buffer) qu’il y a d’instance parallèle de rendu. 62 PROCESSEURS GRAPHIQUES ET PIPELINE Architecture de réparJJon et fin au niveau de l’image 2014-­‐09-­‐26 Pour les architectures avec réparJJon de fin, l’avantage principal demeure la balance de charge sur la majorité du pipeline. Ceci étant dit, la balance de charge accrue diminue la flexibilité de l’architecture au niveau du parallélisme. Autrement dit, l’architecture est plus difficile à meNre en œuvre pour des solu1ons à carte vidéo mul1ples. Elles sont donc surtout u1lisées dans les systèmes dédiés où le pipeline est plus flexible et modulaire. Un exemple de système populaire u1lisant un rendu avec répar11on de fin est la console de jeu vidéo PlaySta1on 3. Dans ce système, la distribu1on de la géométrie s’effectue juste avant le nuanceur de fragment (fragment shader), et une combinaison est effectuée juste avant le rendu. On a, dans ce cas, une réparJJon de fin au niveau du fragment. 63 PROCESSEURS GRAPHIQUES ET PIPELINE Architecture de réparJJon de fin au niveau de l’image et du fragment ANNEXE : ÉTUDE DE CAS, XBOX 360 2014-­‐09-­‐26 64 2014-­‐09-­‐26 L’étude de cas qui suit sert à faire un parallèle entre le pipeline théorique vu dans le cadre du cours et un pipeline graphique qu’on retrouve dans un contexte réel et pra1que. Il est important de constater que l’ordre du pipeline reste respecté tant dans la théorique que dans la pra1que, mais que l’interac1on entre les différentes étapes et composantes du pipeline est différente. 65 PROCESSEURS GRAPHIQUES ET PIPELINE Annexe : IntroducJon 2014-­‐09-­‐26 Avant de se lancer dans l’étude du pipeline graphique d’une Xbox 360, étudions brièvement l’architecture matérielle générale de la console par rapport au pipeline graphique. Globalement, la console est cons1tuée des systèmes principaux suivants : •  Un processeur central (CPU) : Connecté par un bus au processeur graphique. • Un processeur graphique (GPU Chip) : Le processeur graphique de la Xbox sert aussi de contrôleur mémoire. Le processeur central doit passer par le processeur graphique pour accéder à la mémoire, et le processeur graphique possède un accès direct à la mémoire vive, qui sert aussi de mémoire vidéo. (Ce type de mémoire est appelé mémoire unifiée puisque le processeur écrit/lit/u1lise exactement la même mémoire que le processeur graphique. Il n’y a donc pas de délais de transfert entre la mémoire vive et la mémoire vidéo, c’est la même mémoire.) •  La mémoire vive système (System RAM) : La Xbox 360 possède 512mo de mémoire vive accessible via le processeur graphique et le processeur central. 66 PROCESSEURS GRAPHIQUES ET PIPELINE Architecture matérielle d’une console de jeu Xbox 360 2014-­‐09-­‐26 •  Une puce subordonnée (Daughter chip) : CeNe puce se trouve connectée au processeur graphique. Elle possède 10mo de mémoire vive dans laquelle sont stockés les tampons-­‐z, les tampons de couleur et les tampons pochoirs. CeNe puce a le rôle dédié d’effectuer l’étape de combinaison du pipeline graphique. •  Un contrôleur d’entrée et sorJes (South Bridge) : Contrôleur s’occupant des autres composantes de la console, notamment les ports USB, l’audio, le réseau, etc. 67 PROCESSEURS GRAPHIQUES ET PIPELINE Architecture matérielle d’une console de jeu Xbox 360 2014-­‐09-­‐26 PROCESSEURS GRAPHIQUES ET PIPELINE Architecture matérielle d’une console de jeu Xbox 360 Représenta1on schéma1que de l’architecture matérielle de la Xbox 360 (RTR3, p.860, 2008) 68 2014-­‐09-­‐26 Un diagramme représentant les étapes qui suivent peut être trouvé à la fin du chapitre. Pipeline graphique de la Xbox 360 : 1.  Pour débuter, les commandes de rendu arrivent au processeur de commandes (command processor), en provenance de la mémoire. Les commandes ont été inscrites en mémoire lors de l’étape d’applica1on du pipeline. 2.  Les commandes consistent principalement en des listes d’indices de vertex à rendre. Les vertex référés dans les listes sont déjà contenus dans la mémoire et doivent être lus par le groupeur de vertex (vertex grouper) et transformés en triangles par le tesselateur (tesselator). 3.  Les données sont ensuite envoyées au séquenceur qui s’occupe d’ini1aliser les programmes des nuanceurs (shaders) et d’aller meNre en cache les textures u1les au rendu. 69 PROCESSEURS GRAPHIQUES ET PIPELINE Pipeline graphique de la Xbox 360 2014-­‐09-­‐26 vertex sur les différents vertex envoyés au processeur graphique. L’exécu1on des nuanceurs s’effectue sur une unité de calcul arithméJque logique (arithmeJc logical unit ou ALU). CeNe étape correspond aux étapes de transforma1on modèle-­‐vue, d’éclairage et de colora1ons des vertex, et à l’étape de projec1on. 5.  Lorsque le nuanceur de vertex a terminé son exécu1on, les vertex sortants passent par l’export de nuanceur et sont envoyés à un assembleur de primiJves (primiJve assembler) qui prend les coordonnées et les transforme en coordonnées fenêtres. L’assembleur de primi1ve s’occupe aussi de faire la prépara1on des triangles et le tronquage de vision. 6.  L’assembleur de primi1ves envoie ensuite des triangles à une unité de rastérisaJon (triangle traversal unit) qui les conver1t en fragments. CeNe étape correspond à l’étape fonc1onnelle de rastérisa1on du pipeline. 70 PROCESSEURS GRAPHIQUES ET PIPELINE Pipeline graphique de la Xbox 360 4. 
Le séquenceur démarre ensuite l’exécu1on parallèle de plusieurs nuanceurs de 2014-­‐09-­‐26 7.  Les fragments créés, ils peuvent être envoyés pour un test d’occulta1on appelé « Early-­‐z test ». Ce test est effectué si on détecte que le nuanceur de fragment qui sera effectué sur ceux-­‐ci ne modifie pas la profondeur du pixel. Dans un un tel cas, on effectue le test de profondeur/pochoir avant l’exécu1on du nuanceur de fragment, ce qui permet d’éviter d’exécuter un nuanceur de fragment inu1lement si le fragment ne passe pas les tests. Si le nuanceur de fragment modifie la profondeur du fragment, nous n’avons pas de garan1e sur sa passa1on du test de profondeur. Le early-­‐z test n’est donc pas exécuté. 8.  Si le fragment n’a pas été détruit à l’étape précédente, on le renvoie à l’ALU pour exécuter ceNe fois le nuanceur de fragment. CeNe étape correspond à l’étape fonc1onnelle de colora1on des pixels. 9.  Les fragments, après avoir passé dans l’ALU sont renvoyés à l’export de nuanceur (shader export). 10.  L’export de nuanceur envoie ensuite la couleur et la profondeur du fragment à la puce subordonnée (daughter chip) qui s’occupe de l’étape fonc1onnelle de mélange et d’écriture dans le tampon de couleur du pipeline. 11.  Une fois tous les fragments écrits dans le tampon de couleur, l’image est affichée et le rendu est terminé. 71 PROCESSEURS GRAPHIQUES ET PIPELINE Pipeline graphique de la Xbox 360 2014-­‐09-­‐26 Voici un diagramme de blocs représentant le pipeline graphique au sein du processeur graphique de la Xbox 360. RTR3, p.861, 2008 72 PROCESSEURS GRAPHIQUES ET PIPELINE Pipeline graphique de la Xbox 360 2014-­‐09-­‐26 Pour terminer ce chapitre, rappelons, de notre étude de cas, que la très grande majorité des systèmes de rendu en temps réel suivent les étapes du pipeline graphique théorique vu en début de chapitre, sous une forme ou une autre. Il existe néanmoins plusieurs op1misa1ons et varia1ons effectuées sur le modèle théorique afin de rendre un pipeline performant et adapté à la réalité du moment. Dans ceNe op1que, savoir analyser un pipeline graphique afin d’en isoler les composantes principales et iden1fier les étapes fonc1onnelles effectuées par cesdites composantes devient important. Lorsque cesdites étapes ont été correctement iden1fiées, leur compréhension devient naturelle, ce qui permet au développeur de correctement évaluer leur impact dans les performances et la qualité du rendu et de prendre des décisions de développement éclairées en conséquence. Une bonne compréhension du fonc1onnement d’un système de rendu est souvent synonyme de bonne u1lisa1on de ce même système. Leur étude est donc un élément primordial pour acquérir de l’expérience dans la réalisa1on de systèmes logiciels 3D en temps réel. 73 PROCESSEURS GRAPHIQUES ET PIPELINE Étude de cas : conclusion 2014-­‐09-­‐26 [Livre] T. Akenine-­‐Möller, E. Haines et N. Hoffman, « Real-­‐Time Rendering »,3rd ediJon, A.K. Peters, Ltd.,Na1ck, MA, USA, 2008 (chapitre 2 et chapitre 18) 74 PROCESSEURS GRAPHIQUES ET PIPELINE Référence recommandée