Quelques applications de la programmation des processeurs ...

Quelques applications de la programmation des

processeurs graphiques a la simulation neuronale et a la

vision par ordinateur

Alexandre Chariot

To cite this version:

Alexandre Chariot. Quelques applications de la programmation des processeurs graphiques ala simulation neuronale et a la vision par ordinateur. Mathematics [math]. Ecole des PontsParisTech, 2008. English.

HAL Id: pastel-00005176

https://pastel.archives-ouvertes.fr/pastel-00005176

Submitted on 12 Jun 2009

HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.

Larchive ouverte pluridisciplinaire HAL, estdestinee au depot et a la diffusion de documentsscientifiques de niveau recherche, publies ou non,emanant des etablissements denseignement et derecherche francais ou etrangers, des laboratoirespublics ou prives.

https://hal.archives-ouvertes.frhttps://pastel.archives-ouvertes.fr/pastel-00005176

Ecole des PontsCertis

Thseprsente pour lobtention du grade de Docteur de lEcole des

Ponts,spcialit Mathmatiques et Informatique

par

Alexandre Chariot

Quelques Applications de laProgrammation des Processeurs

Graphiques la SimulationNeuronale et la Vision par

Ordinateur

Thse soutenue le 16 dcembre 2008 devant le jury compos de :

M. Bernard Lapeyre Professeur lEcole des Ponts (Prsident)M. Michel Barlaud Professeur lUniversit de Nice-Sophia

Antipolis (Rapporteur)M. Stphane Vialle Professeur Suplec (Rapporteur)M. Mohamed Akil Professeur lEcole Suprieure dIngnieurs

en Electronique et Electrotechnique (Examinateur)M. Romain Brette Matre de confrences lEcole Normale

Suprieure de Paris (Examinateur)M. Luc Robert Directeur technique, socit Autodesk

RealViz (Examinateur invit)M. Renaud Keriven Professeur lEcole des Ponts (Directeur)

A Papi et Mamie,A Papa et Maman,

Et Sirven

Titre Quelques Applications de la Programmation des Processeurs Gra-phiques la Simulation Neuronale et la Vision par Ordinateur

Rsum Largement pousss par lindustrie vidoludique, la rechercheet le dveloppement doutils matriels destins la gnration dimagesde synthse, tels les cartes graphiques (ou GPU, Graphics Processing Units),ont connu un essor formidable ces dernires annes.Laugmentation de puissance et de flexibilit ainsi que le faible prix de cesGPU ont eu comme consquence inattendue leur utilisation dans des do-maines autres que graphiques. Cet usage dtourn est nomm GPGPU,General Purpose computation on GPU, ou Programmation Gnrique surGPU. Motivs par les besoins computationnels considrables lis auxdeux domaines de recherche sinscrivant dans les thmatiques du Cer-tis que sont les neurosciences et la vision par ordinateur, nous proposonsdans cette thse dappliquer les concepts GPGPU des applications sp-cifiques de ces domaines.Premirement, les ides cls de la programmation des processeurs gra-phiques et de leur drivation sont exposes, puis nous prsentons la di-versit des applications possibles travers un large panel de travaux exis-tants.Dans une deuxime partie, nous prsentons un rseau de neurones im-pulsionnels simul grce au GPU et acclr jusqu 18 fois par rapport une implmentation CPU quivalente.Dans une troisime partie, nous exposons une mthode variationnelle dereconstruction 3D par strovision dense, adapte sur GPU, permettantde reconstruire prcisment une carte de profondeur, cadence vido.Enfin, nous proposons une mthode dappariements dimages sur GPUpar mise en correspondance de points dintrts. A partir de ce procd,nous avons dvelopp une application apportant un soutien logistiquelors de la capture photographique dune scne large, par exemple desfins de reconstruction 3D.

Mots-cls GPU, GPGPU, Programmation parallle, Rseaux de neu-rones, Vision par Ordinateur, Strovision, Points dintrt, Mise en cor-respondance

v

Title Some Applications of Graphics Processors Programming to NeuralSimulation and Computer Vision

Abstract Widely driven by the gaming industry, research and develop-ment of new hardware graphics equipments for the generation of images,such as graphics cards (or GPU, Graphics Processing Unit), have signifi-cantly risen these recent years.The increased capacities and flexibility and low prices of these GPU hadthe unintended consequence of their use in areas other than graphics. Thishijacking is named GPGPU, (General Purpose computation on GPU). Moti-vated by the computational requirements associated with two researchareas within the Certis thematics (neurosciences and computer vision),we propose in this thesis to apply the GPGPU concepts to specific appli-cations of these areas.First, the key ideas of the graphics processors programming and their hi-jacking are exposed, then we present the diversity of possible applicationsacross a wide range of existing work.In a second part, we present a spiking neural network simulated throughthe GPU.In a third part, we set out a variational method for 3D dense stereo re-construction adapted on the GPU, to precisely reconstruct a depth mapand in almost real time, up to video rate. Finally, we propose an imagematching setup using GPU to match hundreds of images interactively.From this process we have developed an application providing logisticalsupport during the photographic capture of a large scene, for example,for 3D reconstruction.

Keywords GPU, GPGPU, Parallel programming, Neural networks,Computer vision, Stereovision, Features, Matching

vii

Remerciements

Lcriture de la page de remerciements nest jamais lexercice le plusfacile au cours de la rdaction dun rapport de thse. Il faut sassurerde noublier personne et de restituer au plus juste les apports et soutiensde chacun. Davance, je remercie tous les exclus involontaires de cette liste.

En premier lieu, je tiens adresser mon entire reconnaissance mondirecteur de thse, Renaud Keriven, pour la confiance quil ma accorden maccueillant au sein du Certis et par la suite, pour son indfectiblesoutien pendant ces trois annes ainsi que la motivation quil a su min-suffler. Quelle que soit la situation, ses conseils aviss mont toujourspermis davancer clairement dans mes travaux (et dans mes dcouvertesmusicales).

Je tiens prsenter mes remerciements chaleureux aux personnes quimont fait lhonneur dtre prsentes le jour de ma soutenance en tant quemembres du jury, en particulier Michel Barlaud et Stphane Vialle quiont consenti tre rapporteurs de ce manuscrit, en dpit de la charge detravail que cela reprsente, Bernard Lapeyre, prsident de ce jury, ainsiqu Mohamed Akil, Romain Brette et Luc Robert, examinateurs lors dujury de soutenance.

Je remercie spcialement lEcole des Ponts et lUniversit Paris-Estpour avoir assur lorganisation administrative et logistique de ma thse(en particulier Alice Tran pour sa comptence et sa bonne humeur perma-nente), ainsi que le Rectorat de Paris, mayant fourni la bourse ncessaireau droulement de la thse.

Mes sincres remerciements vont aux membres permanents du Certisavec qui jai eu loccasion de travailler ou que jai pu croiser lors de cestrois dernires annes : tout dabord Brigitte Mondou pour sa grandeefficacit et son incroyable patience face nos besoins administratifstoujours plus originaux, Jean-Yves Audibert, Florent Sgonne, Jean-Philippe Pons, Arnak Dalalyan et Pascal Monasse pour tous les changesscientifiques fructueux que jai pu avoir avec eux, pour leurs comptenceset leur gentillesse.

Un grand merci tous les autres membres du Certis pour tout cequils mont apport, aussi bien scientifiquement et humainement qutout autre niveau : Anne-Laure et son infaillible entrain (et son envie decuisiner, dont on aura largement profit !) ; Anne-Marie et son ct suisseforcment trs chocolat ; Cdric notre Attila des goters (ne semant quequelques miettes sur son passage) ; Ehsan et sa dmonstration de Setrun certain midi ; Jaonary qui naura pas manqu de me transmettre son

ix

virus (photographique !) ; Jrme (cest pour quand, cette partie de ten-nis ?) ; Hiep et sa jelly vietnamienne qui nous aura marqu ; Hichem, Huiet Zsolt nos trois post-doc ; Lockman qui arrive toujours des heuresimprobables ; Patrick L., Pierre et Mickal, les trois compres parisiens(quon ne voyait que trop peu ici !) ; et Nicolas (alors, quand est-ce quonvient te voir Vienne ?).

Je noublie pas non plus les "anciens" avec qui jai pu parcourir unbout de chemin trs agrable : Patrick E., Maxime, Charlotte, Noura,Olivier, Romain, Geoffray, Nassim, Thomas, Victor et Julien M.

Mon entire gratitude va Jorge Cham, pour ses grandes et pers-picaces penses propos de son exprience personnelle, mayant thautement prcieuse.

Je ne saurai clairement exprimer toute ma gratitude envers mes pa-rents et grand-parents, qui ont subi mes humeurs et mon manque deprsence auprs deux, tout en mayant inconditionnellement soutenu,aussi bien moralement que financirement. Merci vous.

Un autre merci tout particulier aux amis et personnes proches quise sont rgulirement enquis de mon avance et de ma motivation. Lesoutien dAnnie-Claude maura t plus que prcieux, tout comme lesentraides avec Aurore, Caro, Damien, Louis et Nico avec qui jai pu avoirde nombreuses discutions "doctorales". Je remercie galement tous mesautres amis, mayant soutenu de prs ou de loin ces trois annes durant,non cit mais pour qui je ne manque aucunement davoir une pensesincre, ils se reconnatront facilement.

Enfin, mes dernires et (donc) plus prcieuses penses et doux remer-ciements vont Marie-Pierre, qui a mtamorphos ces derniers mois enune priode plus quheureuse. Merci, ma Toi.

Noisy-le-Grand, le 12 mars 2009.

x

Table des matires

Table des matires xi

Liste des figures xvi

Liste des algorithmes xix

Introduction 1

I Concepts et applications GPGPU 9

1 Programmation gnrique sur GPU 111.1 Dfinition et Motivations . . . . . . . . . . . . . . . . . . 131.2 Elments de paralllisme . . . . . . . . . . . . . . . . . . . 15

1.2.1 Caractre SIMD/MIMD . . . . . . . . . . . . . . . . . . 151.2.2 PRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2.3 Aptitude supporter les oprations de Gather et Scatter . 17

1.3 Historique des GPU et Organisation interne . . . . . . 181.3.1 Les diffrentes gnrations de GPU . . . . . . . . . . . . 181.3.2 Organisation dun GPU . . . . . . . . . . . . . . . . . . 21

1.3.2.1 Composants matriels . . . . . . . . . . . . . 211.3.2.2 Pipeline graphique actuel . . . . . . . . . . . 21

1.4 Comment programmer en GPGPU ? . . . . . . . . . . . . . 241.4.1 Langages . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.4.1.1 Shading Languages . . . . . . . . . . . . . . . 241.4.1.2 Langages GPGPU . . . . . . . . . . . . . . . 25

1.4.2 Modle de programmation . . . . . . . . . . . . . . . . . 271.4.2.1 Tableaux = Textures . . . . . . . . . . . . . . 271.4.2.2 Kernel = Fragment Shader . . . . . . . . . . 271.4.2.3 Calcul = Rendu graphique . . . . . . . . . . 271.4.2.4 Feedback . . . . . . . . . . . . . . . . . . . . . 281.4.2.5 Complexit GPGPU . . . . . . . . . . . . . . 28

1.4.3 Contraintes matrielles . . . . . . . . . . . . . . . . . . . 291.4.3.1 Accs mmoire . . . . . . . . . . . . . . . . . 291.4.3.2 Bande passante . . . . . . . . . . . . . . . . . 291.4.3.3 Autres . . . . . . . . . . . . . . . . . . . . . . 30

1.4.4 Astuces de programmation . . . . . . . . . . . . . . . . 301.4.4.1 Stencil Buffer . . . . . . . . . . . . . . . . . . 301.4.4.2 Z-Buffer et Early Z-Cull . . . . . . . . . . . . 311.4.4.3 Instruction discard() . . . . . . . . . . . . 311.4.4.4 Occlusion Queries . . . . . . . . . . . . . . . 31

1.4.5 Introduction Cg . . . . . . . . . . . . . . . . . . . . . . 31

xi

1.4.5.1 Structures de donnes et types de variablesdisponibles . . . . . . . . . . . . . . . . . . . 32

1.4.5.2 Profil . . . . . . . . . . . . . . . . . . . . . . . 321.4.5.3 Exemples de code . . . . . . . . . . . . . . . 33

1.4.6 Introduction CUDA . . . . . . . . . . . . . . . . . . . 361.4.6.1 Structures de donnes et variables dispo-

nibles . . . . . . . . . . . . . . . . . . . . . . 371.4.6.2 Organisation matrielle . . . . . . . . . . . . 371.4.6.3 Kernels . . . . . . . . . . . . . . . . . . . . . 371.4.6.4 Organisation des threads . . . . . . . . . . . 381.4.6.5 Organisation mmorielle . . . . . . . . . . . 381.4.6.6 Excution . . . . . . . . . . . . . . . . . . . . 391.4.6.7 Exemple de code . . . . . . . . . . . . . . . . 40

1.4.7 Quelques techniques classiques vues sur ces deux langages 411.4.7.1 Quelques techniques classiques de pro-

grammation parallle . . . . . . . . . . . . . 411.4.7.2 Comparaison de Cg et CUDA . . . . . . . . 44

1.5 CLGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471.5.1 CertisLib . . . . . . . . . . . . . . . . . . . . . . . . . . 471.5.2 Motivation : choix de Cg pour la CLGPU . . . . . . . . . 471.5.3 Fonctionnement de la CLGPU . . . . . . . . . . . . . . . 48

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

2 Applications GPGPU 532.1 Outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.1.1 Algbre linaire . . . . . . . . . . . . . . . . . . . . . . . 552.1.2 Equations aux Drives Partielles (EDP) . . . . . . . . . . 562.1.3 Algorithmique . . . . . . . . . . . . . . . . . . . . . . . 57

2.2 Simulations physiques . . . . . . . . . . . . . . . . . . . . . 592.2.1 Automates, Coupled Map Lattice et drivs . . . . . . . . . 592.2.2 Systmes de particules . . . . . . . . . . . . . . . . . . . 602.2.3 Simulation de fluides . . . . . . . . . . . . . . . . . . . . 60

2.3 Finance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622.4 Traitement de signaux . . . . . . . . . . . . . . . . . . . . . 632.5 Illumination . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

2.5.1 Ray Tracing . . . . . . . . . . . . . . . . . . . . . . . . . 642.5.2 Photon Mapping . . . . . . . . . . . . . . . . . . . . . . 652.5.3 Radiosit . . . . . . . . . . . . . . . . . . . . . . . . . . 65

2.6 Traitement dimages et Vision par Ordinateur . . . . . . 662.6.1 Traitement dimages . . . . . . . . . . . . . . . . . . . . 66

2.6.1.1 Segmentation . . . . . . . . . . . . . . . . . . 662.6.1.2 Filtrage . . . . . . . . . . . . . . . . . . . . . 672.6.1.3 Tone Mapping . . . . . . . . . . . . . . . . . 69

2.6.2 Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692.6.2.1 Diagramme de Vorono et Triangulation de

Delaunay . . . . . . . . . . . . . . . . . . . . 692.6.2.2 Transforme en distance . . . . . . . . . . . 702.6.2.3 Raffinement de maillages . . . . . . . . . . . 712.6.2.4 Strovision . . . . . . . . . . . . . . . . . . . 71

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

xii

II Neurosciences Computationnelles 73

3 Introduction aux neurosciences computationnelles 753.1 Le neurone et ses proprits . . . . . . . . . . . . . . . . . 77

3.1.1 Prsentation . . . . . . . . . . . . . . . . . . . . . . . . 773.1.2 Morphologie . . . . . . . . . . . . . . . . . . . . . . . . 773.1.3 Proprits physiologiques . . . . . . . . . . . . . . . . . 78

3.1.3.1 Canaux ioniques . . . . . . . . . . . . . . . . 783.1.3.2 Potentiel de membrane, potentiel de repos . 783.1.3.3 Hyperpolarisation, dpolarisation . . . . . . 79

3.1.4 Potentiel daction . . . . . . . . . . . . . . . . . . . . . . 793.1.5 Propagation des potentiels daction . . . . . . . . . . . . 80

3.1.5.1 Rgnration des potentiels daction lelong de laxone . . . . . . . . . . . . . . . . . 80

3.1.5.2 Transmission synaptique . . . . . . . . . . . 813.2 Modlisation biophysique dun neurone . . . . . . . . . . 81

3.2.1 Modle de Hodgkin et Huxley . . . . . . . . . . . . . . . 823.2.2 Autres modles conductances . . . . . . . . . . . . . . 83

3.2.2.1 Modle de Morris-Lecar . . . . . . . . . . . 833.2.2.2 Modle de FitzHugh-Nagumo . . . . . . . . 843.2.2.3 Autres . . . . . . . . . . . . . . . . . . . . . . 84

3.3 Une famille de modles computationnels particu-liers : les Intgre-et-tire . . . . . . . . . . . . . . . . . . . 853.3.1 Dfinition formelle . . . . . . . . . . . . . . . . . . . . . 863.3.2 Premire formulation : modle de Lapicque . . . . . . . 863.3.3 Modles drivs . . . . . . . . . . . . . . . . . . . . . . 88

3.3.3.1 Intgrateur parfait . . . . . . . . . . . . . . . 893.3.3.2 Intgre-et-tire conductances synaptiques . 893.3.3.3 Intgre-et-tire non linaire . . . . . . . . . . 903.3.3.4 Spike Respond Model . . . . . . . . . . . . . . 90

3.4 Mise en rseau de neurones . . . . . . . . . . . . . . . . . . 903.4.1 Prsentation formelle . . . . . . . . . . . . . . . . . . . . 903.4.2 Rseaux de neurones impulsionnels . . . . . . . . . . . . 91

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4 Simulations sur GPU de rseaux de neurones impul-sionnels 934.1 Travaux antrieurs . . . . . . . . . . . . . . . . . . . . . . . 954.2 Rseaux de neurones impulsionnels connexit non

locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 954.2.1 Modle de neurone utilis . . . . . . . . . . . . . . . . . 964.2.2 Implmentation . . . . . . . . . . . . . . . . . . . . . . . 964.2.3 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.3 Rseau de neurones impulsionnels par sondage . . . . . 1014.3.1 Modle de neurone utilis . . . . . . . . . . . . . . . . . 1014.3.2 Gnration de nombres alatoires et bruit brownien . . . 102

4.3.2.1 Gnrateur congruentiel linaire . . . . . . . 1024.3.2.2 Transforme de Box-Mller et distribution

gaussienne . . . . . . . . . . . . . . . . . . . 1034.3.2.3 Bruit brownien . . . . . . . . . . . . . . . . . 103

4.3.3 Rgnration du rseau . . . . . . . . . . . . . . . . . . 1044.3.4 Implmentation . . . . . . . . . . . . . . . . . . . . . . . 105

xiii

4.3.5 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . 1074.3.5.1 Justification exprimentale . . . . . . . . . . 1074.3.5.2 Performances GPU . . . . . . . . . . . . . . 110

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

III Vision par Ordinateur 113

5 Strovision variationnelle sur GPU 1155.1 Vision par ordinateur . . . . . . . . . . . . . . . . . . . . . 117

5.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1175.1.2 Strovision . . . . . . . . . . . . . . . . . . . . . . . . . 118

5.2 Strovision deux camras . . . . . . . . . . . . . . . . . 1195.2.1 Modlisation . . . . . . . . . . . . . . . . . . . . . . . . 120

5.2.1.1 Modle choisi . . . . . . . . . . . . . . . . . 1205.2.1.2 Formulation de la fonction dnergie . . . . 1205.2.1.3 Minimisation par descente de gradient . . . 121

5.2.2 Implmentation GPU . . . . . . . . . . . . . . . . . . . . 1235.2.2.1 Discrtisation . . . . . . . . . . . . . . . . . . 1235.2.2.2 Sommation . . . . . . . . . . . . . . . . . . . 1245.2.2.3 Rgularisation . . . . . . . . . . . . . . . . . 1245.2.2.4 Critre darrt . . . . . . . . . . . . . . . . . 124

5.2.3 Schma computationnel complet . . . . . . . . . . . . . 1255.2.4 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . 125

5.3 Strovision trois camras . . . . . . . . . . . . . . . . . 1275.4 Vido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

6 Appariement dimages par GPU 1336.1 Dtection et caractrisation de points dintrt . . . . 135

6.1.1 Dtection . . . . . . . . . . . . . . . . . . . . . . . . . . 1366.1.1.1 Harris . . . . . . . . . . . . . . . . . . . . . . 1366.1.1.2 Harris-Laplace . . . . . . . . . . . . . . . . . 1376.1.1.3 DoG et SIFT . . . . . . . . . . . . . . . . . . 1396.1.1.4 SURF . . . . . . . . . . . . . . . . . . . . . . 142

6.1.2 Caractrisation par descripteur . . . . . . . . . . . . . . 1436.1.2.1 SIFT . . . . . . . . . . . . . . . . . . . . . . . 1436.1.2.2 SURF . . . . . . . . . . . . . . . . . . . . . . 145

6.2 Appariement de deux images . . . . . . . . . . . . . . . . . 1476.2.1 Mthode dappariement . . . . . . . . . . . . . . . . . . 147

6.2.1.1 Distances . . . . . . . . . . . . . . . . . . . . 1476.2.1.2 Plus proche voisin approch (ANN) . . . . 1486.2.1.3 Filtrage . . . . . . . . . . . . . . . . . . . . . 148

6.2.2 Algorithme GPU dappariement de deux images . . . . . 1496.2.2.1 Implmentation . . . . . . . . . . . . . . . . 1506.2.2.2 Rsultats . . . . . . . . . . . . . . . . . . . . 152

6.3 Notre application . . . . . . . . . . . . . . . . . . . . . . . 153Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Synthse 157

Conclusion gnrale 163

xiv

Bibliographie 167

xv

Liste des figures

1 Exemples dimages numriques rcentes . . . . . . . . . . . 22 Puissances de calcul brutes compares entre GPU NVidia

et CPU Intel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Exemples de simulations sur les GPU NVidia . . . . . . . . 34 Simulation de rseaux de neurones . . . . . . . . . . . . . . . 65 Applications GPU en vision par ordinateur . . . . . . . . . . 7

1.1 Puissances de calcul brutes compares entre GPU NVidiaet CPU Intel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2 Modle de calcul parallle Single Instruction Multiple Data . 161.3 Modle de calcul parallle Multiple Instruction Multiple Data 171.4 Gather et Scatter . . . . . . . . . . . . . . . . . . . . . . . . . . 181.5 Pipeline GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.6 Modle de programmation GPGPU . . . . . . . . . . . . . . 281.7 Rsultat de lexemple Cg . . . . . . . . . . . . . . . . . . . . . 351.8 Organisation des units logiques de traitement pour CUDA 381.9 Modle hardware de lorganisation des diffrents types de

mmoire GPU adressables en CUDA . . . . . . . . . . . . . . 391.10 Exemple de mapping . . . . . . . . . . . . . . . . . . . . . . . 421.11 Exemple de rduction . . . . . . . . . . . . . . . . . . . . . . 431.12 Scan parallle . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.1 Reprsentation dune matrice en GPU . . . . . . . . . . . . . 552.2 Diffrents rendus en temps rel de profondeur de champ . 562.3 Diffusion non linaire . . . . . . . . . . . . . . . . . . . . . . 572.4 Tri bitonique sur 8 lments . . . . . . . . . . . . . . . . . . . 582.5 Reprsentation dun graphe sur GPU . . . . . . . . . . . . . 582.6 Reprsentation de Coupled Map Lattice en 3D . . . . . . . . . 592.7 Croissance de cristaux de glace sur vitrail . . . . . . . . . . . 592.8 Systme de particules . . . . . . . . . . . . . . . . . . . . . . . 602.9 Simulation de mouvements de tissus . . . . . . . . . . . . . . 612.10 Simulation de la surface dun liquide en temps rel . . . . . 612.11 Simulation dynamique de nuages . . . . . . . . . . . . . . . 612.12 Simulation de lignes de flux . . . . . . . . . . . . . . . . . . . 622.13 Fast Fourier Transform et applications . . . . . . . . . . . . . . 632.14 Rendu par ray tracing . . . . . . . . . . . . . . . . . . . . . . . 642.15 Rendu de caustiques . . . . . . . . . . . . . . . . . . . . . . . 652.16 Rendu par radiosit . . . . . . . . . . . . . . . . . . . . . . . . 662.17 Segmentation par seuillage . . . . . . . . . . . . . . . . . . . 672.18 Strovision multi-vues par level-set . . . . . . . . . . . . . . 682.19 Segmentation par level set dune coupe IRM de cerveau . . . 682.20 Filtre glow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682.21 Exemples de tone mapping . . . . . . . . . . . . . . . . . . . . 69

xvi

2.22 Une application de Computer Vision : cration de panorama 702.23 Diagramme de Vorono et triangulation de Delaunay associe 702.24 Raffinement de maillage . . . . . . . . . . . . . . . . . . . . . 712.25 Exemple de rsultat de strovision . . . . . . . . . . . . . . 72

3.1 Morphologie dun neurone . . . . . . . . . . . . . . . . . . . 783.2 Deux types de neurones . . . . . . . . . . . . . . . . . . . . . 793.3 Enregistrement postsynaptique dun potentiel daction . . . 803.4 Schma dune synapse chimique . . . . . . . . . . . . . . . . 823.5 Potentiel daction idalis dans le modle intgre-et-tire de

Lapicque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 873.6 Schma lectrique quivalent un neurone intgre-et-tire

en comportement linaire . . . . . . . . . . . . . . . . . . . . 873.7 Evolution temporelle du potentiel membranaire dun neu-

rone intgre-et-tire passif . . . . . . . . . . . . . . . . . . . . . 88

4.1 Profil des frquences de dcharge en rgime stable du r-seau simul . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.2 Gain en temps de calcul de notre implmentation GPU parrapport une implmentation CPU de la partie schmadEuler de la simulation . . . . . . . . . . . . . . . . . . . . . 99

4.3 Gain en temps de calcul de notre implmentation GPU delalgorithme 4 complet par rapport une implmentationCPU de rfrence . . . . . . . . . . . . . . . . . . . . . . . . . 100

4.4 Frquence de dcharge (en Hz) en rgime stationnaire enfonction du pourcentage de neurones excitateurs prsentsdans le rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

4.5 Comparaison des frquences de dcharges (en Hz) en r-gime stationnaire pour des simulations sans et avec son-dage en fonction de Npoll . . . . . . . . . . . . . . . . . . . . . 109

4.6 Comparaison des temps dexcution (en s) pour les algo-rithmes CPU et CPU avec sondage, en fonction du nombreNpoll de neurones sonds . . . . . . . . . . . . . . . . . . . . . 110

4.7 Comparaison des temps dexcution (en s) pour les algo-rithmes CPU et GPU en fonction du nombre Npoll de neu-rones sonds . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

4.8 Temps dexcution (en s) des algorithmes CPU et GPU, enfonction de N et pour diffrentes valeurs de Npoll . . . . . . 111

4.9 Gains en temps de lalgorithme GPU par rapport lalgo-rithme CPU pour diffrentes valeurs de N . . . . . . . . . . 112

5.1 Modle stroscopique deux camras . . . . . . . . . . . . 1195.2 Modle deux camras . . . . . . . . . . . . . . . . . . . . . 1205.3 Schma de calcul complet pour deux camras . . . . . . . . 1265.4 Premier et deuxime jeux de donnes . . . . . . . . . . . . . 1275.5 Troisime et quatrime jeux de donnes . . . . . . . . . . . . 1275.6 Surface obtenue partir du premier jeu de donnes . . . . . 1275.7 Surface obtenue partir du deuxime jeu de donnes . . . . 1285.8 Surface obtenue partir du troisime jeu de donnes . . . . 1285.9 Surface obtenue partir du quatrime jeu de donnes . . . 1295.10 Schma de calcul complet pour trois camras . . . . . . . . . 1305.11 Jeu de donnes pour lalgorithme trois camras . . . . . . 131

xvii

5.12 Reconstruction partir de deux camras avec zones occluses 1315.13 Reconstruction avec trois camras . . . . . . . . . . . . . . . 132

6.1 Dtection de points dintrt . . . . . . . . . . . . . . . . . . 1366.2 Dtecteur de coins de Harris . . . . . . . . . . . . . . . . . . 1366.3 Calcul des images de la Difference of Gaussian . . . . . . . . . 1406.4 Dtermination des extrema dans la DoG . . . . . . . . . . . 1416.5 Filtres dapproximation du noyau gaussien avec = 1.2 . . 1426.6 Construction du descripteur SIFT . . . . . . . . . . . . . . . . 1456.7 Ondelettes de Haar utilises et calcul de la rponse en un

point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1466.8 Exemple dappariements corrects de points dintrts . . . . 1476.9 Mthode dappariement de deux images sur GPU . . . . . . 1516.10 Description de notre application portable : aide lacquisi-

tion photographique dense de larges scnes . . . . . . . . . 1566.11 Ballon captif . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646.12 Rsultats du Certis, reconstructions 3D . . . . . . . . . . . . 165

xviii

Liste des Algorithmes

1 Scan naf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 Scan parallle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 Schma dEuler avec dlai . . . . . . . . . . . . . . . . . . . . . 974 Dlais de transmission approchs . . . . . . . . . . . . . . . . 985 Prdcesseurs sonder du neurone i . . . . . . . . . . . . . . 1056 Simulation par sondage . . . . . . . . . . . . . . . . . . . . . . 106

xix

Introduction

Cest par la force des images que, par la suite des temps,pourraient bien saccomplir les vraies rvolutions.

Andr BretonLes Nouvelles littraires, Hommage Saint-Pol Roux, 1925

Elments de contexte

Le sicle de limage

Indubitablement, limage a pris le pas sur tout autre support dinfor-mation depuis dj plusieurs sicles, nos passs artistiques et mdiatiquesen ayant tmoign maintes reprises. En toute situation, nous sommes au-jourdhui plongs dans un milieu fait dimages, quelles soient dessines,photographies, filmes, artificiellement gnres, quelles reprsentent laralit, fidlement ou non, ou bien des ides plus abstraites, et quon lesutilise des fins commerciales, artistiques, ludiques, politiques ou autres.

Ces dernires dcennies ont vu un accroissement de lutilisation delimage, grce au dveloppement ou lapparition de sous-catgories oude nouvelles branches des arts majeurs, telles la photographie (de repor-tage, de mode,. . . ), le dessin (bande dessine, design graphique,. . . ), lapeinture (light painting,. . . ), ou encore la mise en scne (dispositifs inter-actifs et/ou multimdias,. . . ), et bien plus particulirement grce tousles progrs technologiques lis lunivers du numrique, impliques dansla majorit des domaines artistiques, industriels ou commerciaux.

Le numrique et limage

En effet, sil ne fallait retenir de ce dbut de sicle quune seule formede limage, ce serait sans nul doute son pendant numrique, ayant apportaux artistes et industriels "une nouvelle facult : une mallabilit infinie" [199],exploite dans bien des domaines.

Si lindustrie cinmatographique est lune des plus friande en matiredimagerie numrique (un des moteurs actuels de cette industrie tant eneffet lomniprsence deffets spciaux, de retouches numriques, et dani-mations de synthse), elle est depuis 2004 dpasse en termes budgtairepar lindustrie vidoludique (cette tendance saccroit depuis fortement, at-teignant 1.20 milliards deuros pour le cinma contre 2.96 milliards deu-ros pour le jeu vido, en 2004), ainsi devenu en France le premier loisir(figure 1).

1

2 Introduction

Figure 1 Exemples dimages numriques rcentes, illustrant les besoins calculatoires.Gauche : lacteur Bill Nighy dont les mouvements sont numriss pour tre appliqus un modle totalement 3D du personnage du capitaine Davy Jones dont lanimation seranumriquement affine, dans le film Pirates of the Caribbean : Dead Mans Chest,2006 ; c Industrial Light & Magic/Walt Disney Pictures. Droite : extrait du jeu vi-do Little Big Planet sur Playstation 3, 2008, prsentant une scne entirement gnrenumriquement ; cMedia Molecule.

Cette culture de limage et les besoins computationnels sans cessegrandissants, aussi bien quantitatifs que qualitatifs quelle engendre, ontfait apparaitre de nouvelles mthodes de cration dimages numriques,bases sur des amliorations matrielles : ils ont en effet suscit lmer-gence dquipements informatiques vous la gnration dimages nu-mriques.

Les premiers matriels ddis aux calculs graphiques sont dus lasocit Silicon Graphics, Inc. (SGI), ayant introduit au dbut des annes80 la premire station de travail 3D : IRIS 2000. Dautres gammes, usagesprincipalement professionnels, sont apparues dans les annes suivantes,chez SGI (avec les gnrations succdant au IRIS 2000, comme les PowerSeries) et quelques autres industriels.

Graphics Processing Units

Aprs quelques essais de cration de matriels additionnels, sousforme de cartes informatiques, destins aux calculs graphiques (commela socit ATI avec la VGA Wonder) dans les annes 80, cest surtout partir du milieu des annes 90 que, pousss par lindustrie du jeu vi-do, plusieurs industriels ont commenc proposer des cartes informa-tiques grand public prenant en charge toute la partie affichage et surtoutla partie calculatoire lie au graphisme afficher, on les nomma les cartesgraphiques. La srie de cartes Voodoo Graphics de la socit 3dfx Interac-tive en 1994 en est lemblme le plus marquant. Depuis, deux principauxconstructeurs de cartes graphiques ont subsist, ATI (rachet par AMD) etNVidia, amliorant sans cesse leurs cartes graphiques respectives, embar-quant des processeurs graphiques, ou GPU (Graphics Processing Unit), tou-jours plus performants.

Avec de tels processeurs, la volont de ces constructeurs tait originel-lement de proposer un outil matriel permettant de dcharger le proces-seur central de la machine (ou CPU, Central Processing Unit), des calculs3D, voire de tous les calculs lis aux graphismes. Le succs dans le milieudu jeu vido fut immdiat et si important que ces GPU sont depuis de-venus un des lments constitutifs les plus importants dans le choix dunordinateur, quil soit personnel ou professionnel.

Ceci sexplique par plusieurs points. En premier lieu, la puissancebrute de calcul propose par les GPU a largement dpass depuisquelques annes celle affiche par les CPU les plus performants (figure 2),

Introduction 3

grce leur architecture parallle hautement spcialise et optimise pourles oprations graphiques. Le regroupement possible des GPU en clusterdmultiplie encore cette puissance de calcul. Ensuite, la flexibilit de laprogrammation des GPU, samplifiant rapidement, permet dy adapterde plus en plus de types dalgorithmes. Enfin, le faible prix (400e pourun modle haut de gamme) assure une grande accessibilit.

G80G80Ultra

G92

GT200

500

600

700

800

900

1000

FLOPS/s

IntelCPU

NvidiaGPU

3GHzCore2Duo

3.2GHzHapertown

NV30NV35 NV40

G70

G71

0

100

200

300

400

Jan03 Jul03 Jan04 Jul04 Jan05 Jul05 Jan06 Jul06 Jan07 Jul07 Jan08

G

Figure 2 Puissances de calcul brutes compares entre GPU NVidia et CPU Intel de2003 2008. Ds 2003, les GPU ont pris lascendant sur les CPU. Malgr lapparitiondes CPU multi-curs (Core2 Duo et Quad Core Hapertown), les architectures G80 et latoute rcente G200 se dmarquent plus que sensiblement, se montrant jusqu huit foisplus puissantes en terme de GFLOPS (Giga-FLOPS). Adapt de [172].

Calcul gnraliste par GPU

Lanne 2002 a vu lapparition dune importante avance dans la flexi-bilit de programmation des cartes graphiques. Elles devinrent suffisam-ment polyvalentes pour que la communaut scientifique commence syintresser de plus prs et y chercher des applications computationnellesgnralistes potentielles, traditionnellement ralises par le CPU plus po-lyvalent (figure 3).

Figure 3 Exemples de simulations sur les GPU NVidia. Gauche : rendu de lvolutiondun nuage de fume dans une bote. Les calculs physiques lis lcoulement du fluide,tout autant que les calculs graphiques, sont effectus par le GPU. Droite : rendu dunette humaine grce une modlisation complexe des diffrentes couches de lpiderme et une mthode de transluminescence (ou subsurface scattering, phnomne de pn-tration de la lumire travers la surface dun objet translucide). Ces simulations sontexcutes en temps rel.

4 Introduction

Cette utilisation dtourne des GPU est nomme GPGPU (General Pur-pose computation on GPU). Pour les chercheurs, lintrt de la programma-tion GPGPU est clair : pouvoir, faible cot, utiliser des machines oudes clusters de machines parallles, permettant dacclrer grandementlensemble des calculs, avec des gains pouvant atteindre 2000%.

Les langages de programmation utiliss dans un cadre GPGPU ontvolu depuis 2002. Alors quon utilisait ces dbuts des shading languages(Cg, HLSL, GLSL,. . . ), langages bass sur les capacits graphiques descartes, de nouveaux langages GPU spcialiss dans le calcul gnralisteont depuis fait leur apparition, en particulier CUDA (Computer UnifiedDevice Architecture) de NVidia et le trs rcent OpenCL [164, 234, 165](officiellement soutenu par ATI, entre autres).

Malgr une encore faible implantation aujourdhui de cette mthodede dveloppement dans la communaut scientifique, un engouementcroissant est noter et pourrait lavenir changer certaines pratiques enrecherche tout autant quen industrie. De plus, il est noter quactuelle-ment se pose la question de la convergence CPU/GPU en un seul pro-cesseur, les constructeurs ATI (processeur Fusion prvu pour la deuximemoiti de 2009) et Intel (processeur Larrabee, prvu pour fin 2009) sypenchant fortement actuellement. Cela pourrait avoir pour mme cons-quence de modifier les habitudes de dveloppement en recherche et enindustrie.

Motivations

Conscient de la puissance propose mais encore sous-exploite desGPU, la ligne conductrice de cette thse a t la volont de dvelopper denouvelles mthodes et den adapter dautres une exploitation GPU, lesdomaines dapplications tant guids par les diffrents projets auxquels leCertis, le laboratoire o cette thse a t effectue, est li : en particulierle projet Facets, en lien avec lquipe Odyssee, traitant de neurosciences,et le projet ANR Wired Smart.

En effet, deux des domaines dapplications qui nous ont concern, lasimulation de rseaux de neurones (chapitre 4) et lappariement dimages(chapitre 6), ont tous deux comme dfaut dimposer des calculs trslourds, en grande quantit et sur des jeux de donnes toujours plus vastes(les rseaux de neurones simules sont de plus en plus larges, et lapparie-ment dimages est fait travers des ensembles de photographies de plusen plus grands), exigeant des temps de calculs bien trop importants pourdes implmentations CPU standard.

Lutilisation de GPU nous parut alors comme une solution viable explorer pour combler ce rel besoin de vitesse : par ladaptation ou lacration dalgorithmes de calcul sur GPU pour les domaines computa-tionnels prcits, il nous a sembl raliste de pouvoir obtenir des facteursde gains en temps notables.

Lemploi de plusieurs GPU conjointement sous la forme dune grappede calcul (cluster) est possible mais ncessite des mthodes de program-mation spcifiques et les installations matrielles adquates. Le projetANR GCPMF (Grilles de Calcul Pour les Mathmatiques Financires, regrou-pant lquipe IMS de Suplec, le Cermics de lEcole des Ponts, les projetsMATHFI, METALAU, OASIS et OMEGA de lINRIA, le laboratoire PMA

Introduction 5

de luniversit Paris VI, le laboratoire MAS de Centrale Paris, ainsi queles socits BNP Paribas, Calyon, EDF, IXIS CIB, Misys Summit et PricingPartners, et dont lobjectif est de mettre en valeur le potentiel du calculparallle appliqu aux mathmatiques financires sur des infrastructuresde grilles), dans lequel sont impliqus plusieurs personnes du Certis etdu Cermics, tudie cette nouvelle forme de grid computing [237, 64]. Dansle cadre de cette thse, nous avons choisi dexplorer lutilisation non pasdun tel cluster, mais dun unique GPU, cest--dire un seul nud dunepotentielle grappe de calcul, plus accessible quune grille complte de cal-cul.

Il est enfin noter que lors du dbut de cette thse, la communautGPGPU se crait tout juste, seuls les shading languages permettaient de d-velopper sur GPU, cest partir de lun deux, Cg (avec OpenGL commeinterface graphique), que nous avons dvelopp la librairie CLGPU, li-brairie de calcul gnraliste sur GPU, dcrite dans le chapitre 1. Depuis,le langage CUDA, ddi au calcul gnraliste, a t introduit. La questionde la rimplmentation de la CLGPU en CUDA ne se pose que depuislapparition il y a quelques mois (septembre 2008) de linteroprabilitavec OpenGL. Apparemment, il semble possible de crer une interfaceutilisant Cg et CUDA sans que la diffrence soit perceptible au niveauutilisateur.

Organisation de ce rapport et contributions

Cette thse est organise de la faon suivante :

Premire partie

Une premire partie sintresse tout dabord dfinir ce quest la pro-grammation GPU et plus particulirement GPGPU, ses concepts et as-tuces, puis en montrer un panel dapplications prexistantes.

Le chapitre 1 prsente la programmation GPGPU : aprs avoir explicitquelques lments de calcul parallle, une volution des GPU est mon-tre travers un historique des diffrentes gnrations ayant exist ainsique larchitecture globale des cartes actuelles. Ensuite nous dtaillons lesconcepts inhrents au dveloppement GPGPU, les contraintes impliques,quelques astuces classiques de programmation, puis nous prsentons(avec exemples) et comparons, dans une optique GPGPU, deux langagesutilisables sur ces GPU : Cg et CUDA. Enfin, nous prsentons une librairiedestine du calcul gnraliste sur GPU et dveloppe par les membresdu Certis, des fins de recherche et denseignement : la CLGPU.

Le chapitre 2 rpertorie de faon non-exhaustive les applications gn-riques, dont la partie computationnelle est ralise sur GPU, en les clas-sant par domaines : nous commenons par exposer quelques outils math-matiques adapts sur GPU, puis nous prsentons des applications dansles domaines de la simulation physique, du traitement de signal, diff-rentes mthodes de rendu graphiques, de traitement dimage et de visionpar ordinateur. Nous avons ici essay dexposer un panel dapplicationsreprsentatif des possibilits offertes par les GPU.

6 Introduction

Deuxime partie

Une deuxime partie prsente notre premier domaine dapplication :les neurosciences, sciences tudiant le systme nerveux (compos du cer-veau, de la moelle pinire, des nerfs, des organes des sens et du systmenerveux neuro-vgtatif) dans son anatomie et son fonctionnement.

Plus prcisment, nous nous intressons aux rseaux de neurones im-pulsionnels. Un rseau de neurone est un modle de calcul qui sinspirede faon schmatique du comportement de neurones physiologiques ; leneurone impulsionnel est une des modlisations possibles du neurone,cherchant reproduire une des caractristiques biologiques : le poten-tiel daction. Nos tudes dans ce domaine, prsents dans le chapitre 4,ont t menes au sein de lquipe Odyssee, base lInria Sophia-Antipolis, pour le projet Facets (Fast Analog Computing with EmergentTransient States) fond par la Commission Europenne, dont le but est decrer des fondations thoriques et exprimentales pour la ralisation denouvelles reprsentations computationnelles inspires des systmes ner-veux biologiques.

18,27 18,17

14,18

12,00

14,00

16,00

18,00

20,00

Ga

in e

n t

em

ps

0,91

2,27

4,35

10,52

3,49 3,512,44

0,00

2,00

4,00

6,00

8,00

10,00

N=2000 N=5000 N=10000 N=50000 N=100000

Ga

in e

n t

em

ps

Nombre de neurones dans le rseau

Npoll=5

Npoll=10

Npoll=50

Figure 4 Simulation de rseaux de neurones. Gauche : histogramme de dcharge deneurones impulsionnels. Droite : gains en temps observs dans lune de nos applications.Pour de plus amples dtails ; voir chapitre 4.

Le chapitre 3 introduit quelques concepts et proprits physiquespropres aux neurones, puis dfinit quelques unes des modlisations deneurones les plus clbres, cherchant ou non retranscrire ces proprits,en particulier la famille des modlisations impulsionnelles, ou intgre-et-tire.

Le chapitre 4 explicite les deux applications que nous avons dve-loppes en GPU dans le domaine neuroscientifique. La premire estune simulation dun rseau de neurones impulsionnels dans lequel laconnexit entre neurones nest pas locale. Ce travail a t publi Neuro-Comp06 [34]. La seconde application simule un autre rseau de neuronesimpulsionnels connexit non locale, en introduisant la notion de sondagedes voisins, permettant de grandement rduire la charge de calculs touten conservant une prcision trs acceptable. Lensemble de ces travauxrsultent dune collaboration avec Romain Brette.

Troisime partie

Une troisime et dernire partie traite dun autre domaine compu-tationnel, la Vision par Ordinateur, science des machines qui voient, dontle but est ldification de thories et systmes permettant la comprhen-sion de linformation se trouvant lintrieur dimages de provenances

Introduction 7

diverses (photographies, images vido, scanner IRM,. . . ) et dont quelquesunes des applications principales sont la segmentation dobjets, la recons-truction 3D de scnes ou dobjets, la reconnaissance de formes ou la clas-sification par contenu.

Figure 5 Applications GPU en vision par ordinateur. Gauche et milieu : reconstruction3D par strovision, en wireframe et avec texture ; voir chapitre 5. Droite : Appariementsde points dintrts entre deux images dune mme scne ; voir chapitre 6.

Le chapitre 5 propose premirement une courte introduction au do-maine de la Vision par Ordinateur, et en particulier au principe de lastrovision. Nous exposons ensuite notre algorithme de reconstruction3D par strovision dense, adapte au calcul GPU. Cet algorithme estbas sur une fonction dnergie comprenant un terme de rgularisationque lon minimise par descente de gradient. Ces travaux ont fait lobjetdune publication 3DPVT06 [146].

Le chapitre 6 commence par couvrir diffrentes mthodes permettantde dtecter et caractriser des points dintrt dans des images photogra-phiques, cest dire de localiser les points pertinents, sur lesquels ouautour desquels se trouve linformation qui permettra de les caractri-ser, dans loptique dtre galement retrouvs dans dautres images re-prsentant le mme objet. Ensuite, nous prsentons un procd gnraldappariements de points dintrts, prcdemment dtects, travers unjeu dimages du mme objet ou de la mme scne, et proposons un al-gorithme dappariements massifs de points dintrts, adapt sur GPU.Enfin, une application directe est montre travers lbauche dun logi-ciel permettant dassister un ou plusieurs utilisateurs lors de la capturephotographique dune scne large, en indiquant les zones de la scnetrop peu captures pour pouvoir tre discernes. Les travaux prsentsdans ce chapitre, publis ICPR08 [33], ont t raliss dans le cadredu projet Wired Smart, projet cr suite lappel RIAM (Recherche et In-novation en Audiovisuel et Multimdia) de lANR (Agence Nationale dela Recherche), cofinanc par cette dernire et le CNC (Centre Nationalde la Cinmatographie), regroupant le laboratoire I3S de luniversit deNice-Sophia Antipolis, le Dpartement Informatique de lENS Ulm et lessocits RealViz et Mikros Image, et ayant pour objectif la mise au pointde solutions matrielles pour des architectures de suivi de contours.

Le chapitre 7 synthtise la mthodologie de dveloppement exploitelors des travaux prsents dans les chapitres prcdents, en mettant enavant quelques conseils et interrogations se poser avant un nouveau d-veloppement sur GPU, et en rappelant les principales diffrences entreles langages de programmation sur GPU orients graphiques et ceux plusgnralistes. Un questionnement est ensuite effectu sur les apports etcontraintes dune ventuelle rimplmentation des applications prsen-

8 Introduction

tes dans cette thse avec un langage gnraliste, la place dun langageorient graphique comme nous lavons fait.

Premire partie

Concepts et applicationsGPGPU

9

1Programmation gnriquesur GPU

Sommaire1.1 Dfinition et Motivations . . . . . . . . . . . . . . . . . . . . 131.2 Elments de paralllisme . . . . . . . . . . . . . . . . . . . . . 15

1.2.1 Caractre SIMD/MIMD . . . . . . . . . . . . . . . . . . . . 151.2.2 PRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2.3 Aptitude supporter les oprations de Gather et Scatter . 17

1.3 Historique des GPU et Organisation interne . . . . . . . 181.3.1 Les diffrentes gnrations de GPU . . . . . . . . . . . . . 181.3.2 Organisation dun GPU . . . . . . . . . . . . . . . . . . . . 21

1.3.2.1 Composants matriels . . . . . . . . . . . . . . . 211.3.2.2 Pipeline graphique actuel . . . . . . . . . . . . . 21

1.4 Comment programmer en GPGPU ? . . . . . . . . . . . . . . . 241.4.1 Langages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.4.1.1 Shading Languages . . . . . . . . . . . . . . . . . . 241.4.1.2 Langages GPGPU . . . . . . . . . . . . . . . . . . 25

1.4.2 Modle de programmation . . . . . . . . . . . . . . . . . . 271.4.2.1 Tableaux = Textures . . . . . . . . . . . . . . . . . 271.4.2.2 Kernel = Fragment Shader . . . . . . . . . . . . . 271.4.2.3 Calcul = Rendu graphique . . . . . . . . . . . . . 271.4.2.4 Feedback . . . . . . . . . . . . . . . . . . . . . . . . 281.4.2.5 Complexit GPGPU . . . . . . . . . . . . . . . . 28

1.4.3 Contraintes matrielles . . . . . . . . . . . . . . . . . . . . . 291.4.3.1 Accs mmoire . . . . . . . . . . . . . . . . . . . 291.4.3.2 Bande passante . . . . . . . . . . . . . . . . . . . 291.4.3.3 Autres . . . . . . . . . . . . . . . . . . . . . . . . 30

1.4.4 Astuces de programmation . . . . . . . . . . . . . . . . . . 301.4.4.1 Stencil Buffer . . . . . . . . . . . . . . . . . . . . 301.4.4.2 Z-Buffer et Early Z-Cull . . . . . . . . . . . . . . 311.4.4.3 Instruction discard() . . . . . . . . . . . . . . 311.4.4.4 Occlusion Queries . . . . . . . . . . . . . . . . . . 31

1.4.5 Introduction Cg . . . . . . . . . . . . . . . . . . . . . . . . 311.4.5.1 Structures de donnes et types de variables dis-

ponibles . . . . . . . . . . . . . . . . . . . . . . . 321.4.5.2 Profil . . . . . . . . . . . . . . . . . . . . . . . . . 321.4.5.3 Exemples de code . . . . . . . . . . . . . . . . . . 33

11

12 Chapitre 1. Programmation gnrique sur GPU

1.4.6 Introduction CUDA . . . . . . . . . . . . . . . . . . . . . 361.4.6.1 Structures de donnes et variables disponibles . 371.4.6.2 Organisation matrielle . . . . . . . . . . . . . . 371.4.6.3 Kernels . . . . . . . . . . . . . . . . . . . . . . . . 371.4.6.4 Organisation des threads . . . . . . . . . . . . . 381.4.6.5 Organisation mmorielle . . . . . . . . . . . . . . 381.4.6.6 Excution . . . . . . . . . . . . . . . . . . . . . . . 391.4.6.7 Exemple de code . . . . . . . . . . . . . . . . . . 40

1.4.7 Quelques techniques classiques vues sur ces deux langages 411.4.7.1 Quelques techniques classiques de programma-

tion parallle . . . . . . . . . . . . . . . . . . . . . 411.4.7.2 Comparaison de Cg et CUDA . . . . . . . . . . . 44

1.5 CLGPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471.5.1 CertisLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471.5.2 Motivation : choix de Cg pour la CLGPU . . . . . . . . . . 471.5.3 Fonctionnement de la CLGPU . . . . . . . . . . . . . . . . 48

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Ce chapitre introductif va prsenter quelques lments de programma-tion gnrique sur GPU. Aprs une dfinition et lexposition des mo-tivations poussant la communaut sintresser cet outil, nous expli-citerons lorganisation de ces cartes graphiques et nous dtaillerons lesconcepts fondamentaux inhrents leur programmation, en donnant etcomparant des exemples en deux langages. Nous finirons par prsenterla CLGPU, librairie informatique ddie au calcul GPU, implmente parnos soins et utilise dans nos diverses implmentations dalgorithmes surcarte graphique.

1.1. Dfinition et Motivations 13

1.1 Dfinition et Motivations

Au sein dune architecture informatique, les processeurs centraux,CPU, ont originellement la charge de lensemble des calculs. Lorsque lancessit de traiter des donnes de large volume (images, vido ou son)est apparue dans les annes 80, leurs architectures se sont adaptes enproposant des jeux de fonctionnalits ddies ce traitement multimdia :MMX pour les processeurs de marque Intel, ou bien 3DNow ! pour ceuxdAMD, ont contribu au succs de ces gammes de processeurs.

Pousse par lindustrie vido-ludique, ayant rcemment dpass enterme de budget lindustrie cinmatographique, lmergence dun typede matriel informatique ddi aux traitements graphiques dchargeantle CPU, nomm GPU, Graphics Processing Unit, est ne, il y a une dizainedannes, du besoin de plus en plus grand de spcialisation des architec-tures des processeurs, voire de multiplication de ceux ci. Les GPU sontainsi des processeurs ports par une carte annexe, prenant leur chargele traitement des images et des donnes 3D, ainsi que laffichage.

Limplantation de ce type de matriel sest aujourdhui largement r-pandue, et a pour consquence inattendue leur utilisation dans des do-maines non graphiques, en particulier en simulation numrique. Cest cetype dutilisation dtourne que lon nomme GPGPU, General Purpose com-puting on Graphics Processing Units, ou Programmation Gnrique sur CarteGraphique.

Lengouement de la communaut pour cette mthode de programma-tion est tel quaujourdhui, ces cartes graphiques sont devenues de v-ritables outils computationnels professionnels. Etant architecturalementprvus pour un traitement massivement parallle des donnes, ils de-vraient devenir dans un avenir trs proche de vritables coprocesseursutiliss par tout type dapplication.

Les raisons dun tel engouement pour la programmation GPGPU sonttrs nombreuses, nous nous proposons den citer les principales.

Puissance de calcul Les besoins toujours plus importants de ralismepour le rendu dimages demandent une puissance de calcul croissantcontinuellement et ont naturellement pousss les industriels multiplierles capacits matrielles de ces cartes. Que ce soit au niveau du nombrede processeurs parallles contenus sur les cartes graphiques, du nombrede transistors, de la finesse de gravure ou de la quantit de mmoire dis-ponible, leur volution a t spectaculaire. La figure 1.1, adapte de [172],prsente lvolution compare des puissances brutes de calcul en termede GFLOPS, entre les CPU Intel et les GPU NVidia.

Calcul parallle massif Contenant jusqu 240 processeurs, les GPUsont conus pour excuter des tches massivement parallles, jusqu plu-sieurs milliers de threads. Pour cette raison, les GPU pourraient sappa-renter des supercalculateurs dbarrasss de structure complexe pluttqu des CPU multi-curs, capable de traiter seulement quelques threadssimultanment. A lavenir, cela pourrait changer, mais lheure actuelle,en privilgiant la rapidit de calcul, les GPU sont prfrables.


G80G80Ultra

G92

GT200

500

600

700

800

900

1000

FLOPS/s

IntelCPU

NvidiaGPU

3GHzCore2Duo

3.2GHzHapertown

NV30NV35 NV40

G70

G71

0

100

200

300

400

Jan03 Jul03 Jan04 Jul04 Jan05 Jul05 Jan06 Jul06 Jan07 Jul07 Jan08

G

Figure 1.1 Puissances de calcul brutes compares entre GPU NVidia et CPU Intel de2003 2008. Ds 2003, les GPU ont pris lascendant sur les CPU. Malgr lapparitiondes CPU multi-curs (Core2 Duo et Quad Core Hapertown), les architectures G80 et latoute rcente G200 se dmarquent plus que sensiblement, se montrant jusqu huit foisplus puissantes en terme de GFLOPS (Giga-FLOPS). Adapt de [172].

Flexibilit Auparavant simplement paramtrables, les cartes graphiquespermettent aujourdhui une programmation flexible et avance, en pro-posant de plus en plus de contrle sur les caractristiques toujours plusnombreuses, telle lutilisation de types de donnes (en particulier le calculflottant sur 32bits), de structures et dinstructions (branchements condi-tionnels) de plus en plus complexes. Il existe mme dornavant des ou-tils de dbogage destins certains langages utilisables en GPGPU. Laprogrammation dun GPU est ainsi de plus en plus semblable une pro-grammation squentielle classique.

Plusieurs GPU Certains GPU, et en particulier les haut-de-gamme,peuvent tre combins en cluster, dmultipliant encore la puissance decalcul. Cest le cas de la gamme Tesla, proposes par NVidia, qui associejusqu 4 GPU et 16Go de mmoire dans un unique chssis, portant 4 TFLOPS (4000 GFLOPS) la puissance de calcul de ce supercalculateur.Plusieurs calculateurs de ce type peuvent, de plus, tre associs par unrseau classique.

Prix et disponibilit Pour environ 400e, il est possible de se procurerles GPU les plus puissants existants sur le march actuel. Ces trs faiblesprix sont le rsultat de lexistence dun march norme et dune concur-rence rude entre les deux plus importants fabricants de cartes graphiques,NVidia et ATI, dont la cible commerciale principale est le grand public,pour la pratique des jeux vido. La composition dun cluster utilisationprofessionnelle est donc trs raisonnablement envisageable. De plus, parces faibles cots, il est aujourdhui rare pour une station de travail oumme un ordinateur grand public de ne pas disposer dun GPU perfor-mant.

1.2. Elments de paralllisme 15

Ces arguments tendent prouver que la puissance des GPU, long-temps nglige, est prte tre pleinement exploite, dans tout domainecomputationnel.

1.2 Elments de paralllisme

Les capacits parallles des GPU permettent dexcuter un partition-nement dune tche complexe en une multitude de tches lmentaires,pouvant tre ralises par ses diffrents processeurs travaillant simulta-nment, rendant lexcution globale bien plus rapide quune excutionsquentielle. Des algorithmes de domaines varis (mtorologie, finance,traitement dimage. . . ), comme nous le montrerons dans le chapitre 2, seprtent bien cette dcoupe. On se propose de donner ici les dfinitionsde quelques lments de calcul parallle, non spcifiques aux GPU.

1.2.1 Caractre SIMD/MIMD

Les architectures parallles, composes en gnral dun grand nombredunits de calcul, exploitent fortement les modes de fonctionnementSIMD / MIMD, autorisant lexcution simultane de plusieurs partiesde code. Ces modes sont deux de ceux rfrencs dans la taxonomie deFlynn [56], classifiant les diffrents types darchitectures des systmes in-formatiques parallles toujours dactualit.

Dfinition 1.1 Le SIMD, Single Instruction on Multiple Data, est un mode de calcul paral-lle dans lequel chaque unit de calcul reoit la mme suite dinstruction en plusde donnes propres, comme pour les processeurs vectoriels.

Ce modle est reprsent en figure 1.2. Une excution dun code enSIMD peut tre synchrone (on attend quune partie du code ait t ex-cut sur toutes les units de calcul. On parle de SIMD vectoriel, cest parexemple le cas pour les GPU) ou asynchrone (chaque unit de calcul pro-gresse indpendamment des autres. Cest alors un SIMD parallle).

Les instructions SIMD sont accessibles dans de nombreux proces-seurs professionnels et grand public depuis 1997 : MMX [182] pour Intel,3DNow ! [175] pour ATI, les jeux SSE (jusqu SSE4) pour les processeursde type x86, AltiVec [45] pour Apple, IBM et Motorola.

Elles sont parfaitement adaptes, par exemple, au traitement de signal,particulirement le traitement dimage, dans lequel on fait subir chaquedonne lmentaire, le pixel, le mme traitement, de faon indpendante.Dans ces cas, lexcution du code est en gnral bien plus rapide quuneimplmentation classique SISD (Single Instruction on Single Data), dans le-quel les instructions sont excutes exclusivement squentiellement.

Cependant, il existe des contreparties aux processeurs SIMD : leurprogrammation est souvent malaise, un algorithme nest pas forcmentexcutable sur une machine SIMD, la gestion des registres est plus com-plexe,. . .

Dfinition 1.2 Le mode MIMD, Multiple Instruction on Multiple Data permet dexcuterdes suites dinstructions diffrentes sur des donnes diffrentes, de faon asyn-chrone et indpendante.


UC UC UC

Inst

ruct

ions

DonnesDonnes

Stockage des rsultats

Click

to bu

y NOW

!PD

F-XChange

www.docu-track

.com C

lick t

o buy

NOW

!PD

F-XChange

www.docu-track

.com

Figure 1.2 Le modle parallle Single Instruction Multiple Data : toutes les unitsde calcul (UC) traitent simultanment, avec la mme instruction, une partie des donnesqui leur est propre. Chacune de ces units va ensuite ranger son rsultat dans une partiede la mmoire.

Ce modle est reprsent en figure 1.3. Chaque unit de calcul re-oit sa propre liste dinstructions et lexcute sur ses propres donnes.Les machines MIMD sont plutt destines au monde professionnel. LesConnection Machines 5 [235], de Thinking Machines Corporation et les Trans-puters [242] du dfunt Inmos en sont deux des reprsentants.

On distingue deux types daccs mmoire dans ce mode : Mmoire distribue : chaque unit de calcul possde sa propre partie

mmoire et ne peut pas accder celles des autres. Une commu-nication est possible entre processeurs par le biais de messages oudappels de procdures RPC, mais ncessite de connecter ces unitsMIMD de faon adquate, sur le modle dune grille, par exemple.

Mmoire partage : aucune des units de calcul na de mmoirepropre mais toutes peuvent accder une mme mmoire globale.Un changement effectu par une unit dans cette mmoire est doncvisible depuis les autres units. Pour viter les problmes de syn-chronisation, les principes classiques dexclusion sont utiliss : s-maphores, mutex,. . .

1.2.2 PRAM

Dfinition 1.3 On dsigne par PRAM, ou Parallel Random Access Machine, un modle derfrence des machines partage de mmoire, sur lesquels peuvent sexcuter desalgorithmes parallles cest le cas des GPU).

Trois modles sont distingus en fonction de leurs moyens daccs la mmoire, lis aux notions de gather et scatter (dtailles dans la sec-tion 1.2.3) :

1.2. Elments de paralllisme 17

UC UC UC

DonnesDonnes

Inst

ruct

ions

Inst

ruct

ions

Stockage des rsultats

Click

to bu

y NOW

!PD

F-XChange

www.docu-track

.com C

lick t

o buy

NOW

!PD

F-XChange

www.docu-track

.com

Figure 1.3 Contrairement au SIMD, le Multiple Instruction Multiple Data assigne chaque unit de calcul (UC) une suite dinstruction spcifique. Ces units reoiventtoujours une partie des donnes qui leur est propre et stockent leurs rsultats dans unemme partie de mmoire.

1. EREW, Exclusive Read Exclusive Write : chaque processeur ne peutlire ou crire un endroit mmoire que si aucun autre ny accde aumme moment ;

2. CREW, Concurrent Read Exclusive Write : chaque processeur peut lire nimporte quel endroit en mmoire, mais plusieurs processeurs nepeuvent crire simultanment au mme endroit.

3. CRCW, Concurrent Read Concurrent Write : chaque processeur peutlire et crire o il le souhaite en mmoire. Dans ce cas, on distinguetrois sous-cas : CRCW commun : si plusieurs processeurs crivent la mme valeur

au mme endroit, lopration russit. Sinon, elle est considreillgale ;

CRCW arbitraire : si plusieurs processeurs crivent au mme en-droit, un des essais russit, les autres sont avorts ;

CRCW prioritaire : si deux processeurs crivent au mme endroit,leur rang de priorit dtermine le seul qui russit.

1.2.3 Aptitude supporter les oprations de Gather et Scatter

Dfinition 1.4 Gather et Scatter dsignent la possibilit, pour une unit de traitement, de lire,respectivement dcrire, des donnes diffrents endroits de la mmoire, adresssindirectement.

Gather et scatter sont des oprations fondamentales dans tout trai-tement informatique. La figure 1.4 illustre ces deux principes. Dans unlangage ressemblant au C, une opration de lecture type gather scritu=d[i], o d est une structure de donnes stocke en mmoire, i un


index, et u une variable de stockage. Au contraire, lopration de scatterscrit d[i]=u.

Gather

UCUC

UCUC

Scatter

Figure 1.4 Par gather, lunit de calcul a un accs indirect en lecture la mmoiredans laquelle sont stockes les donnes. Par scatter, cette unit peut crire ses rsultats des endroits de la mmoire adresss indirectement.

1.3 Historique des GPU et Organisation interne

Depuis lapparition dans les annes 80 des acclrateurs graphiquesmatriels, leur volution na cess de sacclrer. Les premires cartes gra-phiques accessibles au grand publiques sont apparues dans le milieu desannes 90, avec en particulier les Voodoo Graphics. Cest NVidia qui a intro-duit le terme GPU, remplaant le terme VGA Controller, alors insuffisantpour dsigner lensemble des possibilits offertes par ces cartes.

Lindustrie du jeu vido, en particulier, na depuis cess de moti-ver le dveloppement de nouveaux processeurs ddis au traitementgraphiques. Cette volution peut tre catgorise en diffrentes gnra-tions [52], selon leurs capacits, sur lesquelles nous nous proposons dedvoiler quelques aspects. Une description plus dtaille de larchitecturedes dernires gnrations, permettant de comprendre leur utilisation dansnos applications, est ensuite propose.

1.3.1 Les diffrentes gnrations de GPU

Les forces ayant pouss les industriels amliorer sans cesse ces cartesgraphiques sont dues principalement un aspect conomique de comp-titivit, pour faire face un apptit de plus en plus grand de complexitvisuelle ou de ralisme dans les reprsentations cinmatographiques oules simulations vido-ludiques, pouss par une volont assurment hu-maine de divertissement.

Suivant la loi de Moore [159], faite pour les CPU qui ne la respectentplus aujourdhui, et stipulant que le nombre de transistors sur un proces-seur double tous les 18 mois, les architectures des GPU ont volu depuis

1.3. Historique des GPU et Organisation interne 19

une dcennie, franchissant parfois des sauts technologiques importants.Nous nous proposons ici de classer ces architectures en diffrentes gn-rations.

Avant les GPU Dans les annes 80, des socits comme Silicon Graphicsou Evans and Sutherland proposrent des solutions matrielles extrme-ment couteuses, rserv quelques professionnels spcialiss, et ne pou-vant effectuer que quelques oprations graphiques trs simples commedes transformations de vertex ou des applications de textures. De fa-on gnrale, le reste des oprations graphiques taient accomplies parle CPU.

Premire gnration La premire gnration de GPU proprement par-ler a dbut avec larrive des Voodoo Graphics de 3dfx Interactive en 1996,et dura jusquen 1999. Les principales cartes de cette gnration sont lesTNT2 de NVidia (architecture NV5), les Rage dATI et les Voodoo3 de3dfx. Les premires oprations graphiques disponibles sont la rasteri-zation de triangles et lapplication de texture. Ces cartes implmententgalement le jeu dinstruction de DirectX 6, API (Application Program-ming Interface, Interface de Programmation) alors standard. Cependant, ellessouffrent de certaines limitations, principalement la grande faiblesse dujeu dinstructions mathmatiques et limpossibilit de transformer mat-riellement des vertex, opration lourde encore la charge du CPU.

Deuxime gnration Les premires GeForce 256 de NVidia (NV10)font leur apparition en 1999, peu prs en mme temps que les Radeon7500 dATI (architecture RV200) et Savage 3D de S3. Ces cartes permettentmaintenant une prise en charge complte de la transformation des vertexet du calcul des pixels (Transform and Lightning, T&L). Les deux API prin-cipales, DirectX 7 et OpenGL, sont maintenant supportes par ces cartes.Les amliorations apportes au jeu dinstructions rendent ces cartes plusfacilement configurables, mais pas encore programmable : les oprationssur les vertex et les pixels ne peuvent tre modifis par le dveloppeur.

Troisime gnration Ds cette gnration, les constructeurs NVidia etATI se partagent la quasi-totalit du march, NVidia ayant fait lacquisi-tion de 3dfx. Les Geforce 3 (NV20) en 2001 et GeForce 4 Ti (NV25) en 2002de NVidia, la Radeon 8500 dATI (R200) en 2001 forment cette gnrationde GPU, permettant enfin au dveloppeur de diriger la transformation desvertex par une suite dinstructions quil spcifie. Nanmoins, la program-mabilit des oprations sur les pixels nest toujours pas possible. DirectX8 et quelques extensions OpenGL permettent tout de mme une plusgrande souplesse de configuration dans le traitement de ces pixels.

Quatrime gnration Courant 2002, ATI propose sa Radeon 9700(R300), et NVidia sa GeForce FX (NV30) la fin de la mme anne. Cesdeux cartes, en plus de supporter le jeu dinstructions DirectX 9 et de nou-velles extensions OpenGL, apportent de plus la possibilit de programmerle traitement des pixels. Cest partir de cette quatrime gnration decartes que les premires oprations GPGPU ont pu se faire.


Cinquime gnration Les GeForce 6 (NV40, avril 2004) et GeForce 7(G70, juin 2005) de NVidia, les Radeon X800 (R420, juin 2004) et X1800(R520, octobre 205) et drives composent cette gnration. Ces cartes per-mettent quelques fonctions intressantes, en particulier en calcul GPGPU :laccs aux textures lors de la transformation des vertex, le rendu dansdiffrentes textures (Multiple Render Target, MRT) et le branchement dy-namique, uniquement pour la transformation des sommets, amliorantgrandement la vitesse dexcution. Le traitement des pixels ne supportepas ce branchement dynamique.

Sixime gnration Cest la gnration en plein essor actuellement,quipant la plupart des ordinateurs sur le march. Ses limites sont plusfloues, chaque constructeur apportant ses innovations propres. Elle estcompose des GeForce 8 (G80) et GeForce 9 (G92), lances respective-ment en 2006 et 2008, apportant des modifications dans la faon de conce-voir le pipeline graphique. Entre la transformation des vertex et la ras-terization des primitives (leur transformation en fragments, ou pixels),une tape supplmentaire est insre, permettant de modifier la gom-trie du maillage des primitives : insertions et suppression de vertex sontpossibles, ce qui ouvre de nouvelles voies au calcul GPGPU. Lajout dutype int utilisable en interne (registres) et surtout en externe (textures)a galement contribu largir le nombre dapplications possibles. Deplus, sur les cartes GeForce 8, il nexiste plus de diffrence physique entreles diffrents processeurs. Larchitecture matrielle modifie est dite uni-fie, cette caractristique tant exploite par le langage de programmationCUDA, de NVidia, utilisable avec des cartes architectures G80 ou sup-rieures. La srie GeForce 9 ne connait pas un succs vritable, ayant moinsde mmoire et ses performances tant gales voire infrieures aux cartesquivalentes de la srie GeForce 8, pour un prix semblable. Les sriesde cartes dATI de cette gnration sont les Radeon HD2000 et RadeonHD3000 (R600) , lances en 2007, pour contrer la srie GeForce 8. Mal-gr quelques amliorations intressantes proposes par ce constructeur(support de DirectX 10.1, de la norme Shader 4.1 par exemple), ces cartespeinent simposer cause dun prix trop lev, de pices bruyantes etde puces chauffant beaucoup.

Septime gnration La dernire gnration en date nest pas encorerpandue lheure actuelle. Les GeForce 200 (G200), lances en juin 2008,apportent des amliorations principalement techniques : augmentationde la mmoire disponible, du nombre de processeurs, des frquences m-moire et GPU, de la bande passante par largissement du bus de donnes,pour des performances annonces jusqu deux fois suprieures aux s-ries prcdentes. Pour ATI, les Radeon HD4000, en juin 2008 galement,sont censes rivaliser avec la srie GeForce 9, mais les performances desmodles haut de gamme les mettent au mme niveau que les GeForce 200,proposant les mmes types damliorations techniques, mais affichant destarifs plus attractifs et une consommation lectrique revue la baisse.

Rtrocompatibilit Il est important de noter que les programmes critspour un type ou une gnration de cartes restent utilisable avec les gn-rations futures de cartes, mme si toutes les capacits ne sont plus nces-


sairement exploites. Cest, par ailleurs, un problme important de dve-loppement que de devoir faire avec les diffrentes gnrations de cartesprsentes sur le march.

1.3.2 Organisation dun GPU

Deux aspects importants permettent de caractriser lorganisation desGPU : le contenu matriel orient calcul parallle et son organisation ad-quate en pipeline.

1.3.2.1 Composants matriels

La carte graphique est un des organes de lordinateur, charg du trai-tement graphique et de laffichage. Elle se compose dune zone mmoireet de processeurs, auxquels viennent sajouter divers registres et chipsetsde communication.

Ce quon appelle GPU, au sens strict, est lensemble des processeursgraphiques contenus sur cette carte, cest--dire les units oprant les cal-culs. Par abus de langage, on nommera galement GPU la carte entire.

La mmoire disponible varie aujourdhui jusqu 768Mo, cadence 1080MHz, accessible en lecture et en criture par les processeurs de lacarte mais aussi par le CPU.

Les GPU embarquent jusqu 128 (G80) ou 240 processeurs de fluxchacun (G200), cadencs jusqu 1500MHz, et rpartis en diffrentes ca-tgories, abords dans la section 1.3.2.2. Ces processeurs sont nommsprocesseurs de flux en raison de leurs natures : ils sont en effet capables detraiter, de faon parallle, un ensemble de donnes lmentaires prsentsous la forme dun flux.

Chacun de ces processeurs fonctionne en mode SIMD parallle /CREW, il reoit donc un ensemble dinstructions qui sera excut sur latotalit des donnes du flux. Ils sont de plus tous capables de gather, maispas de scatter : ils peuvent accder nimporte quelle adresse mmoireen lecture, mais pas en criture (voir sections 1.2.1 et 1.2.3).

Les processeurs dun GPU sont organiss en pipeline que nous nousproposons de dcrire.

1.3.2.2 Pipeline graphique actuel

Nous donnons tout dabord quelques dfinitions utiles.

Dfinition 1.5 Un vertex est un point gomtrique 3D, sommet dun ou plusieurs polygones.

Dfinition 1.6 Un fragment est une partie lmentaire dune scne en cours de rendu qui pour-rait occuper lespace dun pixel dans limage finale. La diffrence entre pixel etfragment est une vue desprit : alors que le pixel est un "point" de couleur vi-sible par lutilisateur, le fragment est le "point" de couleur que le programmemanipule, provenant de diffrentes textures, et dont le traitement produira unpixel.

Dfinition 1.7 Un shader est un programme vocation graphique, gnralement court, que ledveloppeur peut spcifier en diffrents langages, maniant des vertex ou des frag-ments et permettant de contrler un sous-ensemble des processeurs dun GPU.


Dfinition 1.8 Un pipeline est une squence ordonne de diffrents tages. Chaque tage rcu-pre ses donnes de ltage prcdent, effectue une opration propre et renvoie sesrsultats ltage suivant.

Un pipeline est dit rempli lorsque tous ses tages sont mis contribu-tion simultanment, cest son utilisation optimale, diminuant le nombredtapes globales dexcution dun algorithme par rapport une versionsquentielle classique.

Le pipeline des GPU actuels est reprsent figure 1.5. Il est composde trois tages programmables, pilots par les shaders, et dun tage non-programmable, le rasterizer.

CPU

GPU

Vertex Shader

Fragment Shader

Geometry Shader

RasterizerClipping / Culling

Mmoire vido

Flux de vertexFlux de vertex

. . .. . .

Flux de vertexmodifis

(position, couleur,normale,)

Flux de vertexmodifis

(position, couleur,normale,)

Flux de vertex avecmaillage modifi

Flux de vertex avecmaillage modifi

Flux defragments

Flux defragments

Primitivegomtrique, ou

ensemble deprimitives

Primitivegomtrique, ou

ensemble deprimitives

ProgrammableProgrammable



Application 3D

Domaine 3DDomaine 3D

Domaine 2DDomaine 2D

Envoi detexturesEnvoi detextures

Rcuprationde textures

Rcuprationde textures

LectureEcritureLectureEcriture

TextureTexture

TextureTexture

Flux defragmentsmodifis

Flux defragmentsmodifis

Click

to bu

y NOW

!PD

F-XChange

www.docu-track

.com C

lick t

o buy

NOW

!PD

F-XChange

www.docu-track

.com

Figure 1.5 Pipeline GPU. Les primitives gomtriques sont envoyes sous la formedun flux de vertex au Vertex Shader, programm par le dveloppeur, et pouvant modifierles attributs des vertex. Le flux sortant est dirig dans le Geometry Shader, deuximeshader programmable, ayant la capacit de modifier le maillage, donc le nombre de vertex.Le Rasterizer transforme ensuite ces vertex et primitives en une image compose defragments. Le flux de fragments rsultant est pris en charge par le Fragment Shader,troisime et dernier shader du pipeline programm par le dveloppeur, qui se charge dedonner une couleur finale aux fragments / pixels. Le rsultat est crit en mmoire vido,dans une texture ou dans le framebuffer. Le CPU a la possibilit de lire et dcrire danscette mmoire, suivant certaines restrictions.

Pour traiter la gomtrie dune image, les donnes sont premirementenvoyes au GPU. Ces donnes sont les primitives gomtriques de lascne rendre, dcrite via les commandes dune API graphique, et repr-sents sous la forme dun flux de vertex.

Ces vertex sont les donnes dentre du premier tage du pipeline, leVertex Shader. Celui ci a pour vocation de modifier les diffrents attributsdes vertex : il peut les changer et leur en donner de nouveaux, commecouleur et normale. Le flux sortant est de mme taille et est compos des


mmes vertex modifis. Il a accs la mmoire de la carte en lecture etpeut y crire ses rsultats. Sa principale utilit est de dplacer les objetspour donner limpression de mouvement dune frame une autre.

Le flux sortant du prcdent shader est le flux dentre pour ltagesuivant du pipeline, le Geometry Shader. Ce shader permet de modifierla gomtrie de la scne, ici le maillage gomtrique pass la carte. Ilpeut en effet ajouter ou supprimer des vertex et en modifier les attributs.Le flux de sortie contient un ensemble de vertex de taille potentiellementdiffrente celle du flux dentre. Il a galement accs la mmoire enlecture, et en crire pour ses rsultats. Ce shader est en particulier utilispour les mthodes de raffinement de maillage ou daugmentation dedtails sur les modles gomtriques, comme le Displacement Mapping,technique permettant de crer le relief en surface dun objet en dplaantcertains points de cette surface en fonction de valeurs contenues dans unetexture de hauteur (displacement map).

Ltage suivant dans le pipeline est le Rasterizer. A partir du maillagecompos des vertex sortant du shader prcdent, la gomtrie finale estprojete sur une grille de la taille de limage de sortie, et les primitivesgomtriques sont divises en fragments. Cest cet tage du pipelinequon ralise galement quelques oprations supplmentaires amliorantla vitesse dexcution des calculs suivants, telles que clipping (suppressiondes objets extrieurs au cne de vision donc non visibles) ou back-faceculling (suppression de polygones suivant leur orientation par rapport la camra : un polygone prsentant son "dos" la camra nest pas censtre visible). Les fragments rsultants possdent des coordonnes, corres-pondant la position finale dans limage. Le flux de fragment sortant estensuite dirig vers le dernier tage du pipeline.

Le Fragment Shader est le troisime et dernier tage programmable dupipeline. Cest le shader le plus important car pour chaque fragment deson flux dentre, il lui attribue sa couleur finale, en fonction de lclai-rage, des rflexions et rfractions lumineuses et de diverses techniquesde rendu pouvant interroger des textures tierces. Comme les shaders pr-cdents, il peut consulter la mmoire de la carte mais ne peut y crirenimporte o. Il a seulement lautorisation dcrire aux coordonnes dufragment quil est en train de traiter, coordonnes quil ne peut donc mo-difier.

Le flux de fragments calculs, ou shads, est crit en mmoire. Classi-quement, la structure accueillant ces donnes est le framebuffer, directe-ment affich lcran, image ne ncessitant pas un transit supplmentairepar le CPU. Nanmoins, il est possible dcrire cette image dans une tex-ture, pouvant tre utilise par un autre shader ou rcupre sur CPU.

Jusqu la cinquime gnration de cartes graphiques, les processeursembarqus taient catgoriss, certains servant au traitement de vertex,les Vertex Units, dautres celui des fragments, les Fragment Units. Cela apour inconvnient de pouvoir crer un bottleneck : lorsque les Vertex Unitssont surchargs, lutilisation des Fragment Unit nest pas optimale et peutmme tre extrmement diminue, et rciproquement. Avec la mise dis-position de la sixime gnration de cartes graphiques (GeForce 8), lesprocesseurs ne sont plus spcifiques, ils peuvent maintenant servir aussi


bien la gestion des vertex qu celle des fragments. Cela permet de rem-plir au mieux le pipeline et dviter le bottleneck prcdent. Larchitecturede ces cartes est dite unifie.

1.4 Comment programmer en GPGPU ?

Adapter un algorithme gnrique pour un calcul sur matriel spcia-lis, tel un GPU, demande de prendre en compte quelques aspects spci-fiques de ces architectures.

Originairement, les GPU sont destins au traitement et laffichage degraphismes ; ils manient de faon naturelle vertex et pixels, sont capablesde rasterizer des primitives et dutiliser quelques structures simples dedonnes tout au mieux. Les liberts dont jouissent les dveloppeurs surCPU, concernant types complexes de donnes, gestion de mmoire ourichesse des jeux instructions, sont alors drastiquement rduites par leslimitations matrielles inhrentes aux architectures de ces cartes. Il a donct ncessaire de repenser le portage dalgorithmes gnriques sur GPU.Un modle de programmation classique en GPGPU en a merg, ainsique diffrentes astuces largement employes.

Dans cette section, aprs un tour dhorizon des langages de program-mation disponibles sur GPU, nous exposons ce modle de programmationGPGPU, ainsi que les contraintes et astuces lies ce type de program-mation. Nous continuons avec une rapide prsentation de deux langagesutiliss en GPU, Cg et CUDA, puis les comparons sur limplmentationde quelques techniques usuelles de calcul parallle.

Dans les chapitres 4, 5 et 6, nous dtaillerons trois applications dediffrents domaines et dimportante ampleur, utilisant les mthodes etastuces dcrites ci-dessous pour contourner les contraintes de program-mation sur GPU afin dobtenir des gains en vitesse significatifs.

1.4.1 Langages

Le but initialement graphique des GPU a bien entendu dirig lesconstructeurs initialement proposer des langages destins ce type decalcul, cest--dire dont les instructions utilisent les branchements mat-riels spcifiques, destins des oprations de type mult-add, largementutilises en synthse dimages. Mme si dautres langages plus gnra-listes ont depuis t prsents, le choix reste bien plus restreint sur GPUque sur CPU. On sintresse ici faire un tour dhorizon non-exhaustifdes langages existants sur GPU. En plus des langages bas niveau typeAssembleur dont il ne sera pas fait mention dans cet expos, manipulantdirectement le contenu de registres des units programmables sur la carte,les langages de plus haut niveaux disponibles sur GPU se distinguent endeux grandes catgories : les Shading Languages, dont les instructions sontprincipalement destines aux calculs graphiques, et ceux dont lobjectifest le calcul gnrique, que lon nommera langages GPGPU.

1.4.1.1 Shading Languages

Ces langages ont pour point commun de proposer au dveloppeur desjeux dinstructions spcifiques la gnration dimages, ils sont orientsmatriel. Ils permettent dcrire des shaders. Ceux ci seront excuts par

1.4. Comment programmer en GPGPU ? 25

les units matrielles spcifiques, Vertex Unit et Fragment Unit, ces deuxtypes dunits tant unifis dans les dernires gnrations de cartes.

Cg, HLSL, GLSL Ces trois langages, respectivement proposs par NVi-dia [147, 52], Microsoft [178, 154] et 3DLabs [195], ont t dveloppsconjointement et sont donc trs similaires. Ce sont les shading languagesles plus usits. Les syntaxes et smantiques proposes ont t dlibr-ment fixes proches des instructions du C++, par soucis de simplicit. Leslments qui ont effectivement motiv ce choix sont la portabilit entrediffrents systmes dexploitation et/ou modles de GPU et la possibilitdun dveloppement rapide. Un compromis ncessaire entre ces lmentset une volont de performance a amen ces langages possder des ins-tructions exploitant directement les units matrielles de la carte, propo-ses via une syntaxe de type C et permettant de raliser les oprations debases et dautres plus spcifiques de la gnration dimages de synthse.Ces langages sont compilables et multi programmes : le dveloppeur doitcrire un shader pour chaque tage programmable du pipeline : VertexShader, Geometry Shader et Fragment Shader. Chacun a ses particularits,en particulier les types de donnes entrant et sortant. Lensemble de cesshaders est encastr dans un code C++ englobant, pilotant la carte gra-phique. Les rares diffrences entre ces langages se rsument deux prin-cipaux points. Premirement, ils ne supportent pas tous les mmes API :HLSL est exclusivement utilisable avec DirectX, GLSL avec OpenGL, etCg a la capacit dutiliser les deux. Le second point est li la gestiondes diffrents modles de cartes : alors que GLSL ne propose pas de sous-ensemble dinstructions ddis chaque modle, Cg et HLSL exploitentcette ide, sous la notion de profil, aborde dans la section 1.4.5.2.

Sh Tout comme Cg, HLSL et GLSL, Sh [151], dvelopp par le ComputerGraphics Lab de lUniversity of Waterloo, est un langage encastr dans leC++, avec une syntaxe proche du C permettant dcrire des shaders para-mtrs. Il est la fois orient vers le calcul graphique et la programmationgnrique. Sa particularit la plus notoire est dtre bas sur le traitementde flux de donnes. RapidMind [107] est le successeur commercial de Sh,il est utilis dans un nombre important de domaines ncessitant une cer-taine puissance : 3D, traitement de signaux, finance,. . .

1.4.1.2 Langages GPGPU

Lutilisation des shading languages pour de la programmation gn-rique nest pas des plus aise. Le dveloppeur les employant est contraintdadapter ses algorithmes un modle de calcul bas sur des primitivesgomtriques et des textures, ce qui nest pas toujours facile ni mmepossible. Des moyens pour programmer les GPU sans pour autant avoirbesoin de connaissances en graphisme ont naturellement suscit un int-rt grandissant. Diffrents langages ont mergs de projets industriels ouuniversitaires.

Tous ces nouveaux langages ont comme dnominateur commun dtrede plus haut niveau que les shading languages, en proposant plus de pos-sibilits et en se sparant totalement des notions graphiques : texture, sha-der, vertex ou fragment ny ont plus de sens. Les plus importants langagesGPGPU sont prsents dans la suite.


CUDA CUDA [25, 168], Compute Unified Device Architecture, est le der-nier n des langages de NVidia, pouvant tre utilis partir de la siximegnration de cartes graphiques de ce constructeur (architectures G80 etplus rcentes). Quelques unes de ses particularits sont dtre encastrdans du code C++ en en dfinissant seulement quelques extensions, demettre disposition une mmoire partage et rapide, ou de supporterdiffrents types doprations scalaires, en particulier les oprations surentiers et bit bit. Cest aussi le premier langage exploiter lunificationdes shaders sur les architectures G80 de NVidia. Dans le domaine du trai-tement dimages, il est de plus en plus employ ; Young et Jargstorff pro-posent dans [254] quelques implmentations astucieuses dalgorithmesclassiques de ce domaine. Une prsentation plus dtaille de CUDA estpropose dans la section 1.4.6.

OpenCL Le trs rcent OpenCL [164, 234, 165] (Open Computing Lan-guage) a t annonc par Apple au sein du Compute Working Group, formpar le Khronos Group (regroupant 3DLabs, Apple, AMD, NVidia, ARM, Erics-son et dautres universitaires et industriels). Ces partenaires souhaitentmettre disposition un langage open source, dans la veine dOpenGL [214]et OpenAL [39] et ont pour ambition de faire dOpenCL le standardlibre pour le calcul GPGPU,

Quelques applications de la programmation des processeurs ...

Documents

Transcript of Quelques applications de la programmation des processeurs ...