Imn638 Chap021

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

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

IntroducJon

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
CONCEPT DE PIPELINE
2014-‐09-‐26 4
2014-‐09-‐26

Concept de pipeline
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
2014-‐09-‐26

Concept de pipeline

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
2014-‐09-‐26

Concept de pipeline
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
2014-‐09-‐26
PROCESSEURS GRAPHIQUES ET PIPELINE7

Concept de pipeline
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
2014-‐09-‐26

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

Concept de pipeline
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
2014-‐09-‐26

Concept de pipeline

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
ÉTUDE DÉTAILLÉE DU PIPELINE GRAPHIQUE
2014-‐09-‐26 12
2014-‐09-‐26

Étude détaillée du pipeline graphique
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
2014-‐09-‐26

Étapes conceptuelles du pipeline graphique
•  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
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
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
2014-‐09-‐26

Étude détaillée du pipeline graphique : étape de géométrie

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
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

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
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
2014-‐09-‐26


Conversion en coordonnées fenêtres pour Direct3D 9 et ses prédécesseurs :

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
2014-‐09-‐26


Conversion en coordonnées fenêtre pour OpenGL, Direct3D 10 et ses successeurs :

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
2014-‐09-‐26

Étude détaillée du pipeline graphique : étape de rastérisaJon
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
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
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
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
2014-‐09-‐26

Encart : Tampon-‐Z (Z-‐Buffer)
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
2014-‐09-‐26

-‐ Exemple d’uJlisaJon avancée du tampon-‐z : On souhaite rendre un arrière-‐plan
1
à 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
2014-‐09-‐26

2-‐
Exemple d’uJlisaJon avancée du tampon-‐z : On souhaite mélanger plusieurs
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
2014-‐09-‐26

Encart : Mélange de couleur et écriture dans le tampon de couleurs
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
2014-‐09-‐26

exemple, si notre test de profondeur est de type « plus pe1t que » (less-‐than), et
Par
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
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
2014-‐09-‐26


Pour des raisons de performance, les facteurs de mélange ne peuvent être
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
2014-‐09-‐26

Encart : Tampon pochoir (Stencil Buffer)

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
2014-‐09-‐26

Les tests pochoirs sont effectués en fonc1on d’une valeur de référence numérique

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
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
2014-‐09-‐26


Finalement, notons que les opéra1ons de l’acétate précédent peuvent être
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
2014-‐09-‐26

Exemple
d’uJlisaJon simple du tampon pochoir :
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
2014-‐09-‐26


Seulement les pixels de la scène où le pochoir avait préalablement été mis à 1 seront
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
2014-‐09-‐26

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

GesJon de la mémoire vidéo
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
2014-‐09-‐26

Mémoire vidéo et mémoire vive

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
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
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
2014-‐09-‐26

Le
dynamisme et le type d’accès de l’informa1on de rendu sont des concepts de
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
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
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
2014-‐09-‐26

Mémoire cache vidéo
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
ARCHITECTURES GRAPHIQUES
2014-‐09-‐26 50
2014-‐09-‐26

Architecture générale
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
2014-‐09-‐26

Architecture générale

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

2014-‐09-‐26

Architectures graphiques
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
2014-‐09-‐26

Architectures graphiques
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
2014-‐09-‐26

Architecture de réparJJon première

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
2014-‐09-‐26

Architecture de réparJJon intermédiaire

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
2014-‐09-‐26

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
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
2014-‐09-‐26

Architectures de réparJJon première et intermédiaire

Représenta1on du rendu en tuiles des architectures de réparJJon première et
réparJJon intermédiaire.

[Equalizergraphics.com, 2009]
58
2014-‐09-‐26

Architecture de réparJJon de fin au niveau du fragment
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
2014-‐09-‐26

Architecture de réparJJon de fin au niveau du fragment
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

2014-‐09-‐26

Architecture de réparJJon de fin au niveau de l’image
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
2014-‐09-‐26

Architecture de réparJJon et fin au niveau de l’image
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
2014-‐09-‐26

Architecture de réparJJon de fin au niveau de l’image et du fragment

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
ANNEXE : ÉTUDE DE CAS, XBOX 360
2014-‐09-‐26 64
2014-‐09-‐26

Annexe : IntroducJon

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
2014-‐09-‐26

Architecture matérielle d’une console de jeu Xbox 360
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
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
2014-‐09-‐26

Représenta1on schéma1que de l’architecture matérielle de la Xbox 360 (RTR3, p.860, 2008)
68
2014-‐09-‐26

Pipeline graphique de la Xbox 360
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
2014-‐09-‐26

Le séquenceur démarre ensuite l’exécu1on parallèle de plusieurs nuanceurs de
4. 
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
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
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
2014-‐09-‐26

Étude de cas : conclusion

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

2014-‐09-‐26

Référence recommandée

[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

Imn638 Chap021

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Imn638 Chap021

Uploaded by

Copyright:

Available Formats

I M N 6 3 8

PROCESSEURS GRAPHIQUES ET PIPELINE

• Concept de pipeline

• Étude détaillée du pipeline graphique

• Ges1on de la mémoire vidéo

• Étude de cas

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE7

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

• RastérisaJon : L’étape de rastérisa1on est aussi eﬀectuée à l’intérieur du processeur

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

• Éclairage et teinte des vertex

• Tronquage (clipping) de vision

• Conversion en coordonnées fenêtres

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

Conversion en coordonnées fenêtre : La conversion en coordonnées fenêtre

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

• Rastérisa1on des triangles

• Colora1on des pixels

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

Notons que lors de la spéciﬁca1on du test, le développeur peut aussi spéciﬁer un

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

• Si le test pochoir a échoué.

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

Ces étapes eﬀectuées, le pipeline a été

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

• Un processeur graphique

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

PROCESSEURS GRAPHIQUES ET PIPELINE

•  Concept de pipeline

•  Étude détaillée du pipeline graphique

•  Ges1on de la mémoire vidéo

•  Étude de cas

•  RastérisaJon : L’étape de rastérisa1on est aussi eﬀectuée à l’intérieur du processeur

•  Éclairage et teinte des vertex

•  Tronquage (clipping) de vision

•  Conversion en coordonnées fenêtres

•  Rastérisa1on des triangles

•  Colora1on des pixels

•  Si le test pochoir a échoué.

•  Un processeur graphique

•  Architecture de répar11on intermédiaire.

•  Architecture de répar11on de ﬁn au niveau du fragment.

•  Architecture de répar11on de ﬁn au niveau de l’image.

2.  On eﬀectue la totalité du traitement de la géométrie. (Oﬀre une meilleure

3.  On divise l’image en tuiles et on associe une unité de calcul de rastérisa1on à

3.  On génère les fragments par rastérisa1on.

• Un processeur graphique (GPU Chip) : Le processeur graphique de la Xbox sert

•  La mémoire vive système (System RAM) : La Xbox 360 possède 512mo de

•  Un contrôleur d’entrée et sorJes (South Bridge) : Contrôleur s’occupant des

2.  Les commandes consistent principalement en des listes d’indices de vertex à

6.  L’assembleur de primi1ves envoie ensuite des triangles à une unité de

10.  L’export de nuanceur envoie ensuite la couleur et la profondeur du fragment à la