Algorithmes de la morphologie mathématique pour - Pastel - HAL

More documents

Recommendations

Info

Algorithmes de la morphologie mathématique pour les architectures orientées fluxJaromír BRAMBORà l’intérieur d’une forme, pour interpoler les couleurs, les vecteurs décrivant les propriétés de la surface,les coordonnées des textures et peut même être utilisée pour interpoler d’autres données qui n’ont pas uncorrespondant direct dans le graphisme 3D.Après la création et l’obtention des paramètres interpolés des vertex, les fragments passent à l’unitéde traitement des fragments décrite sur la fig. 3.18 par le bloc Fragment processeur et appelée égalementpar le terme anglais fragment shader. Il s’agit d’une unité de traitement qui traite le flux de la mêmemanière que le Vertex processeur. C’est-à-dire que nous pouvons accéder aux paramètres globaux etmême échantillonner les textures mais nous ne pouvons pas influencer le traitement d’autres fragments oucréer de nouveaux fragments. Dans les applications graphiques 3D, cette unité est utilisée pour un calculintensif de la couleur locale du fragment et implémente la partie principale du calcul de l’illumination dela partie de la surface 3D qui correspond au fragment. C’est pourquoi ce bloc fonctionnel est fortementparallélisé, plus que celui du processeur des vertex, et son implémentation matérielle est optimisée pourl’accès massif aux textures, ce qui se traduit par une structure particulière des mémoires caches qui ontpour but d’exploiter au maximum la localité des données lors d’échantillonnage des textures.Les fragments traités passent dans l’unité suivante que nous désignons comme unité de post-traitementqui correspond dans la figure 3.18 au bloc Raster opération et qui regroupe tout un tas de fonctions utiles.Parmi elles, nous trouvons, selon les capacités de notre GPU cible, le fusionnement (appelé blendingavec les valeurs du framebuffer), application d’une transformation fixe sur les valeurs de la couleur, lesopérations du masque, les tests sur les valeurs, la convolution, la fonction stencil de masquage conditionnel,suppression des fragments selon la valeur de leur profondeur, accumulation des valeurs. Pour plusd’information, nous renvoyons le lecteur à la littérature Gra03, WNDS99 .Le flux des pixels qui sortent de ce bloc est écrit continuellement dans le framebuffer. Le framebuffera aujourd’hui de larges possibilité qui ne se restreignent pas seulement à un vidéobuffer. En effet, il estpossible d’y connecter diverses zones de mémoire d’un GPU et obtenir ainsi la sortie des résultats quiest configurable par l’utilisateur lors de l’exécution du programme dans les GPP.Pour conclure, nous devrions noter que l’évolution de la structure du pipeline graphique est constante.Il est fort probable que les fonctionnalités dont nous disposons à présent seront élargies, comme c’étaitdéjà le cas à plusieurs reprises. Par exemple, avant 2004, nous n’avions pas encore la possibilité d’accéderaux textures à partir des Vertex programmes. En même temps, le schéma de blocs que nous avonsprésenté sur la fig. 3.18, page 52, est assez général et devrait être valable dans sa forme encore un certaintemps. Cette remarque est due au fait que la recherche et le développement dans ce domaine sont trèsintensifs et nous pouvons nous attendre à des changements plus ou moins importants. Comme exempled’une implémentation non standard du schéma classique du pipeline graphique, nous pouvons citer l’architectureATTILA MGR+ 05a, MGR + 05b dans laquelle les unités de traitement des vertex et des fragmentssont réunies dans des blocs fonctionnels universels et programmables. Cette architecture distribue lesmoyens matériels pour le calcul en stream selon l’intensité du traitement dans un bloc ou l’autre et donneaux unités universelles soit la fonction d’un vertex processeur, soit d’un fragment processeur. Il s’agitd’une architecture tout-à-fait intéressante pour notre traitement dans lequel nous utilisons largement plusles unités des fragments que celles des vertex et où il serait avantageux de disposer de maximum demoyens matériels dédiés au traitement des fragments, même temporairement, pour ainsi obtenir uneparallélisation encore plus forte du traitement en flux.3.4.5.4 Interfaces de programmation des GPP - DirectX et (Open)GLIl faut disposer d’outils qui permettent aux programmeurs des applications sur les GPP de facilementutiliser les fonctionnalités matérielles des GPU. Deux groupes des API sont actuellement disponibles. Lepremier groupe est constitué par DirectX de Microsoft. Le deuxième groupe est constitué par OpenGLde Silicon Graphics Incorporated et par d’autres dont la syntaxe et les fonctionnalités sont très prochesd’OpenGL et dont nous pouvons citer Mesa ou l’API OpenGL ES destiné pour les systèmes embarqués.Les deux offrent une interface qui permet de manier les GPU mais elles diffèrent dans la philosophie54
Jaromír BRAMBOR3.4. MODÈLE STREAM DU CALCUL ET LES ARCHITECTURES ASSOCIÉESde leur construction. Tandis que DirectX est lié aux technologies de Microsoft, OpenGL est modulablepar extensions où chaque fabricant des architectures de traitement 3D peut exposer les fonctionnalitésde son matériel par une extension propriétaire. La standardisation de la structure de base du OpenGLest effectuée par OpenGL Architectural Review Board, ARB, qui regroupe les équipes issues de grandsfabricants de solutions pour le graphisme. Les extensions du standard OpenGL qui ont été approuvées parARB mais qui n’étaient pas, pour différentes raisons, incluses au standard sont appelées ARB Extensionset exportent le plus souvent l’interface des fonctionnalités des GPU les plus récents.Les solutions logiciels basées sur OpenGL (ou Mesa) ont un grand avantage par rapport au DirectX– c’est leur facilité de portage vers une plateforme de système d’exploitation différente. Nous avons utilisépour nos expériences les deux plateformes pour finalement migrer totalement vers Mesa car nousvoulions garder la portabilité de nos solutions et effectuer des tests comparatifs pour des systèmes d’exploitationdifférents (Windows XP et une distribution de Linux).Un autre avantage d’OpenGL pourrait également être mentionné. C’est le fait que la plupart deslangages de script (e.g. Python, Haskell) ont la possibilité de programmation des GPU via une bibliothèquecompatible avec OpenGL même si les fonctions qu’ils offrent n’incluent pas toujours les ARBExtension dont nous aurions besoin pour notre travail. Pour plus de détails sur ces interfaces, nous renvoyonsle lecteur à la littérature traitant d’OpenGL WNDS99, HAL04, Dal03, KBR03 et à la littérature traitant deDirectX Gra03, Mig04 .3.4.5.5 Langages d’ombrage pour le temps réel - Cg, GLSL, HLSLComme les processeurs graphiques ont évolué à partir des pipelines fixes ou configurables vers lespipelines programmables, les langages de haut niveau destinés aux blocs programmables à l’intérieurd’un GPU ont fait leur apparition. On les appelle les langages d’ombrage pour le temps réel (angl.Shading languages), avec une spécification du temps réel dans leur nom pour les distinguer des langagesd’ombrage (classiques) destinés au rendu des images et des scènes complexes et où l’exigence du tempsréel ne figure pas (e.g. RenderMan de Pixar Animation Studios). Leur nom ombrage (angl. shaders) estdérivé du fait que le traitement des vertex et des fragments est utilisé pour le calcul des ombres ou del’illumination locale dans la synthèse des images.Le premier des langages d’ombrage pour le temps réel que nous mentionnons est nommé Cg FK03 . Sonnom est une abréviation de C for graphics et il s’agit d’un langage développé par NVidia. Il s’incorporeà travers des bibliothèques fournies par le fabricant dans les deux API présentés. Ainsi, nous pouvonsl’utiliser avec le DirectX et aussi avec OpenGL. Le deuxième langage d’ombrage est nommé HLSL(High Level Shading Language) de Microsoft et vient de compléter DirectX. Le troisième est nomméGLSL (OpenGL Shading Language) et complète OpenGL via les ARB Extensions.Tous les trois sont largement inspirés du langage C, dont ils ont la syntaxe, mais ils ont défini leurspropres types et identificateurs qui reflètent les types utilisés dans le traitement sur les GPU. Ainsi,il n’est pas difficile pour un programmeur connaissant le langage C d’adopter ces langages. Pour unecomparaison des fonctionnalités de ces trois langages, nous renvoyons le lecteur à un article Lov05 .Ces langages nous servent comme base pour le traitement à l’intérieur du GPU. La grande partie del’algorithme de traitement d’images sur les GPU est implémentée par ces langages car c’est le GPU quiassure l’exécution tant que le programme d’application, exécuté dans le GPP, ne fait que coordonner letravail du GPU, assure l’envoi des commandes graphiques et se charge de la lecture des résultats.3.4.6 Calcul sur les flux de données avec les GPU3.4.6.1 GPGPUNotre manière de travailler entre dans la catégorie du calcul général sur les processeurs graphiquesqui s’est différenciée du calcul classique de rendu d’images 3D et constitue aujourd’hui une branche55
Page 2 and 3:
Marques commerciales déposées et/
Page 4 and 5: Cette page est blanche par intentio
Page 7 and 8: ALGORITHMES DE LA MORPHOLOGIE MATH
Page 9 and 10: ALGORITHMS OF MATHEMATICAL MORPHOLO
Page 11: Table des matièresGuide de thèse
Page 14 and 15: Algorithmes de la morphologie math
Page 30 and 31: Cette page est blanche par intentio
Page 36: Algorithmes de la morphologie math
Page 39 and 40: Jaromír BRAMBOR3.2. FACTEURS INFLU
Page 41 and 42: Jaromír BRAMBOR3.2. FACTEURS INFLU
Page 43 and 44: Jaromír BRAMBOR3.3. CONSOMMATION D
Page 45 and 46: Jaromír BRAMBOR3.4. MODÈLE STREAM
Page 53: Jaromír BRAMBOR3.4. MODÈLE STREAM
Page 59 and 60: CHAPITRE 4Formalisme fonctionnelado
Page 61 and 62: Jaromír BRAMBOR4.2. HASKELL ET LES
Page 63 and 64: Jaromír BRAMBOR4.3. PRIMITIVES DE
Page 67 and 68: Jaromír BRAMBOR4.4. PRIMITIVES DU
Page 77 and 78: Jaromír BRAMBOR4.5. MODÈLE FORMEL
Page 97 and 98: Partie IIAlgorithmeset les skeleton
Page 99 and 100: CHAPITRE 5Algorithmes de voisinagen
Page 101 and 102: Jaromír BRAMBOR5.1. ALGORITHMES É
Page 103 and 104: Jaromír BRAMBOR5.1. ALGORITHMES É
Page 105 and 106:
Jaromír BRAMBOR5.1. ALGORITHMES É
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Jaromír BRAMBOR5.3. ALGORITHMES G
Page 117 and 118:
Jaromír BRAMBOR5.3. ALGORITHMES G
Page 119 and 120:
Jaromír BRAMBOR5.4. ALGORITHMES PO
Page 121 and 122:
Jaromír BRAMBOR5.4. ALGORITHMES PO
Page 123 and 124:
Jaromír BRAMBOR5.5. RÉSULTATS EXP
Page 125 and 126:
Jaromír BRAMBOR5.6. RÉCAPITULATIO
Page 127 and 128:
CHAPITRE 6Permutation SIMD des arra
Page 129 and 130:
Jaromír BRAMBOR6.2. APPROCHE MACRO
Page 131 and 132:
Jaromír BRAMBOR6.2. APPROCHE MACRO
Page 133 and 134:
Jaromír BRAMBOR6.3. ALGORITHMES RA
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Jaromír BRAMBOR6.4. NOTES SUR L’
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
CHAPITRE 7Algorithmes de voisinaged
Page 149 and 150:
Jaromír BRAMBOR7.1. PARTICULARITÉ
Page 151 and 152:
Jaromír BRAMBOR7.3. SKELETON ALGOR
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
CHAPITRE 8Algorithmes de la dilatat
Page 167 and 168:
Jaromír BRAMBOR8.2. APPROCHE EMPLO
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
Page 177 and 178:
CHAPITRE 9Algorithmes et complexit
Page 179 and 180:
Jaromír BRAMBOR9.4. ESTIMATION DE
Page 181 and 182:
Jaromír BRAMBOR9.5. EXEMPLE D’ES
Page 183 and 184:
Page 185 and 186:
Page 187 and 188:
Page 189 and 190:
Conclusion et perspectives
Page 191 and 192:
Conclusion et perspectivesConclusio
Page 193 and 194:
Jaromír BRAMBORtations sur les GPU
Page 195 and 196:
Jaromír BRAMBORsemble inadapté, d
Page 197 and 198:
Annexe
Page 199 and 200:
Annexe AFonctions pour assurer l’
Page 201 and 202:
Annexe BDéfinitions des fonctions
Page 203 and 204:
Jaromír BRAMBORtestSIMD :: PVec I
Page 205 and 206:
Liste des termes et des abréviatio
Page 207 and 208:
Liste des figures1.1 Évolution du
Page 209 and 210:
Jaromír BRAMBORListe des figures7.
Page 211 and 212:
Liste des tableaux1.1 Évolution de
Page 213 and 214:
Bibliographie[AD03] Marco ALDINUCCI
Page 215 and 216:
Jaromír BRAMBORBibliographie[Cou02
Page 217 and 218:
Jaromír BRAMBORBibliographie[Gha99
Page 219 and 220:
Jaromír BRAMBORBibliographie[Lem96
Page 221 and 222:
Jaromír BRAMBORBibliographie[RS01]
Page 223 and 224:
Jaromír BRAMBORBibliographie[Wik06
Page 225 and 226:
IndexSymbols+, fonction . . . 62, 7
Page 227 and 228:
Jaromír BRAMBORINDEXICL . . . . .
Page 229:
Jaromír BRAMBORINDEXspecNgbSQR, fo
show all

Algorithmes de la morphologie mathématique pour - Pastel - HAL

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?