Partitions spatiales pour un lancer de Rayon sur GPU

Partitions spatiales pour un lancer de Rayon sur GPU
Vincent Nivoliers
31 aoˆut 2006
Stage de recherche de L3 au LIRIS, Universit´e Claude Bernard, Lyon1
Encadrants : Bernard P´eroche, Jean-Claude Iehl
1

Rapport de stage de L3 au LIRIS Vincent Nivoliers
Table des mati`eres
1 Introduction 2
2 Base du probl`eme 3
2.1 Lancerderayons ..................................... 3
2.1.1 Principe...................................... 3
2.1.2 Analyse ...................................... 3
2.2 FonctionnementdelaGPU ............................... 3
2.2.1 Parall´elisme.................................... 3
2.2.2 Pipeline programmable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.3 Utilisation de la carte graphique pour le lancer de Rayons . . . . . . . . . . 4
2.3 Partitionsspatiales.................................... 5
2.3.1 Partitionsclassiques ............................... 5
2.3.2 StructuredeKdtree ............................... 5
3 Solutions actuelles propos´ees par la recherche 6
3.1 Construction d’un KDtree efficace . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Impl´ementationsurGPU ................................ 7
3.3 Bounding Volume Hierarchy (BVH) . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4 Travail de recherche 8
4.1 Travail sur la structure de Kdtree . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Cr´eation de l’algorithme de parcours sur GPU . . . . . . . . . . . . . . . . . . . . . 10
4.2.1 Principe de la couture de l’arbre . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2 Avantage de la couture dans le cas des nœuds vides . . . . . . . . . . . . . 12
4.2.3 Suppression des pointeurs vers les nœuds vides . . . . . . . . . . . . . . . . 13
4.2.4 Pointsimportants ................................ 14
4.2.5 Pourallerplusloin................................ 14
4.3 Impl´ementationsurGPU ................................ 15
4.3.1 Codage du Kdtree dans des textures . . . . . . . . . . . . . . . . . . . . . . 16
4.3.2 Mise en place de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.3 Probl`eme rencontr´e `a la fin . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Encadrement 19
6 Conclusion 19
1 Introduction
Le lancer de rayons est un algorithme classique en synth`ese d’images, utilis´e principalement
pour le calcul de l’´eclairement d’une sc`ene. Le but du stage ´etait dans un premier temps d’´etudier
les structures acc´el´eratrices propos´ees pour acc´el´erer cet algorithme. De plus cet algorithme est
couramment implant´e pour calculer sur le processeur de la carte m`ere, mais son impl´ementation
pour le processeur de la carte graphique est plus complexe, du fait de la diff´erence d’architecture.
Ainsi mon objectif ´etait de comprendre le fonctionnement de la carte graphique, et d’utiliser les
r´esultats obtenus `a la fois sur carte m`ere (CPU) et sur carte graphique (GPU) pour cr´eer une
structure acc´el´eratrice de la sc`ene adapt´ee `a l’ex´ecution de l’algorithme sur carte graphique.
Dans ce rapport, je m’attacherai tout d’abord `a vous d´etailler les diff´erents probl`emes soulev´es
par le lancer de rayon, et les contraintes li´ees `a l’impl´ementation sur GPU. Ensuite, je ferai un
bilan des diff´erents articles qui m’ont ´et´e utiles pour mon travail. Enfin, je d´etaillerai mon travail
et les r´esultats que j’ai obtenus.
Encadrants : B. P´eroche, J.C. Iehl 2

Rapport de stage de L3 au LIRIS Vincent Nivoliers
2 Base du probl`eme
2.1 Lancer de rayons
2.1.1 Principe
Le lancer de rayons se base sur le mod`ele de l’optique g´eom´etrique. Il consiste `a g´en´erer un
rayon partant de l’emplacement de l’œil de l’utilisateur et passant par chaque pixel de l’image.
Nous avons ainsi une origine et une direction. Deux probl`emes sont `a distinguer : le probl`eme de
visibilit´e, et le lancer de rayons. Le probl`eme de visibilit´e peut s’exprimer ainsi : ´etant donn´e un
rayon (origine et direction), et un ensemble d’objets (triangles), le but est de trouver le premier
objet que le rayon coupe, et le point d’intersection.
Le lancer de rayons, bas´e sur le principe de Whitted (1980), quant-`a lui, consiste `a utiliser les
r´esultats de ce probl`eme pour calculer l’´eclairage d’une sc`ene. On dispose des rayons primaires,
g´en´er´es depuis l’œil de l’observateur (cam´era), on r´esoud le probl`eme de visibilit´e pour chacun
de ces rayons, puis selon les mat´eriaux, s’ils sont diffus, on cr´ee des rayons d’ombre, depuis le
point d’intersection vers les sources de lumi`ere, pour savoir si d’autres objets font de l’ombre `a
cet endroit, si le mat´eriau est sp´eculaire (r´efl´echissant), on cr´ee un rayon r´efl´echi suivant les lois
de la r´eflexion au point d’intersection. Pour tous ces nouveaux rayons, on r´esoud le probl`eme de
visibilit´e, et ainsi de suite.
2.1.2 Analyse
Une impl´ementation brutale de l’algorithme consiste `a parcourir l’ensemble des objets de la
sc`ene pour chaque rayon, afin de d´eterminer l’intersection. Si on ne consid`ere que les rayons pri-
maires, lanc´es depuis l’oeil, on obtient une complexit´e lin´eaire en le nombre d’objets, avec une grosse
constante correspondant au nombre de pixels. Les objets ´etant souvent eux-mˆeme complexes en
terme de nombre de faces, pour des sc`enes complexes, le coˆut devient rapidement inabordable.
De plus, la complexit´e devient plus compliqu´ee lorsque l’on commence `a g´en´erer des rayons de
r´eflexion, et d´epend de l’agencement de la sc`ene. Enfin, un autre probl`eme se greffe, provenant
des sources de lumi`ere pouvant ˆetre r´efl´echies aussi, et illuminer des objets par le biais de surfaces
r´efl´echissantes. Il est donc n´ecessaire d’organiser les donn´ees pour rendre la recherche d’intersection
plus efficace.
2.2 Fonctionnement de la GPU
Pour utiliser la carte graphique, il est obligatoire de passer par une application qui fait le lien
avec le mat´eriel. Parmis ces applications, on distingue notamment openGL et DirectX. C’est ainsi
qu’il devient possible d’activer ou de d´esactiver les options, et de donner ou r´ecup´erer des donn´ees.
2.2.1 Parall´elisme
La carte graphique est fondamentalement con¸cue pour travailler de fa¸con parall`ele. On dis-
tingue deux types de processeurs : le processeur de sommets et le processeur de fragments. Chacun
poss`ede plusieurs dizaines d’unit´es de calcul travaillant chacune sur un sommet ou un fragment.
Le fonctionnement de ces unit´es de calcul est dit “SIMD” pour Single Instruction Multiple Data.
Cela signifie qu’elles peuvent calculer en mˆeme temps sur des donn´ees diff´erentes, mais ex´ecuter la
mˆeme instruction. Lorsqu’une unit´e de calcul requiert un calcul diff´erent des autres, elle bloque leur
ex´ecution jusqu’`a ce que les instructions soient de nouveau coh´erentes. De plus, ces unit´es de calcul
n’ont pas de pile d’appels, et ne peuvent donc en aucune fa¸con travailler de mani`ere r´ecursive.
2.2.2 Pipeline programmable
La carte graphique ex´ecute un pipeline complet sur l’ensemble de la g´eom´etrie soumise. S’il
n’est pas possible de n’utiliser qu’une partie du pipeline, il est toutefois possible d’intervenir dans
ce sch´ema d’ex´ecution `a deux endroits, `a l’aide de ce qu’on appelle les “shaders”. Un shader est un
programme qui s’ex´ecute soit sur le processeur de sommets, soit sur le processeur de fragments. Au
Encadrants : B. P´eroche, J.C. Iehl 3

Rapport de stage de L3 au LIRIS Vincent Nivoliers
niveau d’un sommet, les donn´ees en entr´ee sont les coordonn´ees du sommet, ainsi que sa normale
et les attributs suppl´ementaires. Le processeur de fragments quant-`a lui travaille sur un ´el´ement
de surface d’une face, triangulaire, dont les donn´ees sont interpol´ees `a partir des sommets de la
face correspondante. Il est donc possible d’ex´ecuter de petits programmes `a chacun de ces stades
compil´es sp´ecialement pour ces processeurs.
(Geometry)
App.
Memory
(pixels)
Vertex
Processor
Pixel
Unpack
Pixel
Pack
Pixel
Trasfer
Primitive
Assembly Clip, project Viewpoint,
cull
Texture
Memory
Rasterize
(Geometry)
(Pixels)
Read
Control
Fragment
Processor Per Fragment Operations Frame Buffer Operations
Frame
Buffer
Vertices
Pixel Groups
Fragments
Textures
Programmable
Processor
Fig. 1 – Pipeline openGL
2.2.3 Utilisation de la carte graphique pour le lancer de Rayons
Implanter le lancer de rayons sur carte graphique consiste `a la d´evier de son fonctionnement
habituel pour lui faire ex´ecuter les calculs de recherche d’objet et d’intersection. Pour r´ealiser cela,
les donn´ees de l’algorithme sont ´ecrites dans des textures, sous formes de couleurs RGBA. On
doit donc stocker les donn´ees des objets et des rayons que l’on lance dans ces textures, cod´ees
en couleurs. Ensuite, pour pouvoir ex´ecuter une op´eration par rayon, on demande `a la carte gra-
phique d’afficher un carr´e, pour lequel les coordonn´ees texture des fragments vont co¨ ıncider avec
les emplacements des rayons dans les textures. On peut donc utiliser une unit´e de calcul par rayon,
et ex´ecuter les calculs en parall`ele sur les rayons. Du fait des contraintes cit´ees pr´ec´edemment, la
recherche d’intersection ne peut pas ˆetre r´ecursive, et pour utiliser au mieux les possibilit´es de pa-
rall´elisme, les calculs sur les diff´erentes unit´es de calculs doivent ˆetre aussi similaires que possible.
Les branchements sont donc `a proscrire, car ils engendrent des comportements divergents, et les
rayons coh´erents doivent ˆetre calcul´es en mˆeme temps.
Les textures peuvent ˆetre 1D, 2D ou 3D, de taille 4096 au maximum. Une case de la texture
est compos´ee de quatre flottants, pour les valeurs RGBA (Red Green Blue Alpha), ou trois, RGB
seulement. Les sp´ecifications IEEE font que les flottants sont de taille 32 bits avec 23 bits de
mantisse, toutefois, les constructeurs de cartes graphiques ne sont pas contraints de respecter cette
norme, si bien que chaque constructeur peut d´ecider de remanier la fa¸con de coder les flottants `a sa
fa¸con, il faut se r´ef´erer aux donn´ees de la carte graphique. De mˆeme en ce qui concerne les tailles
de textures, toutes les cartes ne supportent pas les mˆemes types et tailles de textures. Ainsi la
portabilit´e du code est difficile. D’ailleurs, dans les articles de recherche, il est toujours mentionn´e
pr´ecis´ement la carte graphique utilis´ee ainsi que ses sp´ecifications. De toute fa¸con, si la m´emoire
de la carte graphique est de 256Mo, il n’est pas possible de stocker un grand nombre de textures.
Il est impossible de stocker directement des pointeurs, des entiers, etc... tout est mis sous forme
de flottants. De plus les instructions en GLSL qui est le langage utilis´e pour les shaders [Ros04] ne
permettent pas la lecture bit `a bit des flottants, donc seule la mantisse est r´eellement utilisable.
Encadrants : B. P´eroche, J.C. Iehl 4

Rapport de stage de L3 au LIRIS Vincent Nivoliers
4096 repr´esente 212, donc pour adresser une texture carr´ee de 4096 de cˆot´e, il est n´ecessaire d’avoir
24 bits de mantisse, pas de chance.
2.3 Partitions spatiales
Pour limiter la recherche d’intersection, les objets sont organis´es selon leur r´epartition dans
l’espace, afin de pouvoir rapidement isoler l’objet cr´eant l’intersection. Les objets ´etant pour la
plupart d´ecris sous forme d’un maillage de triangles, on consid´erera par la suite que tous nos
objets sont des triangles.
2.3.1 Partitions classiques
Grilles :
Une premi`ere approche consiste `a discr´etiser la sc`ene par une grille r´e-
guli`ere et r´epartir les objets dans des “voxels”. Cette structure permet
tout d’abord de calculer facilement ´etant donn´e un rayon les voxels
travers´es par le rayon et de les ´etudier dans l’ordre de parcours du
rayon. De plus, elle est particuli`erement adapt´ee aux sc`enes dyna-
miques, car il est facile de transf´erer un objet d’une case `a une autre.
Une approche plus r´ecursive est la structure de grilles hi´erarchiques
qui consistent `a imbriquer des grilles les unes dans les autres avec
une r´esolution de plus en plus fine, aux endroits o`u la sc`ene est plus
complexe.
Arbres :
Les Arbres sont uns structure purement r´ecursive. On en distingue
principalement deux types : ceux qui cherchent `a diviser le nombre
d’objets, et ceux qui cherchent `a partitionner l’espace. Les r´esultats
actuels tendent `a prouver que les partitions spatiales sont plus effi-
caces, car un rayon ne peut se trouver dans deux nœuds `a la fois. Le
principe est de diviser la sc`ene par des plans de coupe et de r´epartir
les objets de part et d’autre. La construction d’un arbre optimal ´etant
trop complexe, on utilise des heuristiques pour le construire de fa¸con
intelligente. Je me suis int´eress´e lors de mon stage `a la structure de
kd-tree.
2.3.2 Structure de Kdtree
La construction d’un Kdtree suit la logique suivante : au d´epart, tous les ´el´ements de la sc`ene
sont regroup´es dans une boˆıte englobante. Cette boˆıte correspondra `a la racine de l’arbre. ` A chaque
´etape, on s´electionne un plan de coupe selon des crit`eres qui seront expliqu´es par la suite, et on
coupe la boˆıte initiale en deux. Les triangles sont r´epartis de part et d’autre de `a ce plan, et des
deux cˆot´es s’ils sont coup´es par le plan. On obtient ainsi deux boˆıtes plus petites, et disjointes,
que l’on va pouvoir subdiviser `a nouveau. Les plans de coupe sont `a priori quelconques, mais dans
les impl´ementations actuelles, ils sont align´es sur les trois axes xyz, ce qui rend la construction et
le parcours pour un rayon plus simple. Le crit`ere d’arrˆet est d´efini selon des heuristiques, mais le
principe global est le suivant : on d´efinit tout d’abord une profondeur maximale limite, ainsi qu’un
nombre de triangles maximum par feuille.
Sur la CPU, le principe de parcours est simple, `a chaque nœud, on parcours les fils dans l’ordre
de travers´ee du rayon. Lorsqu’on arrive `a une feuille, on parcourt la liste des triangles qu’elle
contient, et on regarde si l’un d’eux coupe le rayon. Les nœuds ´etant parcourus dans l’ordre de
travers´ee, la premi`ere intersection trouv´ee correspond `a la plus proche de l’origine du rayon, et
interrompt le d´eroulement de la recherche. Dans le cas d’un lancer de rayon sur carte graphique
ce type de parcours n’est plus possible, ´etant donn´e qu’il se base sur la pile du processeur pour
savoir `a quel nœud il doit remonter dans l’arbre en cas d’´echec, et pour r´ecup´erer les r´esultats des
calculs pr´ec´edents. L’algorithme de parcours ne peut donc pas ˆetre le mˆeme, ce qui nous m`ene au
Encadrants : B. P´eroche, J.C. Iehl 5