Brambor Doctoral Thesis

Collge doctoral
N attribu par la bibliothque

THSE
pour obtenir le grade de
Docteur de lcole des Mines de Paris
Spcialit Morphologie Mathmatique
prsente et soutenue publiquement
par
Jaromr BRAMBOR
le 11 Juillet 2006
ALGORITHMES DE LA MORPHOLOGIE
MATHMATIQUE POUR LES ARCHITECTURES
ORIENTES FLUX
Directeur de thse : Michel BILODEAU
Jury
M. Gilles BERTRAND Examinateur
M. Michel BILODEAU Examinateur
M. Pierre BONTON Rapporteur
M. Laurent CHABIN Examinateur
M. Dominique JEULIN Prsident
M. Michel PAINDAVOINE Rapporteur
Marques commerciales dposes et/ou utilises dans un ou plusieurs pays et leurs propritaires respectifs
Marques Propritaire
Aphelion Amerinex Applied Imaging, Inc. et ADCIS SA.
AMD, AMD Athlon, AMD Opteron Advanced Micro Devices, Inc.
ARM, ARM11 ARM Limited
ATI, CrossFire, Radeon ATI Technologies Inc.
SuperH Hitachi Ltd.
IBM, PowerPC International Business Machines Corporation.
IEEE, POSIX The Institute of Electrical and Electronics Engineers, In-
corporated.
Intel, Itanium, MMX, Pentium Intel Corporation
MATLAB The MathWorks, Inc.
DirectX, Microsoft, Microsoft Press, Windows, Win32, Xbox Microsoft Corporation
AltiVec, MOTOROLA, Motorola, Inc.
GeForce, NVidia, NVIDIA Quadro, SLI NVIDIA Corporation
PCI Express PCI-SIG
RenderMan Pixar Animation Studios
OpenGL, OpenGL ES Silicon Graphics Incorporated
Sony, PlayStation Sony Corporation
Sun, VIS Sun Microsystems, Inc.
Crusoe, Efceon, Transmeta Transmeta Corporation
TSMC Taiwan Semiconductor Manufacturing Company, Ltd.
Linux Linus Torvalds
Wikipedia Wikimedia Foundation, Inc.
Jaromr et Blanka
mes parents
et
Julie et Maxim Jaromr
ma famille
Cette page est blanche par intention
Remerciements
Cette thse est laboutissement dun projet de recherche de plusieurs annes. Ce projet doit un grand
merci tous ceux qui lont soutenu directement ou indirectement lors de sa ralisation et tous ceux qui
ont suivi la cration et la nalisation de cette thse, de loin ou de prs.
Au Centre de Morphologie Mathmatique et ses membres
Jaimerais exprimer mes sincres remerciements lcole Nationale Suprieure des Mines de Paris
et en particulier son Centre de Morphologie Mathmatique Fontainebleau reprsent par Monsieur
Fernand Meyer pour mavoir accueilli et mavoir permis de travailler sur le sujet de mon projet de re-
cherche.
Mes remerciements sadressent galement Monsieur Michel Bilodeau, mon directeur de thse, pour
le temps quil a consacr lencadrement de mon projet et de ma thse et pour ses avis sur mon travail.
Un merci sadresse Monsieur Jean Serra que japprcie beaucoup pour son travail effectu dans le
domaine de la morphologie mathmatique. Pour son travail qui inuence le traitement dimages depuis
des dcennies, qui conduit dautres chercheurs et qui les incite utiliser la morphologie mathmatique
et continuer de la dvelopper.
Un merci aussi aux autres membres du CMM Beatriz Marcotegui et Dominique Jeulin, Serge
Beucher, Jean-Claude Klein, Petr Dokldal, Etienne Decencire, Francis Bach et John-Richard Ordez
Varela pour leur prsence et leurs points de vue discuts au cours de sances de lectures et dexposs car
dans la science et la recherche, cest aussi leffet synergique qui importe et qui permet davancer plus
rapidement.
Je ne dois pas oublier de remercier deux membres non scientiques mais dont limportance au sein du
CMM est cruciale et chez qui japprcie leurs valeurs humaines et leur serviabilit. Mon merci sadresse
ainsi Catherine Moysan et Laura Andriamasinoro.
Aux partenaires du projet de recherche
Une partie de cette thse a t dveloppe dans le cadre du projet Medea+ PocketMM et nance
par le Ministre de lconomie, des Finances et de lIndustrie (MINFI) de la Rpublique franaise. Un
grand merci nos partenaires et en particulier STMicroelectronics pour nous avoir procur les outils
de dveloppement.
ma famille
Un merci spcialement chaleureux ma famille reprsente par ma femme Julie et mon ls Maxim
Jaromr, par Blanka, ma mre, in memoriam par Jaromr, mon pre, par mes surs Milena, Blanka et
So na et leurs familles pour la patience dont ils ont fait preuve lors de la rdaction du manuscrit et pour
le soutien quils mont prodigu dans les moments rudes et prouvants. Merci beaucoup.
5
Algorithmes de la morphologie mathmatique pour les architectures orientes ux Jaromr BRAMBOR
mes collgues en recherche
Mes collgues du Centre de Morphologie Mathmatique mritent, eux aussi, une part de remercie-
ment car cest eux qui ont donn lesprit multiculturel mon sjour Fontainebleau et qui mont aid
mettre au point mon franais oral travers des discussions portant sur les sujets scientiques et m-
taphysiques. Mes mercis sadressent
1
Eva Dokldalov, Mathilde Boehm, Thomas Walter, Thomas
Retornaz, Raf Enciaud, Costin Alin Caciu, Jess Angulo, Romain Lerallut, Gabriel Fricout, Timothe
Faucon, Thibauld Nion, Nicolas Laveau, Souhal Outal et Maxime Moreaud.
1
nomms par ordre croissant selon la distance topologique partir de mon bureau
6
Rsum
ALGORITHMES DE LA MORPHOLOGIE MATHMATIQUE
POUR LES ARCHITECTURES ORIENTES FLUX
cole des Mines de Paris
Jaromr BRAMBOR, 11 Juillet 2006
Mots cls : morphologie mathmatique, algorithmes rapides, ux de donnes, macro blocs SIMD, pro-
cesseurs graphiques, Haskell, description formelle, lambda calcul
Cette thse est consacre aux algorithmes de morphologie mathmatique qui peuvent considrer les
pixels dune image comme un ux de donnes. Nous allons dmontrer quun grand nombre dalgorithmes
de morphologie mathmatique peuvent tre dcrits comme un ux de donnes traversant des units
dexcution. Nous verrons que cette approche peut aussi fonctionner sur des processeurs gnriques
possdant un jeu dinstructions multimdia ou sur des cartes graphiques.
Nous prsentons dans un premier temps les possibilits offertes par les architectures grand public en
guise de traitements morphologiques et explorons ensuite leurs capacits dexcution parallle avec des
jeux dinstructions SIMD. Nous terminons cette partie en examinant les capacits de calcul parallle
lchelle des tches et des ls dexcution que nous apportent les processeurs plusieurs curs.
Pour dcrire les algorithmes en ux de donnes, nous proposons dutiliser le langage fonctionnel
Haskell, ce qui nous permettra de dcrire les briques de base de la construction des algorithmes de
morphologie mathmatique. On applique ces briques dans la description des algorithmes les plus cou-
ramment utiliss (dilatation/rosion, oprations godsiques, fonction distance et nivellements) ce qui
facilitera le portage de ces algorithmes sur plusieurs plate-formes.
Lapport principal de cette thse est quelle aborde un sujet important du point de vue pratique et
quelle explore les capacits SIMD des architectures multimdia en vue dassurer lexcution rapide des
algorithmes morphologiques travaillant sur le voisinage. Nous proposons pour la construction des algo-
rithmes morphologiques un mode dexcution original par macro blocs et nous tudions en profondeur
la transposition de cette ide aux architectures SIMD. Nous montrons que lutilisation des macro blocs
est particulirement intressante pour les architectures multimdia et nous montrons galement que les
algorithmes morphologiques proposs dans cette thse atteignent de meilleures performances que les
implmentations standard. Un nouveau champ souvre ainsi aux algorithmes dvelopps dans les appli-
cations de traitement dimages en temps rel.
Cette thse explore galement les processeurs graphiques et dmontre sur des rsultats exprimen-
taux quils sont, ds prsent, assez performants pour concurrencer les processeurs gnraux. Lapport
secondaire de cette thse est celui du formalisme fonctionnel bas sur le lambda calcul qui a t adopt
pour la description des algorithmes travaillant sur les ux de donnes.
7
Abstract
ALGORITHMS OF MATHEMATICAL MORPHOLOGY
FOR STREAM-ORIENTED ARCHITECTURES
cole des Mines de Paris
Jaromr BRAMBOR, 11 July 2006
Keywords : Mathematical Morphology, fast algorithms, stream of data, SIMD macro blocs, graphics
processors, Haskell, formal description, lambda calculus
This thesis deals with the algorithms of Mathematical Morphology that can consider the pixels of an
image as if they were a stream of data. We will show that a great number of algorithms of Mathematical
Morphology can be described by data ows (streams) passing through the operating units. We will see
that this approach can function on generic processors supporting a multi-media instruction set as well as
on graphics cards.
Firstly, we present the possibilities of main stream architectures for morphological processing and
then we explore their capacities in terms of parallel execution with SIMD instruction sets. Finally, we
examine the possibilities of parallel computing using tasks and threads on multi-core processors.
We propose to use the functional language Haskell for the description of algorithms operating on data
ows. This allows us to describe the building blocks that are used to construct morphological algorithms.
We apply these bulding blocks in the description of the most usually used algorithms (dilation/erosion,
geodesic operations, distance function and levelings). This will also facilitate the porting of these algo-
rithms onto several platforms.
The principal contribution of this thesis is to address an important subject from the practical point of
view and to explore SIMD capabilities of multi-media architectures to ensure the fast execution of mor-
phological algorithms working on neighborhood. We propose an original mode of execution by macro
blocks for the construction of morphological algorithms and we study in depth the transposition of this
idea to SIMD architectures. We show that the use of macro blocks is particularly interesting for multi-
media architectures. We also show that the morphological algorithms proposed in this thesis reach better
performances than standard implementations. Thus, a new eld opens to algorithms we have developed
here in real-time image processing applications.
This thesis also explores the graphics processors and shows on experimental results that they are
already powerful enough to compete with general processors. The secondary contribution of this thesis
is the functional formalism based on lambda calculus that is used to describe algorithms working on data
ows.
9
Table des matires
Guide de thse 15
I Introduction, bases thoriques
et appareil mathmatique 17
1 Motivation 19
1.1 volution en chiffres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2 Processeurs usage gnral les GPP et les GPPMM . . . . . . . . . . . . . . . . . . . 20
1.3 Processeurs graphiques les GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4 Au-del de lhorizon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2 tat de lart 25
3 Architectures 31
3.1 Taxonomie des architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.1 Taxonomie de Flynn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.2 Taxonomie de Duncan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Facteurs inuant la performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.1 Structure de larchitecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Frquence de(s) lunit(s) de calcul . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.3 Structure, capacit et frquence des mmoires . . . . . . . . . . . . . . . . . . . 38
3.2.4 Paralllisation des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.5 Paralllisation dexcution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.6 cartement et latence des instructions . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.7 Instructions spcialises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.8 Nombre de registres et leur dsignation . . . . . . . . . . . . . . . . . . . . . . 40
3.2.9 Approche limplmentation des algorithmes . . . . . . . . . . . . . . . . . . . 41
3.3 Consommation dnergie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4 Modle stream du calcul et les architectures associes . . . . . . . . . . . . . . . . . . . 44
3.4.1 Calcul sur les streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4.2 Architectures stream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4.3 Architecture de von Neumann et ses successeurs utiliss pour le calcul stream . . 46
3.4.4 Calcul stream sur les architectures SWAR plusieurs ls . . . . . . . . . . . . . 49
3.4.5 Pipeline graphique et les GPUs . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.4.6 Calcul sur les ux de donnes avec les GPU . . . . . . . . . . . . . . . . . . . . 55
11
4 Formalisme fonctionnel
adopt pour la morphologie mathmatique 59
4.1 Approche fonctionnelle et imprative . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2 Haskell et les bases des langages fonctionnels . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.1 Syntaxe du Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.2 Fonctions de base du Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.3 Primitives de stockage et de reprsentation des donnes . . . . . . . . . . . . . . . . . . 63
4.3.1 Types de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.4 Primitives du calcul comme skeletons algorithmiques . . . . . . . . . . . . . . . . . . . 66
4.4.1 Primitives du calcul squentiel . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.4.2 Primitives du calcul parallle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.4.3 Paquetage et dpaquetage des arrays pour le traitement SIMD . . . . . . . . . . 68
4.4.4 Sens du parcours, passage dun array un ux de donnes et vice versa . . . . . 70
4.4.5 Concept des "superpixels" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.5 Modle formel du traitement en pipeline graphique . . . . . . . . . . . . . . . . . . . . 76
4.5.1 Types de donnes utiliss dans le modle . . . . . . . . . . . . . . . . . . . . . 76
4.5.2 Primitive de calcul avec le pipeline graphique . . . . . . . . . . . . . . . . . . . 81
4.5.3 Modle du pipeline graphique des GPU . . . . . . . . . . . . . . . . . . . . . . 83
4.6 Primitives de la morphologique mathmatique . . . . . . . . . . . . . . . . . . . . . . . 84
4.6.1 Images dans la morphologie mathmatique . . . . . . . . . . . . . . . . . . . . 84
4.6.2 Grilles et voisinages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.6.3 lments structurants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.6.4 Extraction du voisinage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.6.5 Kernels de la morphologie mathmatique travaillant sur le voisinage local . . . . 92
4.6.6 Oprations du voisinage local avec un masque . . . . . . . . . . . . . . . . . . . 94
4.6.7 Travail sur le voisinage avec les superpixels . . . . . . . . . . . . . . . . . . . . 94
II Algorithmes
et les skeletons algorithmiques 97
5 Algorithmes de voisinage
non dpendants du sens du parcours 99
5.1 Algorithmes lmentaires pour les GPP . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.1.1 Approche nave limplmentation des oprations sur le voisinage . . . . . . . . 99
5.1.2 Division du problme en traitement de lintrieur et en traitement du bord . . . . 102
5.1.3 Gnralisation du travail sur le voisinage . . . . . . . . . . . . . . . . . . . . . 105
5.1.4 Approche des superpixels, algorithmes aux kernels complexes qui exploitent la
localit des donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.2 Algorithmes lmentaires pour les GPPMM . . . . . . . . . . . . . . . . . . . . . . . . 112
5.2.1 Skeletons algorithmiques GPPMM de base . . . . . . . . . . . . . . . . . . . . 112
5.2.2 Algorithmes concrets GPPMM de base de la morphologie mathmatique . . . . 113
5.2.3 Algorithmes SIMD bass sur lapproche des superpixels . . . . . . . . . . . . . 114
5.3 Algorithmes godsiques pour les GPP/GPPMM . . . . . . . . . . . . . . . . . . . . . 115
5.3.1 Ide de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.3.2 Itrations, n de propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.3.3 Note sur le travail godsique avec les superpixels . . . . . . . . . . . . . . . . 117
5.3.4 Travail SIMD avec les vecteurs paquets . . . . . . . . . . . . . . . . . . . . . 117
5.4 Algorithmes pour les GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.4.1 Traitement des bords de la texture sur les GPU . . . . . . . . . . . . . . . . . . 118
12
Jaromr BRAMBOR TABLE DES MATIRES
5.4.2 Approche utilisant les oprations de Minkowski . . . . . . . . . . . . . . . . . . 118
5.4.3 Approche utilisant lchantillonnage complexe des textures dans lunit de trai-
tement des fragments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.4.4 Approche utilisant les point sprites . . . . . . . . . . . . . . . . . . . . . . . . 120
5.4.5 Description des algorithmes pour les processeurs graphiques par le formalisme
fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.5 Rsultats exprimentaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
5.6 Rcapitulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6 Permutation SIMD des arrays applique
au changement de stockage des donnes vectorielles 127
6.1 Transpositions et rotations des arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.1.1 Dnitions des transpositions et des rotations . . . . . . . . . . . . . . . . . . . 128
6.2 Approche macro blocs aux transpositions et rotations . . . . . . . . . . . . . . . . . . . 129
6.2.1 Dcoupage des arrays en macro blocs et leur recollage . . . . . . . . . . . . . . 131
6.2.2 Lalgorithme gnrique travaillant sur les macro blocs . . . . . . . . . . . . . . 131
6.3 Algorithmes rapides SIMD de transposition et de rotation . . . . . . . . . . . . . . . . . 133
6.3.1 Fonctions shufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.3.2 Dcoupage sur les macro blocs et leur recollage sur les architectures SWAR . . . 134
6.3.3 Shufes utiliss pour les transpositions et rotations dun macro bloc . . . . . . . 135
6.3.4 Algorithme complet pour les transpositions et les rotations par SIMD . . . . . . 140
6.4 Notes sur limplmentation, rsultats exprimentaux . . . . . . . . . . . . . . . . . . . 141
6.5 Rcapitulation, perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
7 Algorithmes de voisinage
dpendant du sens prdni de parcours de limage 147
7.1 Particularit du sens du parcours pour le traitement SIMD du voisinage . . . . . . . . . 147
7.2 Skeletons applico-rductifs pour la propagation . . . . . . . . . . . . . . . . . . . . . . 150
7.3 Skeleton algorithmique de la propagation SIMD en 4-voisinage . . . . . . . . . . . . . . 151
7.3.1 Propagation lintrieur dun macro bloc . . . . . . . . . . . . . . . . . . . . . 151
7.3.2 Phase gnralise de la propagation . . . . . . . . . . . . . . . . . . . . . . . . 152
7.3.3 Propagations SIMD sur limage entire pour le 4-voisinage et la grille carre . . 153
7.3.4 Calcul de la fonction distance . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
7.3.5 Calcul des nivellements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
7.4 Approche utilisant les macro blocs avec la transposition directe . . . . . . . . . . . . . . 158
7.5 Notes sur limplmentation, rsultats exprimentaux . . . . . . . . . . . . . . . . . . . 159
7.6 Rcapitulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
8 Algorithmes de la dilatation/rosion
pour les lments structurants de la forme dun segment 165
8.1 Approche itrative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
8.2 Approche employant les algorithmes rutilisation des valeurs . . . . . . . . . . . . . . 167
8.2.1 Principe de lalgorithme de van Herk-Gil-Werman . . . . . . . . . . . . . . . . 168
8.2.2 Paralllisation pour les architectures SIMD . . . . . . . . . . . . . . . . . . . . 172
8.3 Rsultats exprimentaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
8.4 Rcapitulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
9 Algorithmes et complexit 177
9.1 Dnition dun algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
9.2 Complexit dun algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
9.2.1 Dnition de la complexit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
13
9.2.2 Les mesures de la croissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
9.3 Modlisation des performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
9.4 Estimation de la complexit et des performances pour les GPP/GPPMM . . . . . . . . . 179
9.4.1 Ide gnrale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
9.4.2 Estimation pratique pour les GPPMM . . . . . . . . . . . . . . . . . . . . . . . 180
9.5 Exemple destimation pratique de la complexit des algorithmes de voisinage . . . . . . 181
9.6 Estimation de la complexit et des performances pour les GPU . . . . . . . . . . . . . . 183
9.6.1 Transfert de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
9.6.2 Inuence du systme dexploitation et de lAPI . . . . . . . . . . . . . . . . . . 186
9.7 Rcapitulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Conclusion et perspectives 189
Annexe 197
Listes 205
Liste des termes et des abrviations 205
Liste des gures 207
Liste des tableaux 211
Bibliographie 213
Index 225
14
Guide de thse
Pour accentuer la bonne lisibilit de cette thse et pour permettre au lecteur de se crer une vision
globale du contenu avant mme dentamer la lecture, nous voudrions brivement exposer cette place
les points cls de la thse accompagns de quelques remarques. Ces quelques lignes vont, comme nous
le croyons, servir une meilleure orientation dans lensemble de ce trait.
Cette thse tudie la problmatique du calcul de la morphologie mathmatique sur les architectures
destines oprer sur les ux des donnes (streams) dont nous explorons deux groupes diffrents. Le pre-
mier groupe englobe les architectures pour le calcul gnral avec les fonctionnalits SIMD, le deuxime
les architectures des processeurs graphiques qui travaillent naturellement avec les ux de donnes et qui
ont une structure trs particulire. Nous nous intressons aux algorithmes rapides et utilisables en pra-
tique sur les deux groupes darchitectures et nous dcrivons plusieurs algorithmes originaux que nous
avons pu dvelopper.
Le document est divis en deux parties principales derrire lesquelles nous ajoutons une conclu-
sion gnrale suivie par les annexes. Nous commenons notre expos par la partie nomme Introduction,
bases thoriques et appareil mathmatique o nous introduisons tout dabord la problmatique des archi-
tectures, avec un accent sur le pipeline graphique et les processeurs graphiques. Ensuite, nous prsentons
le formalisme mathmatique fonctionnel. Tout le reste de cette thse sappuie fortement sur ce forma-
lisme. Il trouvera son utilit dans la description des algorithmes et nous verrons que son grand avantage
se situe dans sa faon de modliser qui permet de dcrire dune faon abstraite mme les algorithmes
troitement lis aux fonctionnements dune architecture particulire. Dans cette mme partie, nous in-
troduirons galement les outils algorithmiques de base, exprims laide de formalisme fonctionnel.
Il sagit surtout des primitives pour lorganisation de donnes et pour le parcours dune image. Nous
ajouterons galement les outils qui se focalisent directement la morphologie mathmatique et nous pr-
senterons la manire formelle de leur expression. Ces outils de base sont utiliss dans la partie suivante,
incorpors dans la description des algorithmes fonctionnels complexes.
La deuxime partie est consacre la description des algorithmes et les concepts algorithmiques.
Elle est organise par chapitres ddis chacun un thme particulier. Dans chaque chapitre, nous explo-
rons les possibilits dutilisation des architectures SIMD et des GPU pour les algorithmes relatifs la
morphologie mathmatique.
Nous y prsenterons tout dabord les algorithmes morphologiques gnriques et SIMD non-triviaux
dont le traitement ne dpend pas dun sens du parcours particulier, suivis par les algorithmes itratifs
et qui travaillent en utilisant un parcours spcique de limage pour nir par la prsentations des algo-
rithmes pour les lments structurants de la forme dun segment qui vont combiner toutes les techniques
prsents.
Nous abordons galement des sujets que nous jugeons prometteurs pour lavenir car ils se consacrent
aux traitements morphologiques sur les processeurs graphiques. Le travail avec ces processeurs est par-
ticulier mais il a beaucoup en commun avec les traitements SIMD qui seront dcrits pralablement.
Dans les algorithmes pour les GPU nous utiliserons avec avantage le style de travail que nous dcrivons
pour les architectures SIMD et nous proposerons les algorithmes et les solutions pratiques adaptes au
traitement sur les processeurs graphiques.
15
Nous dcrivons galement les notions de base pour pouvoir exprimer le cot dun algorithme. Sa-
chant que dans la pratique cest surtout le cot exprim en termes de temps du calcul qui nous intresse
le plus, nous prsentons les techniques envisageables pour une telle tude de complexit.
Nous allons terminer cette thse avec une conclusion gnrale prsentant le sommaire des rsultats
obtenus et avec des perspectives qui ouvrent la possibilit dune prochaine continuation des recherches
portant sur le sujet trait.
Lannexe contient les dnitions auxiliaires des fonctions en langage fonctionnel. Nous navons pas
inclus ces dnitions dans le texte principal pour deux raisons nous avons estim que leurs noms
saisissaient bien le sens intuitif de leur comportement et on a voulu ne pas encombrer le texte principal
avec des dtails qui pourraient dtourner lattention du lecteur du sujet expos. En mme temps, pour
prsenter cette thse en tant que conception complte, nous ne voulions pas les omettre et nous les
incluons ainsi dans lannexe.
Nous incitons le lecteur utiliser la version lectronique de cette thse. Elle lui offre les possibilits
hypertexte et facilite ainsi la liaison partir du texte aux ressources bibliographiques, aux dnitions des
termes et surtout aux dnitions des fonctions dans le formalisme fonctionnel. Surtout pour ce dernier,
la version lectronique peut savrer un outil trs pratique qui peut, en cas de doute, considrablement
amliorer lorientation dans les algorithmes.
La bibliographie elle-mme est galement dote des fonctions hypertexte qui permettent de visualiser
directement les sources souhaites, bien entendu les sources bibliographiques ayant une version en ligne
que nous avons pu consulter.
16
Partie I
Introduction, bases thoriques
et appareil mathmatique
CHAPITRE 1
Motivation
1.1 volution en chiffres
Une tude des activits du secteur des circuits intgrs effectue en 1965 par Gordon Moore
1
lui
a permis destimer lvolution de ce secteur comme une tendance exponentielle. Moore se basait sur
le nombre de composantes par circuit intgr et il a inclus dans son observation les circuits mis sur le
march pendant les annes 1959-1965.
1000
10000
100000
1e+06
1e+07
1e+08
1e+09
1e+10
1970 1975 1980 1985 1990 1995 2000 2005 2010
N
o
m
b
r
e

d
e

t
r
a
n
s
i
s
t
o
r
s
Lanne dintroduction
4004
8008
8080
8086
286
386
486
Pentium
Pentium II
Pentium III
Pentium 4
Itanium
Itanium 2
Itanium 2 (9 Mo)
Itanium 2 (12 Mo)
FIG. 1.1 : volution du nombre des transistors
par produit Intel
Il a publi ensuite un article
Moo65
o il expliquait
que les conditions pour lvolution du secteur taient
favorables et a prvu, lhorizon des 10 annes sui-
vantes, une croissance exponentielle par un facteur 2
chaque anne.
La formule prsente par Moore exprimait une ap-
proximation des donnes mesures et essayait de les ex-
trapoler dans le temps. Les annes suivantes ont vri
que Moore avait eu raison en ce qui concerne la crois-
sance exponentielle du nombre de composantes par cir-
cuit mais ont galement corrig le facteur 2 prvu par
Moore pour chaque anne un facteur 2 pour tous les
18 24 mois. Cette formule est devenue clbre, elle
sest inscrite dans lhistoire de linformatique dune fa-
on informelle comme la Loi de Moore et elle avait,
comme elle la toujours, un grand succs non seulement
parmi le public populaire mais galement dans le cercle
scientique, citons comme preuve la rdition de lar-
ticle original de Moore en 1998
Moo98
par lorganisation
IEEE. Pour aller plus loin dans cette philosophie, divers
auteurs dclinent cette loi sur dautres types de donnes
connexes aux processeurs. Il est courant dutiliser les diagrammes de lvolution de divers paramtres
dpendant du temps. On parle ainsi de vecteurs de Moore
Gro02
et on les utilise pour dmontrer les aspects
plus dtaills de la production des processeurs tels que la lithographie, la consommation dnergie, les
performances, les chiffres daffaires.
Si nous regardons de prs g. 1.1
2
, nous pourrons observer, depuis lanne 2000, un changement
1
Gordon Moore devint en 1968 un des cofondateurs de lIntel Corporation
2
Donnes collectes partir des publications
NSG05a, NSG05b, Boh04
et des documents de communication dIntel
19
non ngligeable de la tendance de la courbe qui correspondrait prsent (anne 2005) un facteur de
croissance gal 2 pour chaque anne. Notre argumentation sappuie ici sur un chantillon de 34 annes
de production dun grand reprsentant du march des processeurs grand public, un reprsentant qui est
aussi trs actif et trs avanc
Boh04
dans linnovation des technologies pour la fabrication des puces en
silicium.
Anne Processeur
Nombre
de transistors
1971 4004 2 300
1972 8008 2 500
1974 8080 4 500
1978 8086 29 000
1982 286 134 000
1985 386 275 000
1989 486 1 200 000
1993 Pentium 3 100 000
1997 Pentium II 7 500 000
1999 Pentium III 9 500 000
2000 Pentium 4 42 000 000
2001 Itanium 25 000 000
2003 Itanium 2 220 000 000
2004 Itanium 2
(9 Mo L3 cache) 592 000 000
2005 Itanium 2
(12 Mo L3 cache) 1 720 000 000
TAB. 1.1 : volution de nombre des
transistors par produit Intel
Ce nouveau dynamisme des possibilits de fabrication pour-
rait nous inciter rchir la direction que prendront les archi-
tectures grand public dans les annes venir. L o lutilisation
dune technologie de gravure de plus en plus prcise
Boh04, Int06a
130 nm en production en 2001, 90 nm en production en 2003,
65 nm en production en 2005, 45 nm planie pour la pro-
duction en 2007, 32 nm plani en 2009
GS03
est en train
datteindre les dimensions de quelques couches datomes, on
commence parler de nanotechnologies et rechercher des so-
lutions pour la gravure 13 nm
Boh02
et l o il est possible
dimplmenter
NSG05a
1 milliard et 720 millions de transistors
sur une seule puce, cf. tab. 1.1, la paralllisation lintrieur
des puces prend sa relve. Si on donne lexemple des proces-
seurs grand public, nous pourrons mentionner les technologies
dj prsentes comme les architectures superscalaires ou les
units de traitement vectoriel, comme les architectures multi-
thread avec un seul cur ou les architectures multithread avec
plusieurs curs. La dernire qui est galement la plus jeune la
paralllisation par la multiplication du nombre des curs lin-
trieur dun processeur sur une seule puce est prsente par Intel comme son produit pilote, nomme
Platform 2015
Int05
, est adopte en tant que stratgie dvolution pour les dix prochaines annes.
1.2 Processeurs usage gnral les GPP et les GPPMM
Sous le terme de processeurs usage gnral nous comprenons les processeurs les plus universels
possible qui sont capables dexcuter plusieurs types de calcul diffrents. Luniversalit de ces proces-
seurs est gagne au prjudice de la spcialisation et par consquent de la performance, mme si celle-ci
doit rester raisonnable vis--vis de lutilit applicative de ces processeurs. Pour se rfrer un tel pro-
cesseur par la suite, nous allons utiliser labrviation GPP, drive dun terme anglais General Purpose
Processor.
Nous nous intresserons aux processeurs de ce type, plus prcisment une catgorie de ces pro-
cesseurs destine principalement lusage des particuliers. Cest une catgorie trs puissante en ce qui
concerne le nombre dunits vendues mais aussi une catgorie prsentant certaines particularits. No-
tamment il sagit de contraintes sur
le prix qui doit tre, pour des raisons conomiques, plutt en bas dchelle,
les dimensions qui ne doivent pas tre excessives ou qui doivent tre mme les plus petites possible
dans le cas o nous visons les produits portables,
la consommation dnergie qui est une contrainte impose pour des raisons soit pratiques (besoin
dun systme de refroidissement particulier ou non ?), soit nancires (cot dlectricit) soit de
dure dautonomie de lalimentation (produits portables).
Nous trouvons ces processeurs commercialiss sur le march de grand public au cur des ordinateurs
professionnels, personnels ou portables, incorpors dans les produits nomadiques. Cependant, nous pou-
vons les trouver aussi bien loigns du grand public dans les solutions non destines lusage personnel
tels que les serveurs informatiques ou galement les processeurs embarqus et dans des applications
varies, industrielles, civiles ou militaires.
20
Jaromr BRAMBOR 1.3. PROCESSEURS GRAPHIQUES LES GPU
Fabricant
Fonctionnalits ou
extensions multimdia
Intel IA-32 MMX, SSE, SSE2, SSE3
Intel IA-64 inclus
Intel PCA (PXA27x) Wireless MMX
AMD 3DNow!, 3DNow!2
AMD64 inclus
Sun VIS
MOTOROLA AltiVec
SuperH SHmedia
Transmeta Efceon
MMX, SSE, SSE2, SSE3
(VLIW)
TAB. 1.2 : Architectures multimdia
Ce type de processeurs essaie de couvrir le plus grand
nombre de clients potentiels et pour sy adapter, leurs ar-
chitectures ont bien volu au cours des annes. Elles nous
proposent, dans leurs versions actuelles, les fonctionnali-
ts dites multimdia
1
pour le traitement de donnes, ce qui
veut dire quune partie de larchitecture est ddie au trai-
tement de donnes rgulires dun grand volume
2
, telles
que le son, les images, la vido. Nous parlons ainsi des
processeurs usage gnral avec les extensions multim-
dia, GPPMM (une abrviation drive dun terme anglais
General Purpose Processor with MultiMedia extensions).
Le tableau 1.2 prsente une liste non exhaustive des appel-
lations des architectures ou des extensions multimdia selon divers fabricants de processeurs.
Ce sont les capacits multimdia qui vont nous intresser dans cette thse chez les GPPMM car
en les utilisant, nous pouvons bncier trs facilement et sur la plupart des architectures existantes
grand public dune rduction prvisible du temps de calcul et par dualit dune augmentation du dbit
de traitement de donnes. De plus, les instructions multimdia pour le traitement par la morphologie
mathmatique sont semblables et nous pouvons ainsi obtenir une portabilit plus ou moins aisment.
Cela est valable mme pour des processeurs trs diffrents, comme cest le cas pour les processeurs
puissants
LFB01
dun ct et pour les processeurs basse consommation
Bra02
de lautre.
1.3 Processeurs graphiques les GPU
Une place trs particulire parmi les architectures des processeurs est dtenue par les processeurs
graphiques, les GPU (driv dun terme anglais Graphic Processing Unit). Il sagit des processeurs qui
taient initialement utiliss lacclration de la visualisation des scnes 3D, trs exigeante en ce qui
concerne le nombre doprations effectues et la spcicit du calcul.
Le calcul sur les GPU se distingue dabord par lutilisation dun ensemble limit mais bien choisi
dun certain nombre de fonctions mathmatiques (sin, cos, puissance, la racine carre, produit scalaire,
etc.), ensuite par le procd de calcul qui utilise naturellement les types vectoriels (de 3 ou 4 compo-
santes) et nalement par lutilisation courante des oprations en virgule ottante. Tout cela est encore
major par la contrainte du temps dans le cas de la visualisation 3D interactive et/ou en temps rel. Ce
calcul spcique, runi avec la masse dinformations traites lors de ce calcul, tait (et est toujours) in-
adapt aux architectures du calcul gnral, mme si ces dernires auraient pu leffectuer en dpit de la
rapidit.
Puisque ni les GPP, ni leurs successeurs GPPMM, ne pouvaient satisfaire la demande importante
pour la visualisation devenue de plus en plus exigeante, une nouvelle catgorie de processeurs ddis a
vu le jour, la catgorie des processeurs graphiques destins lacclration du calcul pour la visualisation
3D. Ces processeurs taient et sont toujours des acclrateurs, cest--dire des processeurs secondaires
ddis, qui restent fortement lis aux processeurs principaux (GPP).
En effet, la cohabitation GPP-GPU a donn ce que lon en avait espr. On a spar la problmatique
de la visualisation deux parties : la partie de haut niveau est reprsente par le GPP et on lutilise pour
lexcution de lapplication de la visualisation. La deuxime partie de niveau bas est reprsente par ces
acclrateurs ddis et spcialiss qui soccupent du calcul intensif. Toutes les architectures actuelles des
ordinateurs personnels utilisent les acclrateurs graphiques ou, au moins, des sous-systmes graphiques
si on ne peut pas les classer dans la catgorie des acclrateurs au vrai sens du mot.
1
La dnition universelle et pertinente du mot multimdia est difcile trouver, nous pouvons le dnir comme runissant
plusieurs et diffrents types de mdias, dans ce contexte des mdias lectroniques
2
Remarquons que la locution grand volume est vague et contextuelle, elle signie ici les units, dizaines ou au maximum
les centaines de Mo
21
1
10
100
1000
1997 1998 1999 2000 2001 2002 2003 2004 2005 2006
x
1
0
6
Lanne dintroduction
FIG. 1.2 : volution de nombre de transistors
des processeurs graphiques NVidia
Depuis leur naissance, les processeurs graphiques
ont volu et voluent toujours trs rapidement. Tout
en protant des innovations technologiques durant la
dernire dcennie, ils se sont dvelopps partir dune
structure du pipeline xe capable dexcuter seulement
un ensemble trs limit de fonctions jusqu un pipeline
avec des blocs parallliss et dots de la possibilit de
reconguration complexe. Cette facult de recongu-
ration de plusieurs de leurs composantes lors de lex-
cution leur a permis de devenir une architecture trs
intressante non seulement pour la visualisation 3D
laquelle ils taient originalement destins, mais gale-
ment pour une utilisation plus large et moins lie la
visualisation qui inclut prsent aussi le calcul scienti-
que
GPG
.
Pour tablir un parallle avec la Loi de Moore et les
GPP, q.v. g. 1.1, nous prsentons ici et de la mme manire lvolution des performances des proces-
seurs graphiques, q.v. g. 1.2
1
. En consultant cette gure, nous essayons de saisir la tendance de lvo-
lution du nombre des transistors par GPU dans le temps et nous nous apercevons rapidement que nous
pouvons proposer deux interprtations diffrentes de ce graphique : une premire et encourageante qui,
en prenant en compte toute la priode observe de sept ans, estime lvolution comme exponentielle.
Mais nous pouvons proposer galement une deuxime interprtation qui, en se basant sur les quatre
dernires annes, ne devrait pas manquer de mentionner une lgre baisse de la croissance et devrait
nous inciter tre prudent dans nos conclusions de prvision exponentielle. En mme temps, le dernier
chantillon, correspondant Juin 2005, dsigne le chip NVidia G70 (GeForce 7800 GTX) fabriqu par
TSMC
TP05
en utilisant la lithographie 110 nm
NVi06
. On nest pas donc dans le mme esprit que pour la
g. 1.1 qui prsentait la technologie Intel, plus avance prsent, et nous pouvons donc esprer encore
un important progrs venir en ce qui concerne lvolution des GPU.
Nous remarquons quen compltant les GPP dans le domaine dans lequel ils ntaient pas trs adap-
ts, les GPU ont pu explorer la voie de la forte paralllisation sur une seule puce. Leur prix de fabrication
les a rendus trs comptitifs par rapport aux autres solutions du calcul parallle, notamment par rapport
la paralllisation via la multiplication du nombre de processeurs. La forte spcialisation a galement son
revers. tant ddis un calcul spcique, les GPU prsentent de nombreuses particularits qui peuvent
les rendre trs utiles pour une tche ou un type de calcul mais qui peuvent aussi les rendre compltement
inadaptes pour dautres. Nous allons discuter de ce sujet dans la partie Algorithmes et les skeletons
algorithmiques.
Dans les applications pratiques, cest surtout la performance qui nous intresse. Si on voulait effec-
tuer une prvision dvolution des performances des architectures de la mme faon que la fait Moore
avec lvolution du nombre des transistors sur une puce, nous trouverions que la transposition de cette
ide sur la performance nest pas triviale. La performance dun systme dpend non seulement du pro-
cesseur principal mais galement de toutes ses composantes qui doivent tre bien quilibres car cest
tout lensemble qui forme un seul produit dont la performance nous intresse.
Mme si les auteurs utilisent les courbes dvolution des GFLOPS
OLG
+
05, Owe04
ou mme dautres
paramtres de performance pour comparer les CPU avec les GPU an de soutenir la supriorit des
GPU pour le calcul, nous devons souligner quil est trs difcile de comparer la performance de deux
architectures trs diffrentes qui, en plus, ont t conues chacune pour un calcul distinct. Nous nallons
pas faire une telle comparaison et nous allons prsenter lvolution des paramtres de performances des
GPU indpendamment des GPP.
1
Les chiffres correspondent aux processeurs de NVidia Corporation et ont t collects partir des sources indirectes
depuis linternet
22
Jaromr BRAMBOR 1.4. AU-DEL DE LHORIZON
1
10
100
1000
10000
100000
1997 1998 1999 2000 2001 2002 2003 2004 2005 2006
x
1
0
6
Lanne dintroduction
Vertices/s
Texels/s
Fragments/s
FIG. 1.3 : volution des performances des pro-
cesseurs graphiques NVidia
La gure 1.3
1
prsente lvolution des trois pa-
ramtres principaux dun GPU les capacits maxi-
males de traitement en nombre de vertex
2
par se-
conde, en nombre de texels
3
par seconde et en
nombre de fragments
4
par seconde. Diffrents gra-
phiques de ce type sont prsents par diffrents au-
teurs
Owe04, Lue04, Mah05, Sei04
. Nous constatons que les
courbes correspondant aux fragments et texels sont
dune forte croissance et suivent, au moins pour les
quatre dernires annes, une fonction exponentielle.
Lexception est la courbe des vertex. Elle est galement
dune forte croissance mais, pour les annes 2003
2005, elle ne suis pas la mme progression. Ceci est
normal car les units de traitement des vertex nont
pas besoin du mme degr de paralllisation que les
texels et les fragments. Les units de traitement des ver-
tex sont conues pour un nombre relativement petit de
donnes en comparaison avec le nombre beaucoup plus
important des fragments traits dans les units parall-
lises plus massivement. Le traitement des texels est effectu principalement dans les units de traitement
des fragments, cest pourquoi les chiffres pour les texels concident avec ceux des fragments.
Ce que nous voulions dmonter ctait le fait que pour les GPU ce nest pas seulement le nombre
des transistors qui prsente une croissance exponentielle mais que ce sont galement les paramtres de
performance. Ces croissances sont trs encourageantes, elles suivent la logique de la Loi de Moore et
nous laissent penser la forte volution des GPU qui nous attend encore dans les prochaines annes.
1.4 Au-del de lhorizon
Nous avons utilis la leon de lhistoire concernant la Loi de Moore pour bien souligner le dyna-
misme exponentiel dvolution des performances des puces lectroniques durant les 40 dernires annes.
Ce dynamisme na pas cess depuis, au contraire, et nous pouvons dj entrevoir les grands changements
qui nous attendent dans les annes venir. Il est quasiment inutile de remarquer que ce que nous pouvons
fabriquer aujourdhui est loin de ce que pouvaient esprer les membres
5
de lquipe de Bell Labs quand
ils ont dcouvert leffet de transistor en 1947. La question que nous pouvons nous poser est si dans 40
ans nos successeurs, eux aussi, considreront notre poque de la mme manire que nous regardons au-
jourdhui lpoque de Moore. Nous pouvons nous demander si lide exprime par Moore en 1965 pour
le nombre des transistors par une seule puce lectronique peut encore rsister aux innovations technolo-
giques et aux nouvelles tendances dans le design darchitectures. Moore lui-mme la critiquait avec le
rsultat plutt optimiste en 2003 dans son article
Moo03a, Moo03b
intitul No exponential is forever : But
"Forever" Can Be Delayed !
En effet, lavenir proche est assez prvisible
FH05
. Comme
6
lindique International Technology Road-
1
Les chiffres ont t collects partir des documents de communication de NVidia Corporation
2
Dans le contexte des GPU, un vertex contient des coordonnes dun sommet dune forme gomtrique et ventuellement
dautres informations (couleurs, position dans la texture, etc.)
3
Abrviation du terme anglais texture element, texel, contient des informations dun lment de texture
4
Dans le contexte des GPU, un fragment contient des coordonnes 2D de la position sur lcran, la coordonne z et
linformation sur la(les) couleur(s)
5
John Bardeen, Walter Brattain et William Shockley ont dcouvert leffet de transistor en dcembre 1947
Lab97
et ils ont
obtenu le Prix Nobel de physique en 1956. Il est intressant de sapercevoir que le brevet
Sho51
issu de cette dcouverte na
t dpos quau nom de William Shockley.
6
Selon la thse de Robert Strzodka
Str04
, pages 103104
23
map for Semiconductors
ITR
, le dynamisme de la croissance exponentielle pourrait ralentir dans les an-
nes venir et tre gal 3 annes pour le doublement du nombre des transistors. Il devrait persister sous
cette forme pendant au moins 10 annes. Autour de 2020, quand on atteindra les contraintes physiques
de fonctionnement de la technologie base sur les charges lectriques, dautres approches qui ne seraient
pas limites par ces contraintes pourraient rallonger la dure de la Loi de Moore.
En mme temps, les approches parallles commencent se prsenter comme un phnomne quo-
tidien. Les processeurs existants avec plusieurs curs destins aux applications parallles et dautres
solutions varies qui suivent cette philosophie et sont tudies par les chercheurs
1
en sont la preuve.
Il est fort probable que dans un avenir trs proche nous allons nous retrouver couramment aux prises
avec les solutions du grand public composes de plusieurs processeurs physiques, eux-mmes dj dots
dune structure parallle lintrieur.
En ce qui concerne les GPU, nous pouvons constater quils se sont transforms en processeurs pro-
grammables, trs adapts certains types du calcul et quils commencent tre srieusement utiliss
mme pour les tches qui ne leur taient pas destines lorigine. Les chances pour une future utilisation
plus massive des GPU dans lavenir semblent trs bonnes. Ce qui parle dans leur intrt cest la faon
implicitement parallle de programmation et dexcution, propres ces processeurs. Leur architecture
est adapte ce travail et peut tre facilement largie au niveau de la puce sans contredire la philosophie
de la structure.
Ce qui semble pour linstant le vrai frein de lutilisation vulgaire des GPU pour le calcul gnral
est la manire dont ils sont incorpors ct des GPP dans larchitecture PC. Remarquons surtout la
mmoire distincte des GPU qui ncessite le transfert des donnes dans les deux directions et galement
la lenteur du pilote en temps de rponse un grand nombre de petits blocs de commandes. Esprons
que ces obstacles majeurs vont bientt disparatre, que le calcul gnral sur les GPU pourra bientt
atteindre sa maturit et devenir courant dans son utilisation. Les premiers pionniers montrer le chemin
pourraient tre les consoles de jeux. En se diffrenciant de la plateforme PC des ordinateurs grand public,
elles combinent dans une architecture ddie une grande puissance du calcul gnral avec une grande
puissance du calcul spcialis sur les ux de donnes. Pour ces consoles, nous pouvons nous attendre
galement une forte volution dans les prochaines annes.
ce jour, nous regardons vers lavenir et nous imaginons et crons les solutions pour le futur. Soit
court terme et exploitables ds prsent ou trs prochainement, soit long terme, plus conceptuelles
et exploitables dans quelques annes. Prvoir avec exactitude ce qui se passera long terme est trs
difcile. En revanche, nous pouvons ds aujourdhui cibler les ides prometteuses et les concepts qui ont
du potentiel. Nous croyons que les architectures que nous visons dans cette thse et les algorithmes que
nous y dcrivons en font partie.
1
Eva Dejnozkova a tudi cette approche dans sa thse
Dej04
en se focalisant sur les processeurs faible consommation
24
CHAPITRE 2
tat de lart
Cette thse est consacre aux algorithmes de la morphologie mathmatique qui peroivent et traitent
les donnes comme ux. Nous parlons ainsi du paradigme ux ou galement du paradigme stream.
Prcisons que le terme franais ux et le terme technique dorigine anglaise stream, largement utilis dans
le domaine informatique, dsignent le mme sujet. Bien que nous utiliserons les deux dans les locutions
dsignant le traitement ou le paradigme, pour une distinction plus pointue nous prfrons employer le
terme stream comme type de donnes et le terme ux dans lappellation dune mthode de traitement.
Ce sujet est dun intrt majeur pour les ralisations des applications pratiques et plus particulire-
ment pour les applications en temps rel o les architectures du calcul sont souvent ddies et prsentent
les caractristiques de traitement en ux. En mme temps, ce sujet nest pas, selon nous, sufsamment
dcrit dans sa globalit. Mme si certains articles publis dans les journaux scientiques traitent de sujets
connexes cette problmatique et quelques thses ont t galement ddies la conception des archi-
tectures particulires pour la morphologie mathmatique, nous navons pas connaissance dun travail qui
serait intgralement consacr aux techniques algorithmiques du domaine de la morphologie mathma-
tique, ddies aux architectures possdant des capacits spciales pour le traitement en ux, y compris les
techniques utilisant le pipeline graphique et les processeurs graphiques pour les ns de la morphologie
mathmatique.
Lambition de chaque scientique est, bien sr, de pouvoir dcouvrir un domaine ou une partie dun
domaine qui serait compltement inexplor. Acqurir les expriences dans un tel domaine, en approfon-
dir les connaissances et montrer par la suite le chemin ses successeurs, cest la vocation de chacun
deux. Pourtant, il est trs rare de nos jours que nous puissions explorer une problmatique hic sunt
leones
1
, une problmatique qui serait totalement inexplore et dont nulle partie ne serait encore di-
vulgue par dautres chercheurs. Cest peut-tre le phnomne de notre poque o nous travaillons
lchelle plantaire et dans une atmosphre trs comptitive o il est tout--fait possible que certaines
quipes scientiques travaillent sur les mmes problmatiques paralllement car les demandes pour leurs
tudes proviennent de diffrentes sources et sont assures par un nancement distinct. Ce qui nous arrive
le plus souvent dans un tel environnement, cest que nous explorons les problmatiques intressantes et
peu connues, mais dj prospectes par un tiers, les problmatiques qui ne sont pas compltement vides
mais dans lesquelles nous constatons un manque effectif dune expertise labore pralablement.
Il faut remarquer que divers articles et travaux scientiques dcrivant lutilisation des architectures
SIMD pour le traitement dimages et le traitement par la morphologie mathmatique sont prsents et
assez nombreux. En revanche, les travaux de ce domaine pour les processeurs graphiques sont quasi
inexistants car il sagit dune problmatique nouvelle qui na pas pu encore dtre tudie en profondeur
1
Linscription latine hic sunt leones, signiant en franais ici sont les lions, tait utilise sur anciennes cartes pour dsigner
un espace inconnu
25
ni tre utilise une large chelle. De plus, nous avons remarqu le manque de rigueur dans la description
formelle de tels algorithmes. Le degr de formalisation varie dun article lautre et ce fait est le plus
agrant dans les descriptions des algorithmes pour les processeurs graphiques o lon se contente, de
temps autre, seulement dune image dillustration ou dune description vague de fonctionnement. Dans
ces situations, nous serions contents de pouvoir nous adresser une approche formelle, simple, unie
et surtout dj existante pour la description des algorithmes pratiques de traitement dimages et cela non
uniquement en morphologie mathmatique.
Cest ainsi que nous percevions ltat de lart au moment de notre intervention et do est ne notre
motivation de chercher clarier une partie de la morphologie mathmatique concernant le traitement
sur les architectures dites orientes ux. Au dbut, nos cibles prioritaires taient les architectures grand
public basse consommation avec les fonctionnalits multimdia qui sont de plus en plus utilises dans
les applications embarques de traitement des images. Mais nous ne voulions pas nous restreindre seule-
ment aux architectures basse consommation car le principe de travail avec ces dernires est le mme
que pour les architectures classiques grand public qui sont dsignes par le terme anglais main stream.
En mme temps, le style de travail en ux de donnes est bien marquant dans le fonctionnement des
processeurs graphiques et nous voulions dmontrer galement la piste de leur possible utilisation pour
les applications de la morphologie mathmatique.
Toutes ces architectures utilisent le paradigme stream comme le modle de traitement. Cest la raison
pourquoi nous voulions dcrire les algorithmes de la morphologie mathmatique qui seraient construits
en utilisant lapproche des ux de donnes pour le traitement. Les algorithmes qui seraient en mme
temps assez gnraux dans leur forme et qui pourraient ainsi rester abstraits dune architecture parti-
culire. Cette gnralisation est, en effet, lorigine de notre titre qui emploie explicitement le terme
architectures orientes ux pour dsigner un groupe darchitectures dont le point commun est le traite-
ment en ux.
Nous voudrions prsenter, dans la suite de ce petit chapitre, les sources qui nous ont inspir et dont
le travail nous a servi comme le point de dpart pour nos propres tudes.
Skeletons algorithmiques et formalisme fonctionnel
En mathmatique, il existe plusieurs manires de dcrire un algorithme. Nous voudrions en choisir
une qui permettrait de dcrire dune faon simple le travail avec les ux et qui serait la fois abs-
traite, pour que les procds que nous dcrivons pour les architectures spcialises soient exprims le
plus gnralement possible, et qui aurait la fois la possibilit de vrier la bonne formulation de nos
prescriptions.
Cest pourquoi nous avons limin tout au dbut lventualit dutiliser le pseudocode
Wik05c
et nous
nous sommes inclins vers les mthodes utilises pour la description et pour la programmation des pro-
cds destins aux architectures parallles. Lors de nos recherches bibliographiques, nous nous sommes
vivement intresss aux approches des skeletons algorithmiques exprims en formalisme fonctionnel.
Ces travaux sont souvent originaires du Royaume Uni, largement reprsents par des articles
1
, des rap-
ports techniques
DGG
+
96, Dar98
ou des prsentations
DNG00
de Darlington et al. de Departement of Com-
puting dImperial College Londres mais aussi des thses doctorales
To95, Yan97, Gha99
issues du mme
tablissement. Un autre groupe scientique qui travaille sur cette problmatique est celui de lUniversit
de Pisa en Italie et dont nous citons un article antcdent
DMO
+
92
aux travaux de Darlington et al., une
thse doctorale
Pel93
et les travaux rcents
AD03
issus du mme centre de recherche. Il existe, en effet, des
travaux encore plus anciens traitant le mme sujet
Col89
mais galement les travaux relativement rcents
et dorigine franaise qui traitent les aspects pratiques de la programmation pour les architectures paral-
lles
Cou02
. Les travaux touchant lemploi du formalisme fonctionnel pour les architectures SIMD
Jou91
peuvent galement tre retrouvs.
1
Articles de Darlington et al.
DFH
+
93, DT95, DkGT95, DGTY95b, DGTY95a, DkGTY96, ADGkG96, DGGT97
26
Jaromr BRAMBOR
Les techniques utilises pour driver les programmes partir des spcications formelles par skele-
tons algorithmiques sont galement prsentes. Il sagit des techniques connexes au formalisme de Bird
et de Meertens qui ont propos une algbre pour la programmation et on parle de Bird-Meertens For-
malism
Gib94
appel galement Squiggol ou Squigol. Cette algbre, utilise pour la programmation, peut
tre perue comme un langage fonctionnel. D. B. Skillicorn
1
a voqu
Ski92
lutilisation possible de ce
formalisme en tant que modle parallle pour la programmation.
Un article qui compare diffrentes approches la programmation parallle par skeletons algorith-
miques et qui essaie de les classier est prsent par Campbell
Cam96
. Tous ces travaux prsentent des
mthodologies qui nous paraissent propices nos besoins. Il sagit, en effet, des mthodologies com-
plexes et il faut noter que nous nen avons repris quune partie, mais une partie sufsante nos explica-
tions pour le calcul en stream et les manires de sa paralllisation.
Morphologie mathmatique applique
Cest lutilisation pratique de la morphologie mathmatique qui est vise par les approches que nous
dcrivons dans cette thse. Lors de lutilisation des algorithmes de traitement dimages par la morpholo-
gie sur les architectures grand public, nous nous sommes aperus que les implmentations des mthodes
de base que lon utilisait pour la construction des algorithmes complexes de traitement dimages se
consacraient prioritairement la modularit des oprateurs et taient principalement destines un tra-
vail scientique en phase dtudes de faisabilit plutt qu la phase applicative des projets industriels
de traitement dimages en temps rel.
Cest, en effet, ce type de projets industriels qui pose, parmi dautres, une contrainte sur la dure
maximale dexcution dun tel traitement. Une telle contrainte nest pas prsente dans la plupart des
travaux de recherche effectus pendant la phase de construction des prototypes des algorithmes de traite-
ment dimages. Ces travaux de recherche non applique peuvent, en effet, aboutir des temps du calcul
beaucoup plus levs, excluant mme les algorithmes rsultant du fonctionnement en temps rel.
Pourtant, les applications industrielles de traitements dimages pour le temps rel qui utilisent les
mthodes de la morphologie mathmatique et font appel aux ordinateurs grand public, soit classiques,
soit basse consommation, deviennent de plus en plus frquentes. Ceci surtout grce laugmentation
de leurs performances durant les dernires annes, ce qui leur a permis de devenir comptitifs par rapport
aux architectures particulires et entirement ddies utilises le plus souvent dans les applications de la
la morphologie mathmatique pour le temps rel.
De ce point de vue, cest la thse doctorale de Cristina Gomila
Gom01
qui nous a inspir car elle
prsente un algorithme intressant qui combine le ltrage morphologique de bas niveau avec la segmen-
tation dimages et le suivi des objets dans le traitement des donnes vido. Dans la partie pratique de
sa thse, Gomila vise lutilisation de cet algorithme dans les applications de tlphonie mobile sur le
matriel embarqu grand public.
En effet, ce sont les applications de ce type que nous visons pour les algorithmes spciques dcrits
dans cette thse comme des applications potentielles de la morphologie mathmatique destines aux
architectures multimdia grand public.
Architectures ddies et algorithmes relatifs
Vu la nature fortement parallle et itrative des mthodes morphologiques de traitement dimages,
il nest pas surprenant que ces dernires constituent un centre dintrt privilgi des constructeurs des
architectures particulires de traitement dimages et des concepteurs des algorithmes pour les architec-
tures parallles. Cet intrt est prsent depuis lapparition de ces mthodes et depuis leurs utilisations en
pratique pour les applications o le temps de traitement est un facteur limitant majeur.
1
Skillicorn est aussi lauteur dune taxonomie complexe pour la classication des architectures
Ski98
27
Cest pourquoi les chercheurs daujourdhui ont dj disposition un certain nombre de travaux qui
dcrivent diffrentes ralisations du matriel informatique spcialis en traitement de la morphologie ma-
thmatique et un certain nombre de travaux portant sur les aspects algorithmiques de traitement dimages
destin aux architectures parallles.
Parmi les travaux qui sont consacrs aux algorithmes parallles pour la morphologie mathmatique,
nous mentionnons les articles
MR96, RM00
et la thse doctorale
Mei04
dArnold Meijster. Nous pouvons ci-
ter galement les travaux dAndreas Bieniek et al.
LBB98, BM98, BBM
+
96
qui exploitent diverses possibilits
de construction des algorithmes de segmentation des images pour les architectures parallles. Les al-
gorithmes de la transformation distance et leur utilisation pratique pour les applications mdicales sont
dcrits dans la thse doctorale
Cui99
dOlivier Cuisenaire.
Les architectures ddies certaines mthodes de traitement de la morphologie mathmatique et les
algorithmes conus spciquement pour ces architectures sont reprsents par les implmentations des
automates cellulaires lchelle des pixels. Le traitement en ux de donnes est reprsent le plus sou-
vent par diverses architectures optimises pour les applications de la morphologie travaillant avec des
signaux vido. Ce sont les lignes en retard suivant le sens de balayage vido qui sont utilises comme
paradigme pour lexploitation de la localit et le paralllisme de donnes lors du travail avec le voisi-
nage proche. Citons les travaux traitant ce sujet un article
Nog97
de Dominique Noguet et sa thse
Nog98
doctorale mais galement la thse de Fabrice Lemonnier
Lem96
et la thse de Raphal Sasportas
Sas02
, ces
deux dernires issues du Centre de Morphologie Mathmatique.
Une autre groupe darchitectures parallles est reprsent par les travaux
DD04, DD03
dEva Dejnoz-
kova et al. qui dcrit dans sa thse
Dej04
une architecture convenable pour les algorithmes traitant les
images par les quations partielles diffrentielles.
La construction de la partie dquipement logiciel pour une architecture ddie la morphologie
mathmatique peut trouver galement linspiration dans la thse doctorale
Bil92
de Michel Bilodeau qui
traite ce sujet.
Traitement dimages sur les processeurs graphiques
Les processeurs graphiques ont dj t utiliss pour les calculs des oprations de la morphologie
mathmatique. Larticle le plus ancien (anne 2000) que nous avons pu consulter qui est consacr
ce sujet est celui de Hopf et Ertl
HE00
et utilise la construction des oprations morphologiques par un
rendu conscutif des rectangles dcals afchant limage stocke en tant que texture et par leur fusion
conscutive dans le framebuffer utilisant les oprations max et min pour le blending.
Plus rcemment, en 2002, Yang et Welch ont publi un article
YW02
o ils dcrivent lutilisation du
hardware graphique grand public pour lextraction dun objet de la scne par diffrence avec limage de
fond. Ils utilisent par la suite le post-traitement par ouvertures morphologiques. Les oprations morpho-
logiques y sont implmentes laide des possibilits du multitexturing du processeur graphique quils
ont eu disposition ; ce qui distancie celle-ci de celle prsente par Hopf et Ertl mentionne ci-dessus.
Rcemment (2005), Dixit, Keriven et Paragios ont dcrit la technique pour la segmentation des
images base sur les graphes et le Maximum ux problem, et utilise lalgorithme push-relabel pour le
solutionner. Ils ont dvelopp une implmentation de cet algorithme destin aux processeurs graphiques.
Le calcul principal est effectu dans les units de traitement des fragments o leur algorithme bncie
implicitement dune paralllisation du calcul.
Le sujet ne traitant pas directement la morphologie mathmatique mais qui est crucial pour les ap-
plications de traitement dimages est celui de lutilisation des processeurs graphiques pour les algo-
rithmes bass sur les quations partielles diffrentielles. Ce sujet est bien expliqu dans les articles de
Strzodka
Str02
ou dans les articles que Strzodka a publi avec Rumpf
RS01
ou encore dans les articles o
ils sont cits tous les deux comme les coauteurs
DPRS01, SDR04, KEH
+
02
. La problmatique des quations
partielles diffrentielles utilises en traitement dimages est bien dcrite dans la thse doctorale de Keri-
ven
Ker97
ou de Strzodka
Str04
. Ce dernier a galement particip la publication dun article
ST04
traitant de
28
Jaromr BRAMBOR
limplmentation de la fonction distance gnralise et de la skeletonisation dans le hardware graphique.
Celle-ci tant base sur les pixels des contours dun objet, elle utilise le pavage par la dcomposition
hirarchique et est particulirement intressante pour les applications o un objet couvre une partie rela-
tivement grande de limage, e.g. pour dterminer les cartes de distance pour la navigation des robots.
Wikipedia
De temps autre, nous faisons appel dans nos explications Wikipedia
Wik06k
qui est un projet den-
cyclopdie libre et gratuite et dont les articles nous paraissent sufsamment explicites pour que nous
puissions les proposer au lecteur comme une source bibliographique rapide pour davantage dinforma-
tions ou de prcisions sur certains points. Notamment pour donner, dune faon claire, une dnition aux
termes qui sont largement employs mais dont le sens reste assez vague, citons comme exemple le terme
multimdia
Wik06h
.
29
CHAPITRE 3
Architectures
3.1 Taxonomie des architectures
Pour pouvoir comprendre dans quel domaine se placent les algorithmes dcrits dans les parties sui-
vantes, il nous faut spcier la classe des architectures du calcul appropries. Cest pourquoi nous allons
prsenter les taxonomies les systmes de classication des architectures parallles.
Les diffrenciations suivantes gardent une trs bonne gnralisation par rapport au fonctionnement
exact des machines parallles ce qui nous permettra dobtenir une protabilit entre diffrentes implmen-
tations sur des architectures prcises, soit existantes, soit des architectures concevoir, et largir ainsi le
champ dapplications possibles de nos algorithmes.
Il existe plusieurs systmes de classication des architectures existantes. Pour une liste exhaustive des
travaux portant sur la caractrisation des architectures, parallles ou squentielles, nous recommandons
un article comparatif
BD93
des diffrentes taxonomies.
3.1.1 Taxonomie de Flynn
Parmi les diverses faons de caractriser les architectures, celle de Flynn
Fly66
dtient une place privi-
lgie car elle est toujours perue comme une faon simple et presque intuitive de la description du mode
de fonctionnement dune machine. Elle caractrise les machines selon le type de ux dinstructions et de
ux de donnes.
En dpit de cette simplicit, cette taxonomie nest pas lune des plus discriminatoires et prsente
ainsi de grands dsavantages
CT93
, principalement dues labsence de caractrisation du systme de la
mmoire. Malgr les travaux
Dun90, Ski98
essayant de complter ce systme de caractrisation, la taxo-
nomie de Flynn reste toujours le premier outil de description dans un grand nombre de publications
scientiques. Nous la mentionnons pour pouvoir introduire et expliquer les termes qui seront utiliss par
la suite.
La Taxonomie de Flynn classe les architectures en ces 4 catgories :
architectures SISD et SISD conuant (Single Instruction (stream), Single Data (stream)) - ux
simple dinstructions et ux simple de donnes,
architectures SIMD (Single Instruction (stream), Multiple Data (stream)) - ux simple dinstruc-
tions et ux multiple de donnes,
architectures MISD (Multiple Instruction (stream), Single Data (stream)) - ux multiple dins-
tructions et ux simple de donnes,
architectures MIMD (Multiple Instruction (stream), Multiple Data) - ux multiple dinstructions
et ux multiple de donnes.
31
UC
P
1
P
n
P
2
MI
Flux dentre Flux drivs Flux de sortie
MD
(a) Excution en pipeline, type SISD
conuent
UC
P
1
P
3
P
n
P
2
Rseau dinterconnexions
M
1
M
2
M
3
M
n
(b) type SIMD
CT93
UC
1
UC
2
UC
n
P
1
P
n
P
2
MI
1
MI
2
MI
n
Flux dentre Flux drivs Flux de sortie
MD
(c) type MISD
UC
globale
UC
1
UC
2
UC
3
UC
n
P
1
P
3
P
n
P
2
Rseau dinterconnexions
M
1
M
2
M
3
M
n
(d) type MIMD
CT93
FIG. 3.1 : Les types darchitectures selon la taxonomie de Flynn. Lgende : UC - unit centrale, P - processeur,
M - mmoire, MI - mmoire dinstructions, MD - mmoire de donnes
3.1.1.1 Architecture SISD et SISD conuant
Dans ce type darchitectures, nous pouvons distinguer le mcanisme sriel de dcodage dinstructions
et, par consquent, le traitement dun seul ux dinstructions. Une seule donne peut tre traite dans le
laps de temps , driv du cycle dhorloge et li ainsi la frquence de larchitecture.
Le type darchitectures SISD a un fonctionnement squentiel et nest pas, en effet, explicitement
parallle. Mais il englobe galement le traitement SISD conuant et inclut ainsi les architectures avec un
pipeline dont la structure est illustre sur la g 3.1(a).
Un pipeline est utilis pour maximiser lusage des blocs dexcution en divisant une opration dune
granularit donne en une squence srielle des oprations de granularit plus ne. Le traitement est
toujours effectu avec un seul ux dinstructions sur un seul ux de donnes. Seule une donne peut tre
traite par une unit de traitement distincte dans lintervalle . Avec cette structure, lunit du calcul
parvient une augmentation de bande passante exprime par le nombre dinstructions par seconde. Nous
prsentons un exemple pratique dexcution en pipeline du processeur SH-5, q.v. g 3.2.
3.1.1.2 Architecture SIMD
Dans ce type darchitectures, cf. g 3.1(b), un seul ux dinstruction est utilis pour contrler le fonc-
tionnement de plusieurs units lmentaires du calcul. Ainsi, larchitecture est capable de traiter plusieurs
donnes la fois. Les donnes y arrivent comme un ux multiple, compos dun certain nombre dl-
ments de base. On classe dans cette catgorie galement les machines vectorielles, les rseaux cellulaires
et les rseaux systoliques.
32
Jaromr BRAMBOR 3.1. TAXONOMIE DES ARCHITECTURES
WB D F1 E1 E2 E3 F2
WB D F1 E1 E2 E3 F2
WB D F1 E1 E2 E3 F2
Temps
Instruction n+0
Instruction n+1
Instruction n+2
FIG. 3.2 : Excution dans le pipeline du processeur SH-5 se poursuit de gauche droite. Lgende : F1, F2
(fetch) - phases de la mise en pipeline dune instruction ; D - dcodage de linstruction ; E1, E2, E3 (execute)
- jusqu 3 phases dexcution, fonction exacte (mmoire, calcul en entiers, en virgule ottante) dpend de
linstruction, WB (writeback) - criture des rsultats dans le registre
Plus gnralement, nous pouvons parler dans le mme cadre dune architecture SPMD (Single Pro-
gram, Multiple Data) - architecture un programme et donnes multiples - qui a la mme conguration
mais les units lmentaires du calcul excutent dune faon synchrone une mme squence dinstruc-
tions ou un mme programme plus complexe. La faon synchrone dexcution est ici indispensable et
constitue le lien avec la catgorie SIMD travaillant de la mme faon au niveau dinstructions.
3.1.1.3 Architecture MISD
Dans ce type darchitectures, plusieurs instructions sont destines traiter la mme donne. Chaque
unit reoit une instruction spcique.
Ce type inclut galement le traitement en pipeline o la tche est divise en tapes distinctes et
o nous ne pouvons pas identier plusieurs units du calcul qui seraient indpendantes, une ddie
chaque tape. En contraste avec le pipeline class sous SISD conuent o les blocs du pipeline taient
commands tous par une mme unit centrale et o ils formaient un seul macro-bloc fonctionnel, le
pipeline du type MISD correspond un enchanement des macro-blocs, chacun ayant sa propre unit
centrale, cf. 3.1(c).
3.1.1.4 Architecture MIMD
La catgorie MIMD est implicitement perue comme asynchrone ce qui la diffrencie grandement
dautres catgories de la taxonomie de Flynn.
Les architectures de ce type sont composes de plusieurs units de calcul spares qui peuvent ex-
cuter diffrents ux dinstructions sur diffrents ux de donnes, indpendamment les unes des autres et
en utilisant leurs propres donnes locales, cf. 3.1(d).
Cette catgorie nexige explicitement aucune forme de synchronisation entre les units. Dans la pra-
tique, la synchronisation, si on en a besoin, est effectue par lintermdiaire dune mmoire partage ou
par le biais de passage des messages par un rseau dinterconnexions.
3.1.2 Taxonomie de Duncan
La taxonomie de Duncan
Dun90
est plus rcente (1990) que celle de Flynn (1966). Elle tait conue
principalement pour surpasser le manque de prcision de la taxonomie de Flynn et ainsi pouvoir distin-
guer certains types darchitectures trs proches dans leur fonctionnement.
La taxonomie de Duncan est base sur la taxonomie de Flynn et reprend sa terminologie en incorpo-
rant les classes SIMD et MIMD dans un systme plus discriminatoire et hirarchis. De plus, elle exclut
les classes qui, selon Duncan, ne dcrivent que les mcanismes parallles de bas niveau. Ces mcanismes
sont courants dans les structures des architectures contemporaines mais nous ne pouvons pas les classer
rigoureusement comme parallles car si tel tait le cas, la plupart des ordinateurs modernes appartien-
33
draient aux architectures parallles. Cette exclusion se prsente par la non incorporation des classes SISD
et MISD et par lexclusion explicite des architectures ayant un pipeline au niveau des instructions.
En revanche, elle inclut les architectures vers lesquelles se porte notre attention. Il sagit des archi-
tectures vectorielles, systoliques, des architectures array vague et des architectures ux de donnes.
La gure 3.3 prsente les catgories de cette taxonomie comme un arbre hirarchis.
Architectures
synchrones MIMD du paradigme MIMD
Vectorielles SIMD Systoliques avec la
mmoire
distribue
avec la
mmoire
partage
Array des
processeurs
Mmoire
associative
MIMD/SIMD flux de donnes rduction vague
FIG. 3.3 : La taxonomie de Duncan
3.1.2.1 Architectures vectorielles
Les architectures de ce type sont caractrises par plusieurs units du calcul qui peuvent tre chanes
et constituer ainsi un pipeline vectoriel. Leur grande diffrence par rapport aux architectures SIMD est le
fait quelles sont conues explicitement pour le calcul vectoriel et implmentent les fonctions spciques
de ce calcul. Pour dmontrer cette diffrence, nous pouvons citer lexemple des instructions oprant entre
les lments dun vecteur telles que la somme des lments et qui ne sont pas en cohrence avec le
modle SIMD qui utilise lapplication dune seule et mme instruction sur plusieurs units et en principe
indpendamment lune de lautre.
3.1.2.2 Architectures systoliques
Les architectures systoliques ont mrit galement une place distincte dans la catgorie des archi-
tectures synchrones. Elles se prsentent par un certain nombre dunits capables dexcuter dune faon
synchrone soit une instruction, soit, et le plus souvent, une squence ou un programme. La prsence
dun rseau dinterconnexions dont la topologie est prdnie par le type de calcul et la prsence du
phnomne de pulsation ou de pompage lors du transfert des donnes dune unit du calcul lautre sont
dautres caractristiques propres aux architectures systoliques.
Les architectures de ce type gagnent leur performance en liminant les goulots dtranglement issus
de laccs aux donnes dans la mmoire. Plutt qutre crits dans la mmoire principale, les rsultats du
calcul issus de chaque unit excutive sont stocks dans leurs registres internes et sont distribus, dans la
phase suivante du calcul, via le rseau dinterconnexion directement vers les units qui en auront besoin
pour la poursuite du calcul.
Cette catgorie est trs proche de la catgorie trs gnrale MISDde la taxonomie de Flynn, cf. 3.1.1.3,
page 33. Les architectures systoliques se spcient, en contraste de MISD, par leur insistance sur lexis-
tence dun rseau dinterconnexions complexes et sur la propagation des rsultats laide de ce dernier.
La structure systolique la plus souvent utilise dans le traitement dimages est celle dun array 2D
des processeurs avec les interconnexions bidirectionnelles qui retent la dnition du voisinage, cf.
g. 3.4(a). Nous pouvons en citer une ralisation intressante destine au traitement dimages qui intgre
34
Jaromr BRAMBOR 3.1. TAXONOMIE DES ARCHITECTURES
une architecture systolique directement sur la puce du capteur CMOS et dont les lments excutifs sont
dots des fonctionnalits SIMD
GCRW
+
99
.
Mais ce nest quune des possibilits, un autre exemple de la conguration systolique avec la topo-
logie adapte pour la multiplication des matrices 2x2
Dun90
est prsent sur la g. 3.4(b) et un exemple
trivial dune architecture systolique est un pipeline linaire travaillant dune faon synchrone et constitu
des blocs fonctionnels distincts, q.v. g. 3.4(c).
E E
E
Mmoire
E
E
E
(a) pour le traitement dimages,
grille carre, 4 voisins
E E
E E
Mmoire
(b) pour la multiplication des
matrices 2x2
E E E
Mmoire
(c) pour le traitement en pipeline
FIG. 3.4 : Exemples des congurations et de la topologie dinterconnexions des architectures systoliques. Le
rseau dinterconnexions est dcrit par les ches paisses, les entres et les sorties vers la mmoire sont dcrites
par les ches nes. Lgende : E - lment du calcul
3.1.2.3 Architectures array vague
Les architectures array qui nutilisent pas en mme temps tous les lments pour le calcul et nen
stimulent quun certain nombre sont nommes architectures vague. Comme ctait le cas pour les
architectures systoliques desquelles elles sont trs proches, les architectures vague sont composes dun
certain nombre de processeurs et dun rseau dinterconnexions. Mais elles diffrent de ces dernires par
la faon asynchrone de passage des donnes par le rseau dinterconnexions. La donne rsultante dun
lment du calcul est passe travers le rseau seulement si son successeur est prt pour travailler avec
cette donne et la demande. On distingue ainsi une communication entre les lments, ce qui ntait pas
le cas chez les architectures systoliques o seule la donne tait transfre travers le rseau.
La gure 3.5 illustre le fonctionnement dune architecture vague sur trois itrations. Diffrentes
units du calcul sont actives dans chacune des tapes, la forme prcise de cette activation dpend du
calcul effectuer.
E
1,1
E
2,1
E
1,2
E
2,2
E
1,3
E
2,3
E
1,4
E
2,4
E
3,1
E
4,1
E
3,2
E
4,2
E
3,3
E
4,3
E
3,4
E
4,4
(a) itration no. 1
E
1,1
E
2,1
E
1,2
E
2,2
E
1,3
E
2,3
E
1,4
E
2,4
E
3,1
E
4,1
E
3,2
E
4,2
E
3,3
E
4,3
E
3,4
E
4,4
(b) itration no. 2
E
1,1
E
2,1
E
1,2
E
2,2
E
1,3
E
2,3
E
1,4
E
2,4
E
3,1
E
4,1
E
3,2
E
4,2
E
3,3
E
4,3
E
3,4
E
4,4
(c) itration no. 3
FIG. 3.5 : Exemple de fonctionnement dune architecture vague. Lors des trois itrations dcrites, diffrents
lments (E) sont activs et effectuent le calcul. Lactivation est illustre par une bordure paisse.
35
3.1.2.4 Architectures ux de donnes
Les architectures ux de donnes sont bases sur la perception des donnes en tant que ux et
sur le passage des donnes dune unit du calcul lautre. La caractristique cruciale est la possibilit
du lancement immdiat dune instruction ou dun programme ds que leurs oprandes sont disponibles.
Il sagit des architectures asynchrones dont la topologie du rseau dinterconnexions est dicte par le
calcul effectuer. Les units excutives sont spcialises et ne soccupent pas du va-et-vient des donnes
pour le traitement car leur passage est dtermin lavance par le rseau dinterconnexions. La squence
dexcution est base sur les dpendances entre les units. Exploitant cette dpendance, ces architectures
peuvent implmenter tous les types du paralllisme, que ce soit au niveau des instructions, des routines
ou des tches.
Cration
du marqueur
Image dentre
Masque de la zone
dintrt dans
limage dentre
Image filtre
Sur-nivellement
Sous-nivellement
Combinaison
des nivellements
Application
du masque
FIG. 3.6 : Exemple dun graphe dexcution dun algorithme de ltrage morphologique qui utilise les nivelle-
ments. Les donnes transmises par le rseau dinterconnexions sont les images entires.
Nous prsentons un exemple
1
dun graphe dexcution de lalgorithme de ltrage morphologique des
images en utilisant les nivellements et le masque dintrt, q.v. g. 3.6. Ce graphe dcrit directement la
structure dune architecture ux de donnes qui pourrait tre envisage pour ce traitement. Dans ce cas
prcis, les blocs excutifs, reprsents par les ellipses, sont des routines qui implmentent les oprations
morphologiques et les donnes transmises le long des crtes du graphe sont les images entires.
3.2 Facteurs inuant la performance
Les algorithmes prsents plus loin dans cette thse dcrivent des procds spcialiss mais leurs
dnitions ont t gnralises tant que les modalits exactes de leur excution ou les dtails prcis
dimplmentation ne sont a priori pas donns. Pourtant, la ralisation de ces algorithmes peut faire appel
aux architectures qui ont des structures diffrentes et qui utilisent les fonctionnalits matrielles particu-
lires. Regardons maintenant quels sont les facteurs majeurs qui inuencent la performance nale dun
systme ou dune architecture informatique et qui sont relatifs limplmentation matrielle. Par la suite,
nous discutons en dtail des points suivants :
Structure de larchitecture dans 3.2.1,
Frquence de(s) lunit(s) de calcul dans 3.2.2,
Structure, capacit et frquence des mmoires dans 3.2.3,
Paralllisation des donnes dans 3.2.4,
Paralllisation dexcution dans 3.2.5,
cartement et latence des instructions dans 3.2.6,
Instructions spcialises dans 3.2.7,
Nombre de registres et leur dsignation dans 3.2.8,
Approche limplmentation des algorithmes dans 3.2.9,
1
Cristina Gomila
Gom01
utilisait les traitements de ce type dans sa thse
36
Jaromr BRAMBOR 3.2. FACTEURS INFLUANT LA PERFORMANCE
3.2.1 Structure de larchitecture
La structure de larchitecture est cruciale et prdestine la performance nale et les scnarios dutili-
sation dun processeur ou dun ordinateur issus de cette architecture.
La structure la mieux adapte pour notre cas serait celle qui implmenterait nos algorithmes directe-
ment au niveau du matriel. Cette approche est courante dans la recherche et dans lindustrie spcialise.
Cest une dmarche excellente pour la production et lutilisation en masse. En revanche, elle peut sav-
rer coteuse pour les petites sries de produits, surtout cause de la prsence dun long processus de
dveloppement et cause dun cot lev de fabrication dune srie limite. Les reprsentants apparents
de cette approche sont les puces informatiques ddies une n prcise, les ASIC ou les architectures
dveloppes utilisant les FPGA.
Si on abandonne lide dune architecture entirement ddie et si nous acceptons dimplmenter
nos algorithmes sur des structures plus gnralistes mais qui resteraient spciales dans leur fonction-
nement, on se retrouvera avec des architectures ddies pleinement un calcul sur les ux de donnes
comme Imagine
1
. Ce type darchitectures peut constituer un bon compromis entre la performance et le
cot de dveloppement dune application. Nous pouvons intgrer dans ce mme groupe les processeurs
graphiques programmables car malgr leur universalit marque par la capacit de leur conguration lors
dexcution, leur architecture reste toujours ddie.
De la faon la plus gnrique, nous parlons des architectures des processeurs gnraux, des GPP.
Pour notre travail avec les ux de donnes nous allons nous intresser plutt leurs variantes ayant
des capacits multimdia, GPPMM. Les avantages et les inconvnients sont intelligibles. Le prix est
faible mais puisque la structure nest pas ncessairement adapte au travail que nous voudrions effectuer,
la performance peut savrer inadapte ou insufsante.
Nous ne voudrions pas manquer de citer ici les exemples de structures trs particulires que sont les
consoles de jeux telles que Microsoft Xbox 360
Wik06l
ou Sony PlayStation 3
Wik06i
. Leurs structures sont
ddies un but prcis visualisation interactive avec la sortie dun ux vido. Elles combinent ainsi une
partie largement spcialise pour le travail sur les ux de donnes avec une partie gnrale qui assure le
fonctionnement du moteur de lapplication. Diverses applications sont possibles, e.g. un cluster du calcul
scientique a t construit
Cas03
partir des consoles Sony PlayStation 2.
3.2.2 Frquence de(s) lunit(s) de calcul
La frquence de lunit du calcul est un paramtre cardinal car directement li au dbit dexcution
des instructions. Il est vident que si on augmentait la frquence des units du calcul, nous devrions
nous attendre une augmentation directe de la performance car nous allions, en thorie, traiter plus
dinstructions par unit de temps. En pratique, il ne suft pas daugmenter uniquement la frquence
des units du calcul mais nous devons ajuster aussi la frquence de tous les systmes subordonns,
notamment de la mmoire.
Laugmentation de la performance travers augmentation de la frquence des units du calcul a
t longtemps pourchasse et il faut noter que le d de la conqute de la frquence grandissante est
toujours bien prsent. Un autre point souligner est le fait que la frquence est directement lie, avec
le voltage et la technologie de gravure, la consommation et la dissipation thermique. Cest une des
raisons pour lesquelles nous ne voyons pas prsent de processeurs faible consommation (moins de
10 W) et dont la frquence dpasserait 500 MHz
2
. Pourtant, la frquence ne devrait pas tre la limitation
principale car de nos jours on fabrique dune faon industrielle les puces 4 GHz. En revanche, ce
que nous pouvons observer dans le secteur des puces faible consommation cest linclinaison vers les
architectures VLIW
3
qui fonctionnent une frquence moindre mais qui augmentent la performance en
multipliant les units du calcul. Nous reparlerons de la consommation dnergie dans la section 3.3.
1
Imagine Stream Processor
KDK
+
01, ORK
+
02, KDR
+
02
2
Avec une exception : le processeur VLIW Transmeta Efceon consommerait
Kra04
3W 1 GHz
3
ralises par STMicroelectronics
Bag02, FBF00
et par Transmeta
Tra05b, Tra05a
37
3.2.3 Structure, capacit et frquence des mmoires
Indispensable pour le traitement, laccs rapide la mmoire est aussi important que la performance
de lunit centrale. Dans la plupart des cas aujourdhui, les mmoires sont hirarchises selon la capacit
et selon le temps daccs qui est li la frquence de la mmoire. Cette hirarchisation est gnralement
dicte par le prix du produit. On se trouve ainsi avec un systme compos de la mmoire principale et
un certain nombre (1, 2, 3, voir plus) de mmoires dites caches qui sont plus rapides que la mmoire
principale et dont la rapidit diminue et dont la capacit augmente mesure que lon sloigne de lunit
excutive. Ces mmoires sont utilises pour stocker les copies de travail des donnes. Ainsi, laccs aux
donnes durant le calcul est rendu plus rapide. Pour plus de prcisions, notamment sur les types et le
fonctionnement dtaill de la mmoire cache, nous adressons le lecteur la littrature
LM99, Str04
.
Idalement, les donnes sont prsentes dans la mmoire la plus rapide au moment o on en a besoin
pour le calcul. Si tel tait le cas, nous aurions une situation optimale. Pour y arriver et placer la donne
de la mmoire principale la mmoire cache la plus rapide, diverses stratgies sont appliques. On parle
du prchargement de la donne (angl. prefetch). Ce prchargement est implment soit au niveau du
matriel et on parle ainsi du prchargement automatique de donnes, soit au niveau du logiciel en utilisant
les instructions spcialises ddies au travail avec la mmoire cache dans le cas o notre matriel ne
dispose pas du prchargement automatique. Tel est le cas, par exemple, pour le travail avec le processeur
SH-5
BHM
+
00
.
Car, dans le cas o nous naurions pas effectu manuellement le prchargement et o la donne
ne serait pas prsente dans la mmoire la plus rapide, larchitecture procderait automatiquement au
mcanisme du chargement instantan ce qui aurait ralenti ou stopp lexcution du programme jusqu
ce que la donne ait t transfre dans cette mmoire. Et ce qui causerait, bien sr, de graves implications
sur la performance.
Nous prsentons un exemple pratique de cette situation pour le processeur SH-5, q.v. g. 3.7.
remarquer notamment la faon dexcution des instructions LD.Q et LDX.Q (cf. moiti suprieure de
FIG. 3.7 : tat du pipeline du processeur SH-5 lors de lexcution dans le cas de donnes non prsentes dans la
mmoire cache
38
la g. 3.7) qui, ne pouvant pas accder aux donnes dans la mmoire cache (cf. cache miss dans la
moiti infrieure de la g. 3.7), dclenchent le chargement des donnes partir de la mmoire principale.
Pendant la dure de ce chargement (cf. total bubble dans la moiti infrieure de la g. 3.7), le processeur
ne peut pas poursuivre lexcution et le temps est perdu inutilement avec une grande rpercussion sur la
performance ici 10 cycles supplmentaires pour chaque instruction LD.Q ou LDX.Q. Pour comparer :
si les donns taient prsentes dans la mmoire cache, ces instructions auraient pris 1 cycle chacune.
3.2.4 Paralllisation des donnes
Une catgorie de mthodes dans le traitement des images, incluant la morphologie mathmatique,
sont les traitements sur les donnes ayant le paralllisme implicite. Cette proprit, si elle est bien ex-
ploite, peut rendre le calcul plus rapide et cela dune faon importante.
Cest, en effet, la manire la plus simple daugmentation de la performance. Plutt que de traiter une
donne la fois, nous multiplions nos moyens matriels pour en traiter plusieurs en mme temps. La
manire prcise de cette multiplication peut diffrer. Si on parle de traitements SIMD, nous utiliserons la
mme instruction pour commander dune faon synchrone plusieurs units de calcul qui peuvent traiter
ainsi plusieurs donnes du mme type. Si on parle de la paralllisation au niveau des blocs capables
dexcuter chacun une procdure ou un programme dune faon asynchrone, nous allons nous rfrer le
plus souvent aux traitements MIMD.
Les donnes utilises dans la morphologie mathmatique sont de ce type. Sil sagit dun signal 1D,
dune image 2D, 3D ou de donnes multispectrales, la prsence dun grand nombre de donnes rgulires
du mme type est la premire pointer pour le traitement sur les donnes en parallle.
3.2.5 Paralllisation dexcution
Un autre phnomne entre en jeu. On lappelle la paralllisation des tches ou la paralllisation
dexcution. Il ne suft pas davoir une grande quantit de donnes pour pouvoir calculer en parallle, il
faut galement que le calcul effectuer (les tches) puisse tre excut sur plusieurs donnes en mme
temps.
Les procds de traitement dans le domaine de la morphologie mathmatique sont souvent de ce type.
On identie assez facilement les parties des algorithmes pouvant tre paralllises dans leur excution.
Il sagit des prescriptions du genre "pour tous fait...", "pour tous les pixels effectue...", etc.
Un exemple intressant de paralllisme au niveau des instructions concerne les architectures VLIW.
Nous prsentons ici le listing du code du processeur ST200
Bag02
, q.v. g. 3.8. Lexcution se poursuit par
blocs dlimits par double point-virgule (" ; ;") et les instructions de chacun de ces blocs sont excutes
en mme temps. Dans la gure prsente, nous avons encadr trois de ces blocs, chacun ayant la dure
dexcution de 1 cycle dhorloge et chacun excutant 4 instructions la fois. La planication de la
paralllisation dexcution est accomplie par le compilateur au moment de compilation. Ainsi, elle est
explicitement prsente dans le code du programme. Linuence de cette approche sur la performance est
vidente, comme son impact sur la structure de larchitecture o la paralllisation ne concerne que les
units excutives. Lunit de prparation des instructions reste une seule et commune car elle dcode une
seule large instruction.
3.2.6 cartement et latence des instructions
Les instructions excutes par un ordinateur, que ce soit un ordinateur dune architecture RISC ou
CISC, ont un comportement temporel dcrit par deux paramtres. Il sagit de lcartement (angl. pitch)
et de la latence (angl. latency) des instructions. Ces paramtres sont exprims en cycles et ils sont dune
importance cruciale sur les architectures avec un pipeline dexcution.
Le premier paramtre, lcartement dune instruction, nous indique le temps, mesur en cycles dhor-
loge, qui doit passer entre le lancement de linstruction A et le lancement de linstruction suivante B si
39
FIG. 3.8 : Listing dun programme pour le processeur ST200. Lexcution se poursuit par des blocs encadrs,
ici par 4 instructions la fois, chacun des blocs est excut durant 1 cycle dhorloge.
les oprandes de linstruction B ne dpendent pas des rsultats de linstruction A. Le temps exact diffre
suivant les architectures, il est gal au moins 1 cycle sur les architectures lancement simple des ins-
tructions, telles que SH-5. Nous pouvons citer les architectures superscalaires comme un exemple non
trivial o la dnition de lcartement nest pas vidente car ces architectures peuvent assurer lexcution
de 2 instructions et plus en mme temps.
Le deuxime paramtre, la latence dune instruction, nous indique le temps, mesur en cycles dhor-
loge, qui doit passer entre le lancement de linstruction A et le lancement de linstruction B si lins-
truction B utilise comme oprande un des rsultats de linstruction A. Dans ce cas, la prparation de
lancement de linstruction B est suspendue jusqu ce que la latence exige soit assure.
Cest le compilateur qui devrait assurer la disparition des temps morts issus des latences des instruc-
tions. Cette disparition est ralise, si ralisable, en changeant lordre dexcution des instructions et en
plaant une instruction longue latence dans une squence dinstructions latence faible ou sans latence.
3.2.7 Instructions spcialises
Un jeu dinstructions bien choisi incluant des instructions spcialises peut rendre, sil est bien utilis,
une architecture trs performante.
Nous pouvons mentionner, par exemple, le jeu dinstructions multimdia sur les architectures GPPMM
pour le calcul sur les donnes multiples. Nous pouvons mentionner galement le jeu dinstructions ma-
thmatiques spcialiss sur les GPU.
Les algorithmes du domaine de la morphologie mathmatique travaillent avec lapproche ensembliste
de traitement dimages et utilisent donc abondamment les fonctions logiques, fonctions de comparaison
et pour le travail en niveaux de gris les fonctions mathmatiques max et min. Les constructions du type
if-else sont galement trs courantes mais ne sont pas adaptes certaines architectures car elles sont
traduites et excutes comme les sauts qui peuvent rendre difcile lexploitation du pipeline et la gestion
des mmoires caches. On les transforme facilement en une squence non conditionnelle en utilisant les
instructions de comparaison et de dplacement conditionnel.
Nous allons viser les architectures qui ont ces fonctions incorpores nativement dans leurs jeux dins-
truction. Soulignons que le choix mme de larchitecture matrielle ayant les instructions dsires ne
suft pas. Un choix de la mme importance est celui du compilateur pour cette architecture et surtout
sa qualit. Nous avons beau avoir une architecture puissante, cest le compilateur qui la valorise pour
lutilisation et pour lexcution des programmes.
3.2.8 Nombre de registres et leur dsignation
Lors dun traitement multimdia qui travaille avec un grand nombre de donnes originale et de rsul-
tats partiels en mme temps, le nombre sufsant de registres qui seraient directement utilisables comme
40
Architecture Nombre de registres
Intel IA-32 Pentium 4 8 Mif64, 8 Mif128
Intel IA-64 Itanium 2 128 Mi64, 128 Mf82
IBM PowerPC 970FX (G5) 32 Mi64, 32 Mf32, 32 M128
SuperH SH-5 63 Mif64, 1 spcial Mif64
Legende : M* registre multimdia, *i* de types de nombres entiers, *f* de types
de nombres en virgule ottante, *64 registres de 64 bits, *82 bit registres de 82
bits, *128 registres de 128 bit
TAB. 3.1 : Le nombre et la dsignation des registres multimdia des reprsentants des architectures grand public
les arguments dentre dune instruction arithmtique ou logique est indispensable. Ce besoin est accen-
tu encore plus lors de traitement multimdia de donnes par lapproche qui dcoupe limage aux macro
blocs o nous avons besoin de manipuler un volume important de donnes vectorielles en mme temps.
La table 3.1 prsente une liste des types et de nombre de registres pour les architectures multimdia les
plus reprsentatives pour les applications grand public.
Notons que larchitecture Intel IA-32 emploi un autre modle de fonctionnement qui utilise abon-
damment le travail avec la mmoire cache et o nous avons la possibilit dutiliser une donne stocke
dans la mmoire directement comme argument dune instruction arithmtique. Donc, cette architecture
compense le nombre relativement petit (si on le compare avec larchitecture Intel IA-64) de registres par
un accs rapide aux donnes stockes dans la mmoire cache L1 qui est, gnralement, intgre sur la
puce et cadence, gnralement, la mme frquence que celle du processeur.
3.2.9 Approche limplmentation des algorithmes
Lors du dveloppement dune application qui devrait inclure les instructions spcialises et qui vise
la performance maximale sur une architecture donne, cest--dire qui vise la rapidit maximale dex-
cution dun programme sur cette architecture, au moins trois approches sont possibles :
La premire approche consiste en lutilisation des fonctions dj prtes et crites spciquement
pour larchitecture cible par des professionnels. Nous pouvons citer les bibliothques des fonc-
tions telles quIPP
Int06b
dIntel, une bibliothque des primitives optimises. Le gain de temps est
vident, on pargne le dveloppement du code spcialis. En revanche, ces bibliothques ne four-
nissent pas, en gnral, un ensemble complet des fonctions dont on aurait besoin dans lapplication.
Dans les applications plus complexes et plus compliques, on ne peut pas se contenter seulement
de ces bibliothques et on est oblig de crer nos propres fonctions spcialises. Nous pouvons
citer lexemple de loutil de recherche MorphoMedia
Bra05
, dvelopp au Centre de Morphologie
Mathmatique Fontainebleau au cours du projet de cette thse.
La deuxime approche consiste faire conance au compilateur et en sa qualit en esprant quil
reconnatra automatiquement les constructions complexes qui peuvent tre prsentes dans les pro-
grammes crits manuellement par les programmeurs. Cest lapproche a priori la plus rapide en
temps de programmation de nos propres fonctions mais elle ne garantit pas ncessairement le r-
sultat attendu. Pour viter les problmes lis au temps dexcution lchance dun projet de
dveloppement informatique, il faut adopter ds son dbut un style de programmation propre aux
exigences et la comprhension du compilateur. Cela implique un petit surplus de temps utilis
pour comprendre les dtails de fonctionnement du compilateur. Il sagit le plus souvent des op-
tions de compilation non standards et des directives du compilateurs incorpores directement dans
le code. Par exemple, dans le langage C++ il sagit des directives #pragma.
La troisime approche consiste en programmation de trs bas niveau et en une utilisation directe
des instructions dassembleur de la machine. Cest lapproche la plus coteuse en temps de d-
veloppement mais elle est la plus proche de larchitecture et elle peut exploiter au maximum ses
particularits. En contraste avec les approches prcdentes, elle exige du personnel connaissant les
dtails et les points spciaux de larchitecture.
41
La portabilit dun programme qui utilise les instructions spcialises une autre architecture est un
autre sujet discuter. Le code crit pour une architecture particulire qui, de plus, sen sert couramment,
est difcile porter une autre architecture. Le grand avantage des instructions multimdia des architec-
tures GPPMM est que pour quasiment tous les reprsentants existants des GPPMM nous trouvons, dans
leurs jeux dinstructions, les instructions multimdia qui assurent des fonctionnalits identiques ou trs
similaires.
De ce point de vue, la solution de portage peut tre ralise laide de la couche dabstraction du
matriel, HAL, une couche intermdiaire au niveau du logiciel qui encapsule les diffrences des codes
assembleurs de diffrentes architectures et nexporte quun interface uni et gnralis. Tel est le cas
pour loutil de recherche MorphoMedia
Bra05
. Les GPU, eux aussi, sont dots de la couche HAL prsente
par le pipeline graphique abstrait au niveau du logiciel.
3.3 Consommation dnergie
Un paramtre important pour le choix dune architecture et qui est troitement li la performance
que lon vient de discuter dans 3.2, est la consommation de lnergie. Pour certaines applications, la
consommation ne joue pas un rle important et le seul facteur limitant pourrait tre le cot de llectri-
cit. Pour dautres, la consommation dnergie est le facteur majeur du choix du matriel, surtout pour
les applications portables et nomadiques o lquipement matriel nest pas toujours connect une ali-
mentation xe et o ont doit grer la consommation, dune faon ou lautre. Cela est assur souvent par
lutilisation des rgimes conomiques qui changent la frquence du processeur selon les besoins actuels
de performance ou qui arrtent partiellement ou compltement le fonctionnement en cas dinactivit.
Dans ces cas prcis, le taux consommation/performance est celui qui oriente le choix dun processeur
plutt que dun autre.
La table 3.2 prsente une liste non exhaustive des processeurs issus des architectures que nous ci-
blons dans cette thse. Le premier groupe prsente la consommation de processeurs GPP/GPPMM. Le
deuxime groupe, en contraste avec le premier, prsente les GPP/GPPMM mobiles ou basse consom-
mation. Le troisime groupe prsente la consommation des GPU. Le tableau nit par prsenter la consom-
mation des consoles de jeux, cest--dire dautres architectures spcialises qui peuvent tre vises par
les algorithmes dcrits dans cette thse.
Ce qui nous intresse quant aux processeurs dans ce tableau, cest la consommation dnergie. Pour
linformation, nous y prsentons galement les valeurs de MIPS et de FLOPS que nous avons pu collecter
pour que le lecteur se fasse une ide des performances lies la consommation. Tout en sachant que ces
descripteurs ne sont pas les meilleurs que lon puisse trouver pour valuer la performance mais ils nous
permettent de comparer, au moins au niveau de lordre, les performances darchitectures aussi diffrentes
que, par exemple, SH-5 et AMD Athlon64 FX-60 avec deux curs.
Le premier regard sur les donnes dans le tableau 3.2 nous rvle que la consommation des GPPMM,
des GPU et des consoles de jeux est de mme ordre. Comme les vainqueurs sortent de cette comparaison
les consoles de jeux car si on voulait obtenir lquivalent dune telle solution partir des GPP et GPU,
nous devrions additionner la consommation dun GPP choisi avec la consommation dun GPU choisi ce
qui donnerait lestime une somme deux fois suprieure celle des consoles de jeux. Dans une telle
logique, le ratio performance-consommation est plus favorable aux consoles de jeux.
Les solutions consommation basse ou rduite se font remarquer par la consommation infrieure
de quelques ordres par rapport aux solutions dcrites prcdemment. Ce qui nest pas surprenant car il
sagit de leur dsignation. En mme temps, ils noffrent pas les mmes performances. La diffrence est
importante mais le ratio MIPS par Watt est plus lev pour les solutions basse consommation.
Parmi les architectures de ce type et tout--fait intressantes qui combinent une haute performance
et une basse consommation dnergie nous trouvons les architectures VLIW. Ces architectures sont re-
prsentes par les processeurs tels que ST200
Bag02
bass sur la plateforme nomme Lx
FBF00
de STMi-
croelectronics et par les processeurs Transmeta Crusoe
Tra05a
et Efceon
Tra05b
. Le dernier, Transmeta
42
Jaromr BRAMBOR 3.3. CONSOMMATION DNERGIE
GPP/GPPMM
Processeur(s) Anne
Frquence, MHz Consommation,
MIPS MFLOPS
Processeur (/ Mmoire) W
Intel Pentium XE 955
Int06c
2006 3460 / 1066 156
Gav05a

(dual cur, HT)
AMD Athlon 64 FX-60
Gav06
2006 2600 110 22150
Wik06h
(dual cur)
Intel Pentium 4 6xx
Gav05b
2005 3000 3800 120 140
Intel Itanium 2
NSG05b
2005 1800 100
AMD Athlon 64
Wik05a
2005 2800 8400
Intel Pentium 4 EE
Wik06h
2003 3200 9726
GPP/GPPMM mobiles, basse consommation
Processeur(s) Anne
MIPS MFLOPS
Transmeta Efceon TM8800
Tra05c
2005 1700 3W@1GHz
Kra04

(VLIW)
ARM11 MPCore
GS05, ARM06
2005 400-550 <0.25 2600 (DMIPS)
multiprocesseur 4x core, SIMD
SuperH SH-5
Nor01, Sup02
2002 133-167-400 < 0,4 240-300-714
Mobile Pentium III
Nor01
2001 750 20 875
PowerPC 750
Nor01, FS02
2001 200-400 5,7-5,8 488-733
GPU
Processeur(s) Anne
MIPS MFLOPS
NVidia 7800 GTX Extreme
Kre05
2005 430 180-343
NVidia 7800 GTX
TP05
2005 430 100-110
Rey06
165000
2x NVidia 7800 GT Dual 2005 430 213 / 317
(4 GPU)
Kre05
(2D / 3D)
ATI Radeon X850 2004(5) 540 / 590 GDDR3 90
ATI06

Consoles de jeux
Processeur(s) Anne
MIPS MFLOPS
Sony PlayStation 3
Wik06i
2005(6) 3200 (8xCPU), 218000
et 550 (GPU)
/ 3200 XDR DRAM,
700 GDDR3
Microsoft Xbox 360
Wik06l
2005 3200 (3xCPU), 160
Gre05
115000
500 (GPU)
/ 1600 L2,
700 GDDR3
TAB. 3.2 : Consommation dnergie des GPP/GPPMM, des GPU et des consoles de jeux
43
Efceon, devrait consommer 3W 1 GHz
Kra04
et implmente les instructions multimdia
Tra05c
, compa-
tibles avec MMX, SSE-SSE3 dIntel ce qui entre intgralement en cohrence avec le sujet de cette thse
et ouvre un autre champ dapplication pour nos algorithmes.
3.4 Modle stream du calcul et les architectures associes
3.4.1 Calcul sur les streams
Le calcul qui considre les donnes comme si elles taient alignes dans un ux et arrivaient conti-
nuellement dans les units du calcul est propre aux architectures stream et dans la taxonomie de Duncan
correspond, sans surprise, au type ux de donnes, cf. 3.1.2.4.
Toutes les donnes qui passent par une unit excutive sont traites de la mme faon par un et mme
programme. Il sagit dune caractristique forte et trs importante car elle nous permettra de facilement
parallliser lexcution lintrieur dune unit du calcul par la multiplication de nos moyens matriels.
Ainsi, plusieurs blocs dexcution lintrieur dune unit du calcul vont pouvoir travailler concurrem-
ment en excutant le mme programme, en se partageant les donnes du ux dentre et en assemblant
les rsultats dans un ux de sortie.
Si le traitement dune donne est indpendant des autres donnes, la paralllisation se rvle simple.
Cette situation est dmontre sur la g. 3.9. Sa partie 3.9(a) illustre le traitement dun stream de donnes
o ce nest quune seule donne qui est traite dans un temps tet indpendamment des autres donnes.
La paralllisation de ce traitement est prsente sur la g. 3.9(b) ; dans le mme intervalle t, n donnes
du ux dentre sont distribues, traites dans les units excutives et assembles nouveau dans le ux
de sortie.
Notons que dans le cas o le traitement dune donne de sortie dpend de plusieurs donnes dentre
(e.g. la somme des lments), la stratgie de paralllisation ne sera pas aussi intuitive et va fortement
dpendre du caractre de lopration effectuer.
D E
t
D D D D D D D D D D D
(a) excution en stream avec 1 unit excutive
D
t
D
D D
D D D D
D D D E
n
E
2
E
1
D
(b) excution en stream et en parallle avec n units excutives
FIG. 3.9 : Calcul sur un stream de donnes, D - donne, E
i
- unit excutive i
Dune faon gnrale, nous ne parlons pas dune opration ou dun programme mais plutt dun
kernel. Kernel est un terme qui englobe toutes les activits qui peuvent tre effectues sur un stream.
Regardons maintenant quels sont les types doprations les plus courantes du paradigme stream que
les kernels implmentent. Il sagit de lapplication (angl. map), de la rduction (angl. reduce), et du
ltrage (ang. ltering). Davantage de types de kernels oprant sur les stream peut tre consult dans la
littrature
OLG
+
05
. Remarquons que ces oprations ont leurs correspondants directs dans les fonctions de
divers langages de programmation qui supportent, dune faon ou de lautre, le travail avec les listes.
Notamment il sagit de Haskell, LISP, Python.
44
Jaromr BRAMBOR 3.4. MODLE STREAM DU CALCUL ET LES ARCHITECTURES ASSOCIES
3.4.1.1 Kernel dapplication
Lapplication est une opration lmentaire et en mme temps la plus simple qui peut tre effec-
tue par un kernel. tant donn un stream S et une fonction f, le kernel K
M
implmentant lopration
application va appliquer la fonction f tous les lments du streamS. La g. 3.10 illustre cette situation.
D K
M
=f()
t
D f(D) f(D) D D D D f(D) f(D) f(D) f(D)
FIG. 3.10 : Exemple dun kernel dapplication. La fonction f est applique tous les lments du stream. D -
donne, K
M
- kernel dapplication, f - fonction appliquer
3.4.1.2 Kernel de rduction
Le kernel de rduction effectue une opration qui partir dun large stream dentre dont les lments
sont constitus de m donnes lmentaires calcule un stream plus troit de n donnes lmentaires o
m > n 1. Nous pouvons citer comme exemple toutes les fonctions ayant plusieurs valeurs lentre
et une valeur la sortie, par exemple la somme, somme des valeurs absolues, maximum, minimum,
opration sur le voisinage, opration binaire avec un masque, etc. La g. 3.11 illustre cette situation.
Un exemple trivial dun kernel de rduction est la somme des valeurs du stream tout entier. Son
rsultat est un ux constitu dun seul lment qui ne contient quune seule donne - la somme.
K
R
t
D
1
D
m
D
1
D
m
D
1
D
m
D
1
D
m
D
1
D
m
D
1
D
m
D
2
D
2
D
2
D
2
D
2
D
2
D
1
D
n
D
1
D
n
D
1
D
n
D
1
D
n
D
1
D
n
D
1
D
n
FIG. 3.11 : Le kernel de rduction cre un stream plus troit partir dun stream plus large. D - donne, K
R
-
kernel de rduction
3.4.1.3 Kernel de ltrage
Le kernel de ltrage effectue un ltrage sur le stream en laissant passer les lments qui remplissent
une condition et en liminant les autres. Nous pouvons citer comme exemple le ltrage pour liminer les
valeurs ngatives dun stream, q.v. g. 3.12.
-1
K
F
>=0
t
1 1 1 1 -1 1 -1 1
FIG. 3.12 : Exemple de fonctionnement dun kernel de ltrage. la sortie, les valeurs ngatives sont limines
du stream. D - donne, K
F
- kernel de ltrage
3.4.2 Architectures stream
Les architectures stream sont les architectures qui ont t directement conues pour le travail avec
les ux de donnes. Les exemples les plus loquents des systmes travaillant sur des donnes stream
sont srement les composantes de rseau. Dans leurs cas, les donnes arrivent dans un stream en tant
que paquets, ordonnes dans le temps. Ces paquets sont traits par le programme de la composante et
ressortent comme des paquets transforms, galement dans un stream.
45
Les architectures de ce type sont particulirement intressantes pour le domaine du traitement dimages
et des signaux. La tlvision et le traitement de la vido sont de trs bons exemples des applications o le
ux de donnes est trait par les architectures stream. Nous pouvons mentionner aussi les capteurs CCD
ou CMOS prsents dans les quipement digitaux tels que les camras ou les appareils photographiques
qui ont leur sortie un ux linaire des donnes. Ces donnes, une fois stockes comme des images 2D
dans la mmoire, ne prsentent plus la nature dun ux vido. Cette nature revient lors dun traitement
de ces donnes sur les processeurs squentiels o un procd trs frquemment utilis est constitu de la
transformation de ces donnes en un ux suivie par lapplication dun algorithme sur ce ux. Notons que
ce ux peut tre constitu des pixels mais galement des units plus grandes comme des lignes entires
ou les macro blocs. Comme exemple nous pouvons citer une architecture recongurable Cheops
BW95
,
conue pour le traitement des donnes vido dans les camras et les tlvisions HDTV.
Le phnomne de traitement sur les ux est prsent galement dans les traitements morphologiques,
nous pouvons citer comme exemples une architecture lectronique ddie aux algorithmes de segmen-
tation
Lem96
ou une tude des architectures spciques pour la morphologie
Sas02
ou mme une ralisa-
tion antcdente (1983/84) dun logiciel de morphologie mathmatique pour le calculateur PROPAL
2
BM83, Beu84
, spcialis pour le traitement en parallle avec les capacits SIMD.
Plus rcemment, lquipe commune des laboratoires des universit de Stanford et de Rice a prsent
plusieurs publications portant sur larchitecture dun processeur stream nomm Imagine
1
quils ont d-
veloppe. Ce processeur tait dot de 8 clusteurs de traitement gnral et avec 6 ALUs par clusteur :
il possdait 48 ALUs au total. Ce processeur tait ralis sur une seule puce pour pouvoir exploiter au
maximum la localit des donnes stockes dans les registres temporaires prsents sur la puce.
Bien que ces architectures soient spciques et mme trs intressantes pour les applications de
nos algorithmes et bien que nos algorithmes sadressent aussi elles, ces architectures ne constitueront
pas notre intrt principal et nous ne les mentionnons ici que pour donner une vue globale et complte
sur la problmatique. Car, comme nous lavons soulign dans le chapitre Motivation, page 19, nous
nous intressons en particulier aux architectures plus gnrales grand public avec les fonctionnalits
multimdia et aux processeurs graphiques.
3.4.3 Architecture de von Neumann et ses successeurs utiliss pour le calcul stream
3.4.3.1 Architecture de von Neumann
Les machines du calcul que nous connaissons aujourdhui en tant que GPP sont bases sur larchi-
tecture de von Neumann qui se caractrise par un bloc dunit centrale (CPU) qui assure le calcul, par un
bloc de mmoire commune pour les donnes et pour les instructions et par un bus qui relie ces deux blocs
ensemble. La gure 3.13 prsente la structure de larchitecture du type von Neumann avec la mmoire
cache prsente dans le CPU.
Mmoire
principale
CPU
Mmoire(s)
cache ALU
MEM
BUS
Registres
Unit de contrle
FIG. 3.13 : Schma de larchitecture von Neumann avec une mmoire cache incorpore dans lunit centrale,
CPU - bloc dunit centrale, MEM - bloc de la mmoire, BUS - bus assurant la liaison de lunit centrale la
mmoire
Il faut mentionner intensment que larchitecture de von Neumann nest pas une architecture paral-
lle. Elle tait conue pour lexcution dun code squentiel et dans sa version dorigine, elle nest pas
du tout adapte un calcul sur les streams. Notons que le code parallle est excut en squence sur
1
Imagine Stream Processor
ORK
+
02, KDK
+
01, KDR
+
02, KRD
+
03
, implment physiquement en silicium sur la puce dont la surface
tait 2,6 cm
2
46
cette architecture et nous nexploitons pas du tout les avantages dun possible paralllisme. Le goulot
dtranglement principal et en mme temps un grand dsavantage de cette architecture est la manire
daccder aux donnes dans la mmoire o celles-ci sont obliges de circuler dans les deux sens entre
la mmoire et lunit du calcul. La mmoire cache prsente sur la puce dans le bloc CPU est dj une
technique utilise pour diminuer limpact de ce goulot dtranglement.
En revanche, les architectures ux de donnes nutilisent pas deux concepts fondamentaux de
larchitecture de von Neumann le compteur des instructions (angl. Program counter), qui est propre
au traitement squentiel, et le stockage global des donnes dans un systme de mmoire compos dune
hirarchie plus ou moins complexe des mmoires.
Les solutions qui seraient convenables la fois pour le calcul en squence et pour le calcul sur les
streams et qui essayaient de combiner larchitecture de von Neumann et larchitecture de ux de donnes
ont t galement tudies, surtout dans les annes 1980. Diverses ralisations qui travaillaient avec
diffrents niveaux de granularit ont t prsentes ; comme exemple nous pouvons citer larchitecture
hybride dcrite dans la thse de Iannucci
Ian88
en 1988.
De nos jours, lapproche percevant lexcution du code dans le temps comme des ls dexcution
(angl. thread) a largement chang le point de vue sur la structure originale de larchitecture de von
Neumann et a orient lvolution des architectures GPP bases sur cette dernire vers les architectures
adaptes au travail avec les ux de donnes architectures multithread. Pour plus dinformation sur le
rapprochement entre des architectures ux et des architectures multithread, nous invitons le lecteur se
rfrer un article
SRU01
qui tudie ce point prcis trs en dtail. Pour plus de dtails gnraux sur les
diverses architectures des ordinateurs et sur leurs conceptions, nous adressons le lecteur une des livres
de William Stallings, e.g. la septime
1
dition
Sta06
.
3.4.3.2 Fils dexcution et multitche
Percevoir lexcution sur un ordinateur travers des processus distincts (on parle aussi des tches)
est la pratique couramment utilise dans les systmes logiciels qui doivent assurer lexcution des pro-
grammes ou routines dune faon concurrente. Ils doivent souvent grer la priorit, notamment dans les
cas o il est important de livrer les rsultats dune tche soit le plus tt possible, soit dans un temps
prdni, soit plus tt que le rsultat dune autre tche. Lexemple le plus marquant de travail avec les
processus que nous appelons galement travail multitche sont les systmes dexploitation multitches
dans les ordinateurs. Mais nous pouvons trouver le mme style de travail aussi dans les systmes informa-
tiques pour lautomatisation industrielle o les tches sont galement concurrentes et de plus, la demande
dobtention des rsultats dans un temps prdni est cruciale et dict par la nature de la technologie
contrler.
Pour exploiter le paralllisme une chelle plus petite lintrieur dun processus, les ls dexcu-
tion ou autrement dits les processus lgers
Wik06j
(angl. threads) sont utiliss. La diffrence entre les ls
dexcution et le multitche classique rside dans le fait que les processus classiques sont typiquement
indpendants les uns des autres et communiquent en utilisant une interface fournie par le systme. En
revanche, les ls dexcution peuvent partager des information sur ltat du processus auquel ils appar-
tiennent, les espaces de la mmoire ainsi que dautres ressources. Lexemple trivial dexcution en l
est celui dun processus constitu dun seul l dexcution, dun single thread. Dans les autres cas, nous
parlons dun processus plusieurs ls dexcution, dun processus multithread (MT).
Larchitecture matrielle qui effectue lexcution peut tre, et pour les GPP fut longtemps, larchi-
tecture de von Neumann. Puisquil ne sagit pas de larchitecture parallle, laspect concurrent dexcu-
tion disparat, le temps du processeur est distribu par portions entre les ls et lexcution se poursuit
dune faon squentielle. Mais lchelle du temps moins prcise, lexcution des ls est perue comme
concurrente. Dans ce cas nous parlons du multithreading virtuel (VMT).
1
Septime dition est la plus rcente en 2006
47
bloqu actif
Temps
Processus no. 1
Processus no. 2
Processus no. 3
(a) Multiprocessing sur un processeur
Temps
Processus no. 1
Processus no. 2
Processus no. 3
(b) Multiprocessing sur plusieurs processeurs, les processus sont excuts concurremmet
FIG. 3.14 : Excution de plusieurs processus sur les architectures diffrentes (selon Stallings
Sta06
)
Si les ls peuvent tre excuts en mme temps, nous parlons du multithreading simultan (SMT).
Sur les architectures o laspect parallle dexcution est prsent et qui peuvent lancer plusieurs ins-
tructions de plusieurs ls dexcution, nous parlons du Chip-level MultiThreading (CMT). Si plusieurs
processeurs sont intgrs dans une seule puce, nous parlons de multiprocessing au niveau de la puce
(CMP) ou de plusieurs curs (angl. multicore).
La sauvegarde de ltat dun l dexcution suivie par la restauration de ltat dun autre l qui pour-
suivra loccupation des ressources communes lors de lexcution concourante est nomme le changement
du contexte. Il peut tre moins coteux, mesur par la dure de ce changement, sur les architectures qui
partagent certaines ressources matrielles comme la mmoire cache, par exemple. Cest souvent le cas
pour le multithreading simultan dans les applications multimdia.
3.4.3.3 Architectures ls dexcution
Les architectures matrielles se sont adaptes cette faon de travailler et ont procd aux amliora-
tions en liminant progressivement les goulots dtranglement qui freinaient les applications logicielles
de ce type.
Dans un premier temps, leffort sest concentr sur les units de prparation dexcution des ins-
tructions. Ces units travaillent en pipeline qui peut tre relativement long
1
. Durant le travail avec les
threads, le changement du contexte provoque le vidage de ce pipeline et un nouveau remplissage par
ltat restaur appartenant au nouveau thread. Ce qui cause, en effet, la perte du temps. Cette perte est di-
rectement proportionne, travers les cycles dhorloges ncessaires pour remplir le pipeline nouveau,
la longueur de ce pipeline et la frquence de changements des contextes. Ce qui dfavorise forte-
ment les applications travaillant frquemment avec les threads. Pour diminuer cette perte, la solution se
trouve dans la multiplication du nombre de ces pipelines. Les processeurs qui ont adopt cette solution
implmentent, en effet, le multithreading simultan. La technologie de ce type dveloppe par Intel est
nomme Hyper-Threading Technology
MBH
+
02
.
La g. 3.15 prsente le schma de la structure dune telle architecture. Remarquons que ces tech-
nologies, que nous classons sous CMT, ne sont pas destines uniquement aux processus lgers mais
exploitent aussi bien le paralllisme des processus distincts lors dun travail multitche.
Les solutions rcentes utilisent cette ide et ont aussi tendu la multiplication matrielle aussi aux
units centrales entires. Cest ainsi que nous avons aujourdhui notre disposition les architectures
1
Tejas, le prototype du successeur du Intel Pentium 4, dont le dveloppement a t abandonn, possdait un pipeline de 31
phases
FH05
48
Mmoire
principale
CPU
MEM
BUS
Registres
Registres
Unit de contrle
(pipeline)
LP1
Unit de contrle
(pipeline)
LP2
ALU
Mmoire(s)
cache
FIG. 3.15 : Architecture hyper-threading, CPU - bloc dunit centrale, MEM - bloc de la mmoire, BUS - bus
liant lunit centrale avec la mmoire, LP
- processeur logique
plusieurs curs qui implmentent plusieurs units centrales lintrieur dune seule puce. Si les curs
eux-mmes implmentent le multithreading simultan, nous pouvons parler de la combinaison du mul-
tiprocessing, CMP, et du multithreading, CMT, au niveau de la puce. La g. 3.16 illustre cette situation
sur un processeur avec deux curs o chaque cur implmente aussi le multithreading simultan. Nous
pouvons citer comme reprsentant les processeurs avec deux curs dIntel
Int06d
ou dAMD
AMD06
et le
processeur basse consommation avec quatre curs dARM
ARM06
.
Mmoire
principale
MEM BUS CPU1
Registres
Registres
Unit de contrle
(pipeline)
LP1
Unit de contrle
(pipeline)
LP2
ALU
Mmoire(s)
cache
CPU2
Registres
Registres
Unit de contrle
(pipeline)
LP3
Unit de contrle
(pipeline)
LP4
ALU
Mmoire(s)
cache
FIG. 3.16 : Architecture hyper-threading avec deux curs, CPU
- bloc dunit centrale, MEM - bloc de la

mmoire, BUS - bus liant lunit centrale avec la mmoire, LP
- processeur logique
Ces solutions prsentent laspect parallle et nous pouvons les classer parmi les architectures MIMD
avec la mmoire partage. La philosophie de construction a chang, on est en train de travailler en
parallle mais nous pouvons toujours distinguer les bases de larchitecture de von Neumann un bloc de
mmoire dun ct et un bloc dunit centrale, mme complexe et avec deux curs, de lautre.
3.4.4 Calcul stream sur les architectures SWAR plusieurs ls
Comment exploiter alors le paralllisme prsent dans les architectures succdant celle de von Neu-
mann pour le travail qui nous intresse ? Puisquil sagit des architectures parallles qui exploitent le
paralllisme de plusieurs ux dinstructions, nous devrions modier notre regard classique sur lex-
cution en stream, comme prsent dans 3.4.1, page 44, sans pour autant modier notre philosophie de
travail.
En effet, nous devons exprimer le calcul dun kernel dexcution sur un seul ux de donnes en
utilisant plusieurs ls qui vont tous implmenter la mme fonctionnalit du kernel et travailler sur les
parties du ux principal.
On procde la division du problme en parties plus petites, suivie par lexcution en parallle sur
une architecture parallle, et terminons par la collecte des rsultats. Ce procd correspond au paradigme
de la programmation parallle nomm Divide and Conquer, propre aux architectures MIMD, o une et
49
mme routine est excute sur plusieurs processeurs, physiques ou logiques, en traitant plusieurs donnes
en mme temps. La g. 3.17 illustre cette situation.
t
DIV
T
1
T
2
Tn
CQR
f(D) f(D) f(D) f(D)
D D
D D
D D
D D D D
f(D) f(D)
f(D) f(D)
f(D) f(D)
FIG. 3.17 : Calcul sur un stream en utilisant les ls dexcution et lapproche Divide ans Conquer, T
- thread,
DIV - phase de division du stream, CQR - phase conquer, collecte des rsultats, D - donne, f - fonction du
kernel
La diffrence entre le traitement du stream en parallle comme on la prsent dans la section 3.4.1
et sur la g. 3.9(b), page 44, qui correspond au paradigme nomm processor farm; et le traitement du
stream en ls dexcution qui correspond au paradigme Divide and Conquer rside dans le fait que pour
le dernier, les units parallles de traitement des threads ne peuvent pas tre englobes dans un macro
bloc et tre perues comme une seule macro unit traitant le stream. En effet, nous divisons physiquement
le stream principal en autant de sous-streams quil y a de ls dexcution. Ainsi, le procd Divide and
Conquer est bien perceptible.
Les architectures contemporaines GPPMM, cf. 1.2 dans le chapitre Motivation, page 20, utilisent
les fonctionnalits SIMD incorpores dans les instructions et implmentent le paralllisme de donnes
au niveau des registres. Nous parlons ainsi du traitement SWAR
Nor01
, autrement dit traitement SIMD
lintrieur dun registre (angl. SIMD Within A Register), qui correspond au Subword Parallelism dans le
domaine de traitement des signaux. Les GPPMM sont galement dots, outre ces fonctionnalits multi-
mdia, des fonctionnalits matrielles pour lexcution plusieurs ls. Elle nous ouvrent ainsi un autre
champ dapplications. En exploitant le paralllisme prsent dans les traitements dimages par la morpho-
logie mathmatique, nous pouvons facilement augmenter la performance nale de nos algorithmes sur
ces architectures.
Lutilisation des capacits MT dans les applications du traitement dimages devient progressivement
une technique courante
CHD
+
02
mais son implmentation appartient au domaine de la programmation
spcialise. Nous distinguons deux approches dans le dveloppement de ces applications :
dveloppement manuel qui consiste en programmation dune application multithread laide des
mthodes explicites telles que lutilisation des bibliothques pour la cration, gestion et synchro-
nisation des threads (Win32 ou POSIX). La restructuration complte du code est exige pour une
telle implmentation.
dveloppement automatique ou semi-automatique laide dun compilateur. Dans le cas automa-
tique cest le compilateur lui-mme qui reconnat les structures parallles et les traduit en threads.
Dans le cas semi-automatique cest le programmeur qui marque, laide des commandes du pr-
processeur, les parties du code parallliser qui sont ensuite transformes par le compilateur. Il y
incorpore ses propres fonctions pour lexcution des rgions en parallle. Tel est le cas de lAPI
OpenMP
Ope06
qui est intgr, parmi dautres, dans les compilateurs Intel
Bre05, TBG
+
02
du C++ et
du Fortran.
50
3.4.5 Pipeline graphique et les GPUs
3.4.5.1 Terminologie de la synthse des images
Mme si le traitement morphologique des images appartient au domaine de lanalyse dimages, notre
explication du pipeline graphique va commencer avec leur synthse. Car cest elle que nous devons la
notion du pipeline graphique.
Les processeurs graphiques sont les processeurs destins la synthse des images. Ils ont une ar-
chitecture spcique, compltement subordonne au traitement des pixels et destine la visualisation
partir dun modle de synthse. Cest pourquoi nous parlons dun pipeline graphique, dun pipeline qui
est la fois une abstraction de fonctionnement, implmente soit dans un logiciel comme un programme
soit comme une architecture matrielle o la notion du pipeline prend son vritable sens de chane de
traitement.
Ainsi, la terminologie de la synthse des images est utilise aussi dans la description des algorithmes
travaillant avec le pipeline graphique pour dsigner les divers blocs fonctionnels de cette dernire et cela
mme dans les algorithmes qui ne sont pas relatifs la synthse des images. Nous allons galement suivre
cette logique et utiliser cette terminologie dans les algorithmes de la morphologie mathmatique pour les
GPU o nous ne travaillons pas avec la synthse des images et nous ne nous concentrons pas seulement
sur leur traitement ; nous devrions parler plutt du traitement des donnes vectorielles ou matricielles ou
du traitement des graphes.
La synthse des images 2D est un processus qui, partir dun modle mathmatique, cre une image
2D destine principalement tre rendue sur un cran. Le modle mathmatique peut varier, nous pou-
vons travailler avec les modles de surface 3D dcrits par la gomtrie en espace 3D ou avec les modles
de volume 3D qui utilisent linterprtation dun volume par des donnes discrtises o chaque lment
du volume, voxel, dtient une information. Pour le rendu 3D, il sagit souvent dun coefcient dabsorp-
tion.
3.4.5.2 Structure du pipeline graphique
Regardons le schma
1
du pipeline graphique programmable prsent sur la g. 3.18. Ce schma pr-
sente les blocs principaux du pipeline qui correspondent dans les GPU aux diverses units de traitement,
congurables ou programmables. Ce schma montre galement la faon dont les GPUsont connects aux
GPP et lapplication graphique dans ces derniers travers de lenvironnement run-time dune interface
de programmation dapplication (API).
Dans cette conguration, les processeurs graphiques sont les acclrateurs de traitement et sont su-
bordonns aux processeurs gnraux. Ainsi, nous nous retrouvons avec un systme de calcul distribu
qui ne compte quune unit dirigeante et une unit excutante. Notons qu prsent, la notion du calcul
distribu sest encore accentue car nous comptons parmi les ralisations matrielles rcentes galement
les systmes avec deux ou mme quatre GPU
Kre05
: citons les technologie NVidia SLI et ATI CrossFire.
Cest le GPP qui gre compltement le traitement sur les GPU travers des commandes de congu-
ration, des commandes dexcution ou des commandes initiant un transfert de donnes vers ou partir
des GPU. Ces commandes sont passes travers lune des interfaces API qui nexpose au program-
meur que des fonctions de haut niveau. Cest le pilote de la carte graphique dans les GPP qui reoit ces
commandes, qui les interprte et qui se charge de leur envoi dans les GPU pour les excuter.
Le traitement sur les GPU est diffrent de celui que lon connat du domaine des GPP. Dans les
GPU, les commandes ont la forme des prescriptions dessiner et cest, en effet, exactement la manire
dont on les programme. Lapplication envoie la description dune forme, il pourrait sagir de points,
triangles, rectangles, polygones, courbes ou surfaces. Celles qui ne sont pas reconnues par le matriel
sont transformes par les couches intermdiaires de logiciel en formes plus simples. On utilise souvent
les lignes ou triangles soit pour diviser une forme complexe en formes basiques (comme un polygone
1
Schma synthtis partir de plusieurs sources
FK03, FK03, WNDS99
51
Application
API
(DirectX ou OpenGL)
Interprtation
des commandes
dans le GPU
Vertex
processeur
Assemblage
des primitives
Rastrisation
et interpolation
Fragment
processeur
Raster
oprations
Frame buffer
Sortie vido
Frontire GPP-GPU
3D API commandes et donnes
Commandes et le flux des donnes pour le GPU
G
P
P
G
P
U
Flux des vertex
Vertex textures
Polygones, lignes, points
Fragments rastriss
Fragments transforms
Pixels
U
n
i
t
d
e

g
e
s
t
i
o
n

d
u

G
P
U
(
c
o
n
f
i
g
u
r
a
t
i
o
n

d
e
s

b
l
o
c
s

d
u

p
i
p
e
l
i
n
e

g
r
a
p
h
i
q
u
e
)
chantillonnage
Render buffers
Programme,
paramtres globaux
M
m
o
i
r
e
(
t
e
x
t
u
r
e
s
,

b
u
f
f
e
r
s
,

l
i
s
t
e
s

d
e
s

v
e
r
t
e
x
)
Contrle
Programme,
paramtres globaux
Contrle
Configuration
du frame buffer
Contrle
Fragment textures
chantillonnage
Vertex transforms
FIG. 3.18 : Schma des blocs du pipeline graphique
52
peut tre divis en triangles), soit pour approximer une forme complexe en formes plus simples (comme
une courbe spline peut tre approxime par plusieurs lignes droites).
Les formes de base sont dcrites par leur type (point, ligne, etc.) et par un ensemble de points de
lespace 3D que nous appelons les vertex. Un vertex est une structure complexe et elle peut contenir plus
dinformations que seulement les coordonnes dans lespace ; notamment linformation sur la couleur,
sur les index pointant dans les textures o mme davantage dinformations spciques au calcul effectu.
Une telle commande graphique est passe, utilisant un des interfaces API, au processeur graphique.
3.4.5.3 Fonctionnement du pipeline graphique
Le fonctionnement de base dun pipeline graphique programmable est le suivant. Toutes les donnes
sont traites en tant que ux. Tout dabord, un programme que nous appelons vertex programme est
appliqu sur tous les vertex dentre. Ce traitement correspond sur la g. 3.18, page 52, au bloc vertex
processor, aussi appel par le terme anglais vertex shader. Selon le paradigme stream de traitement
des donnes, le mme programme est appliqu sur tous les vertex. Ce programme ragit localement
et son excution sur un vertex est donc indpendante de lexcution sur dautres vertex. Il dispose des
paramtres globaux pour la lecture mais il ne peut pas les modier et il ne peut crire non plus de valeur
quelconque dans une mmoire commune. En effet, il ne peut que modier les valeurs des proprits
du vertex quil traite. Il est donc impossible de crer de nouveaux vertex, davoir une variable globale
partage modiable par tous les vertex ou dinuencer lexcution dautres vertex. En revanche, nous
pouvons accder aux donnes globales stockes dans la mmoire comme textures en utilisant le processus
dchantillonnage des textures.
Les vertex traits passent le long du pipeline dans lunit suivante, lunit dassemblage des primi-
tives. Cette unit se charge de lextraction des primitives graphiques de base (dcrites par la commande
graphique) et de tous leurs descripteurs partir du ux des vertex. Il sagit, en effet, du dcodage des
formes de base partir de la commande graphique que nous avons passe au GPU. Cette unit prpare
les primitives gomtriques pour ltape suivante du pipeline la digitalisation de cette forme.
La digitalisation est dcrite sur la g. 3.18 comme bloc Rastrisation et interpolation, qui se charge
de la cration des fragments. Les fragments sont la reprsentation digitale dune forme dans un espace
3D digital. La faon exacte dont on drive les fragments partir de cette forme est dpendante des
paramtres du modle de projection que nous avons choisi et des dimensions de notre framebuffer que
nous pouvons imaginer, dune manire simplie, comme une surface digitale destine au rendu de notre
modle 3D.
Soulignons la diffrence entre les fragments et les pixels. Les pixels sont les points de lespace digital
2Ddont la valeur est la couleur. Les fragments sont des structures beaucoup plus riches dans leur contenu,
on qualie un fragment comme un prototype dun pixel. La premire diffrence est dans le fait quun
fragment est dcrit par les coordonnes 3D; simplement dit, un fragment possde dune information sur
la profondeur. Cela donne la possibilit davoir dans le pipeline plusieurs fragments de la mme position
2D qui diffrent dans leur profondeur. Et surtout, un fragment peut contenir davantage dinformations
quun pixel. En revanche, un pixel nous sert comme une structure pour les donnes qui sont inscrites
la n du traitement dans le framebuffer, il contient une position 2D xe et na plus dinformation sur la
profondeur. Dans les algorithmes classiques de synthse des images, il ny a quun pixel qui est gnr
pour une coordonne donne
1
.
Les informations que nous plaons dans les fragments sont obtenues partir des vertex. Puisquune
forme gomtrique est dcrite, dans la plupart des cas, par moins de vertex quil ny a de fragments
drivs de cette forme, nous sommes obligs de distribuer linformation des vertex vers les fragments.
On utilise avec succs linterpolation des valeurs des paramtres partir de plusieurs vertex (2, 3, voir
plus) pour cette distribution. Cette approche est largement utilise pour obtenir la position dun fragment
1
Avec lexception dun traitement des points comme des point-sprites qui peuvent gnrer plusieurs fragments et ensuite
plusieurs pixels pour une seule coordonne 2D
53
lintrieur dune forme, pour interpoler les couleurs, les vecteurs dcrivant les proprits de la surface,
les coordonnes des textures et peut mme tre utilise pour interpoler dautres donnes qui nont pas un
correspondant direct dans le graphisme 3D.
Aprs la cration et lobtention des paramtres interpols des vertex, les fragments passent lunit
de traitement des fragments dcrite sur la g. 3.18 par le bloc Fragment processeur et appele galement
par le terme anglais fragment shader. Il sagit dune unit de traitement qui traite le ux de la mme
manire que le Vertex processeur. Cest--dire que nous pouvons accder aux paramtres globaux et
mme chantillonner les textures mais nous ne pouvons pas inuencer le traitement dautres fragments ou
crer de nouveaux fragments. Dans les applications graphiques 3D, cette unit est utilise pour un calcul
intensif de la couleur locale du fragment et implmente la partie principale du calcul de lillumination de
la partie de la surface 3D qui correspond au fragment. Cest pourquoi ce bloc fonctionnel est fortement
paralllis, plus que celui du processeur des vertex, et son implmentation matrielle est optimise pour
laccs massif aux textures, ce qui se traduit par une structure particulire des mmoires caches qui ont
pour but dexploiter au maximum la localit des donnes lors dchantillonnage des textures.
Les fragments traits passent dans lunit suivante que nous dsignons comme unit de post-traitement
qui correspond dans la gure 3.18 au bloc Raster opration et qui regroupe tout un tas de fonctions utiles.
Parmi elles, nous trouvons, selon les capacits de notre GPU cible, le fusionnement (appel blending
avec les valeurs du framebuffer), application dune transformation xe sur les valeurs de la couleur, les
oprations du masque, les tests sur les valeurs, la convolution, la fonction stencil de masquage condition-
nel, suppression des fragments selon la valeur de leur profondeur, accumulation des valeurs. Pour plus
dinformation, nous renvoyons le lecteur la littrature
Gra03, WNDS99
.
Le ux des pixels qui sortent de ce bloc est crit continuellement dans le framebuffer. Le framebuffer
a aujourdhui de larges possibilit qui ne se restreignent pas seulement un vidobuffer. En effet, il est
possible dy connecter diverses zones de mmoire dun GPU et obtenir ainsi la sortie des rsultats qui
est congurable par lutilisateur lors de lexcution du programme dans les GPP.
Pour conclure, nous devrions noter que lvolution de la structure du pipeline graphique est constante.
Il est fort probable que les fonctionnalits dont nous disposons prsent seront largies, comme ctait
dj le cas plusieurs reprises. Par exemple, avant 2004, nous navions pas encore la possibilit dac-
cder aux textures partir des Vertex programmes. En mme temps, le schma de blocs que nous avons
prsent sur la g. 3.18, page 52, est assez gnral et devrait tre valable dans sa forme encore un certain
temps. Cette remarque est due au fait que la recherche et le dveloppement dans ce domaine sont trs
intensifs et nous pouvons nous attendre des changements plus ou moins importants. Comme exemple
dune implmentation non standard du schma classique du pipeline graphique, nous pouvons citer lar-
chitecture ATTILA
MGR
+
05a, MGR
+
05b
dans laquelle les units de traitement des vertex et des fragments
sont runies dans des blocs fonctionnels universels et programmables. Cette architecture distribue les
moyens matriels pour le calcul en stream selon lintensit du traitement dans un bloc ou lautre et donne
aux units universelles soit la fonction dun vertex processeur, soit dun fragment processeur. Il sagit
dune architecture tout--fait intressante pour notre traitement dans lequel nous utilisons largement plus
les units des fragments que celles des vertex et o il serait avantageux de disposer de maximum de
moyens matriels ddis au traitement des fragments, mme temporairement, pour ainsi obtenir une
paralllisation encore plus forte du traitement en ux.
3.4.5.4 Interfaces de programmation des GPP - DirectX et (Open)GL
Il faut disposer doutils qui permettent aux programmeurs des applications sur les GPP de facilement
utiliser les fonctionnalits matrielles des GPU. Deux groupes des API sont actuellement disponibles. Le
premier groupe est constitu par DirectX de Microsoft. Le deuxime groupe est constitu par OpenGL
de Silicon Graphics Incorporated et par dautres dont la syntaxe et les fonctionnalits sont trs proches
dOpenGL et dont nous pouvons citer Mesa ou lAPI OpenGL ES destin pour les systmes embarqus.
Les deux offrent une interface qui permet de manier les GPU mais elles diffrent dans la philosophie
54
de leur construction. Tandis que DirectX est li aux technologies de Microsoft, OpenGL est modulable
par extensions o chaque fabricant des architectures de traitement 3D peut exposer les fonctionnalits
de son matriel par une extension propritaire. La standardisation de la structure de base du OpenGL
est effectue par OpenGL Architectural Review Board, ARB, qui regroupe les quipes issues de grands
fabricants de solutions pour le graphisme. Les extensions du standard OpenGL qui ont t approuves par
ARB mais qui ntaient pas, pour diffrentes raisons, incluses au standard sont appeles ARB Extensions
et exportent le plus souvent linterface des fonctionnalits des GPU les plus rcents.
Les solutions logiciels bases sur OpenGL (ou Mesa) ont un grand avantage par rapport au DirectX
cest leur facilit de portage vers une plateforme de systme dexploitation diffrente. Nous avons uti-
lis pour nos expriences les deux plateformes pour nalement migrer totalement vers Mesa car nous
voulions garder la portabilit de nos solutions et effectuer des tests comparatifs pour des systmes dex-
ploitation diffrents (Windows XP et une distribution de Linux).
Un autre avantage dOpenGL pourrait galement tre mentionn. Cest le fait que la plupart des
langages de script (e.g. Python, Haskell) ont la possibilit de programmation des GPU via une biblio-
thque compatible avec OpenGL mme si les fonctions quils offrent nincluent pas toujours les ARB
Extension dont nous aurions besoin pour notre travail. Pour plus de dtails sur ces interfaces, nous ren-
voyons le lecteur la littrature traitant dOpenGL
WNDS99, HAL04, Dal03, KBR03
et la littrature traitant de
DirectX
Gra03, Mig04
.
3.4.5.5 Langages dombrage pour le temps rel - Cg, GLSL, HLSL
Comme les processeurs graphiques ont volu partir des pipelines xes ou congurables vers les
pipelines programmables, les langages de haut niveau destins aux blocs programmables lintrieur
dun GPU ont fait leur apparition. On les appelle les langages dombrage pour le temps rel (angl.
Shading languages), avec une spcication du temps rel dans leur nom pour les distinguer des langages
dombrage (classiques) destins au rendu des images et des scnes complexes et o lexigence du temps
rel ne gure pas (e.g. RenderMan de Pixar Animation Studios). Leur nom ombrage (angl. shaders) est
driv du fait que le traitement des vertex et des fragments est utilis pour le calcul des ombres ou de
lillumination locale dans la synthse des images.
Le premier des langages dombrage pour le temps rel que nous mentionnons est nomm Cg
FK03
. Son
nom est une abrviation de C for graphics et il sagit dun langage dvelopp par NVidia. Il sincorpore
travers des bibliothques fournies par le fabricant dans les deux API prsents. Ainsi, nous pouvons
lutiliser avec le DirectX et aussi avec OpenGL. Le deuxime langage dombrage est nomm HLSL
(High Level Shading Language) de Microsoft et vient de complter DirectX. Le troisime est nomm
GLSL (OpenGL Shading Language) et complte OpenGL via les ARB Extensions.
Tous les trois sont largement inspirs du langage C, dont ils ont la syntaxe, mais ils ont dni leurs
propres types et identicateurs qui retent les types utiliss dans le traitement sur les GPU. Ainsi,
il nest pas difcile pour un programmeur connaissant le langage C dadopter ces langages. Pour une
comparaison des fonctionnalits de ces trois langages, nous renvoyons le lecteur un article
Lov05
.
Ces langages nous servent comme base pour le traitement lintrieur du GPU. La grande partie de
lalgorithme de traitement dimages sur les GPU est implmente par ces langages car cest le GPU qui
assure lexcution tant que le programme dapplication, excut dans le GPP, ne fait que coordonner le
travail du GPU, assure lenvoi des commandes graphiques et se charge de la lecture des rsultats.
3.4.6 Calcul sur les ux de donnes avec les GPU
3.4.6.1 GPGPU
Notre manire de travailler entre dans la catgorie du calcul gnral sur les processeurs graphiques
qui sest diffrencie du calcul classique de rendu dimages 3D et constitue aujourdhui une branche
55
parmi les utilisateurs des GPU. Elle est reprsente par une communaut scientique grandissante appe-
le GPGPU
GPG
, ce qui est une abrviation du terme anglais General Processing on Graphics Processing
Units.
Le calcul gnral sur les processeurs graphiques a certaines proprits intressantes. Il se prsente
dun ct par luniformit du calcul, propre au paradigme stream, qui le relie avec dautres architectures
ux de donnes. Dun autre ct, il prsente la proprit du paralllisme spatial qui le distancie des
architectures classiques ux de donnes et qui le valorise par rapport ces dernires. Le paralllisme
spatial est bien incorpor dans larchitecture du pipeline graphique car la notion de la position est prsente
dans les deux structures de donnes principales des GPU qui sont traites en ux vertex et fragments.
Ainsi, les kernels de traitement du ux ont implicitement disposition la notion de la position, ce qui fait
des vertex et des fragments des tokens tout--fait intressants pour le traitement de plusieurs dimensions
et plus particulirement pour le traitement des images dans notre cas.
Le traitement gnral sur les architectures spcialises pour le graphisme nest pas une ide nou-
velle
1
. Diverses architectures ont t proposes et construites, commenant probablement en 1978 par
Ikonas
Eng78
et continuant progressivement jusqu nos jours. En 1988, Fournier et Fussell ont point
dans leur article
FF88
les avantages mais aussi les dsavantages de lutilisation des GPU pour un calcul
algorithmique, diffrent de celui destin la visualisation. Ils ont modlis le framebuffer par un modle
stream et ont cherch, sur les problmes prcis (le problme de visibilit des facettes et le problme du
calcul des ombres) comment la puissance de ces traitements va augmenter si on ajoutait ce modle
plus de capacits de calcul. Larrive des processeurs graphiques programmables a largement chang le
point de vue sur les GPU : ceci se rete dans leur utilisation de plus en plus frquente pour les tches
dun calcul massif. De nos jours, on essaie dexploiter les capacits particulires concernant surtout la
bande passante large entre le processeur graphique et sa mmoire ddie (graphique) mais galement
dexploiter les possibilits du calcul en virgule ottante. Un excellent article
OLG
+
05
analyse la bibliogra-
phie des ralisations scientiques sur les processeurs graphiques faites jusqu lanne 2005. Dautres
articles
CDPS03, GWH05, TC05
prsentent une introduction la problmatique du traitement gnral sur les
GPU.
Un projet logiciel intressant appel Brook
BFH
+
04a, BFH
+
04b
ddi au calcul stream sur les GPU qui
explore leurs capacits dvaluation massive en virgule ottante a t conu par lquipe scientique de
luniversit de Stanford. Il propose un langage spcialis qui largit la syntaxe du langage C et introduit
de nouvelles structures pour les streams et les kernels. Ainsi, il permet de traiter les donns en ux sans
que son utilisateur nait besoin de connatre limplmentation exacte de son programme dans les termes
de la programmation dune application de graphisme 3D laide dun API et dun langage dombrage
quelconque. Cest, en effet, le travail de compilateur brcc du Brook qui traduit le code travaillant avec
les streams en un code dapplication 3D qui inclut les dnitions des shaders appropris au traitement.
Lenvironnement dexcution run-time brt du Brook se charge ensuite de la conguration du pipeline
graphique pour ce traitement, de lenvoi des donnes dans les GPU, de lapplication des programmes
appropris sur ces donnes et de la rcupration des rsultats.
Le grand dsavantage de Brook pour notre travail en morphologie mathmatique est le fait quil
nintgre pas encore le traitement stream avec les types de nombres entiers et quil nimplmente quun
certain nombre doprations de base sur les streams. Le manque de types entiers est d au fait que les
GPU ont t conus prioritairement pour le calcul en virgule ottante et que Brook ne fait quexploiter
les capacits de cette orientation particulire. Ce nest pas le fait dutiliser les types oating point de 32
bits pour effectuer les valuations qui dfavorise cette approche pour le calcul morphologique, mais le
cot des transferts de nos donnes codes dans ces types vers et depuis le GPU. Sachant que ce nest pas
la puissance des GPU dans le calcul en virgule ottante que nous utilisons mais la largeur de la bande
passante la mmoire des donnes qui surpasse celle des CPU classiques qui nous intresse le plus. Dans
ce cas, il serait plus intressant davoir dans Brook la possibilit de travailler aussi avec les types integer
de 8 bits ce qui nest pas, pour linstant, le cas.
1
Pour plus dinformations historiques, nous renvoyons le lecteur aux articles
HCSL02, Ven03
56
Addition des lments correspondant de 2 streams utilisant Brook
taille des streams = 1000, type des donnes = oat 32 bit
Matriel
Avec transfert Sans transfert
GPPGPU (uniquement calcul)
temps taux temps taux
ms dacclration ms dacclration
GPP 0.75 1.0 0.73 1.0
GPU OpenGL 0.19 3.9 0.09 8.1
GPU DirectX9 0.19 3.9 0.09 8.1
GPP = Intel Pentium 4 2.4 GHz single thread ; GPU = NVidia GeForce 6800 LE sur AGP4x.
Excut en 5 sries de 1000 itrations, le temps prsent est le temps moyen pour 1 itration de la
srie la plus favorable.
TAB. 3.3 : Rsultats exprimentaux de lopration addition sur les streams utilisant Brook pour lexcution
dans le GPU
Pour illustrer ce point, regardons la tab. 3.3 o nous prsentons les rsultats dexprimentation avec
Brook. Lopration effectue est une simple addition de deux vecteurs de 1000 lments dont le type est
oat de 32 bits. Les temps qui sont prsents dans ce tableau sont intressants pour un calcul en virgule
ottante car ici, nous obtenons un facteur dacclration 3.9 si nous comparons lexcution sur le GPU
NVidia GeForce 6800 LE avec lexcution plus lente sur le GPP Intel Pentium 4 2.4 GHz, single thread.
Il est, en effet, possible dutiliser Brook pour le calcul morphologique en adoptant son style de travail
et les outils de dveloppement. Mais il faut noter que pour pouvoir obtenir des temps dexcution encore
plus avantageux et notamment dans les algorithmes de la morphologie mathmatique qui travaillent avec
les nombres entiers, il faut effectuer un travail diffrent de celui que Brook nous propose. Malgr cela,
Brook reste un outil de dveloppement intressant pour le traitement en stream et spcialement si nous
voulons tre abstraits de larchitecture particulire des GPU.
3.4.6.2 Calcul de la synthse des images pour la morphologique mathmatique sur les GPU
Le traitement morphologique des images 2D que nous voulons effectuer avec le pipeline graphique
sur les GPU nous dicte prcisment quel modle mathmatique nous allons utiliser. Nous nallons pas
utiliser la projection perspective de lespace 3D 2D car elle na pas dutilit pour notre traitement. En
revanche, nous allons utiliser la projection orthogonale qui constitue un des modes standard de traite-
ment sur les GPU. galement, les modles gomtriques que nous emploierons ne seront pas complexes
et nous nous contenterons des listes de certaines primitives gomtriques, notamment point, ligne, rec-
tangle, que nous allons utiliser comme les commandes graphiques pour lancer le calcul sur les zones de
limage.
Ce fait est traduit dans notre traitement par labsence dutilisation explicite des triangles, largement
utiles dans le graphisme 3D. Les triangles sont utiliss, en effet, pour la simplication des rectangles
des formes gomtriques de base o chaque rectangle est exprim par deux triangles non recouvrants.
57
CHAPITRE 4
Formalisme fonctionnel
adopt pour la morphologie mathmatique
4.1 Approche fonctionnelle et imprative
Il existe deux faons principales pour dcrire un algorithme pour une machine qui sont diffrentes
et opposes. La premire consiste en lutilisation des langages fonctionnels, la deuxime en lutilisation
des langages impratifs.
Les langages fonctionnels ont leurs racines dans le Lambda calcul
1
. Le Lambda calcul
BB94, Wik05b
est un modle du calcul, une formalisation de la notion du calcul, base sur les fonctions et sur la norma-
lisation dune expression calcule par la rduction et qui a pour but obtenir une forme normale, le rsultat
du calcul. Cest--dire tout ce que lon fait habituellement en mathmatique pour calculer un rsultat en
utilisant une formule donne.
Les langages impratifs se basent sur le changement dtat du programme. Dans ces langages, le pro-
gramme est dcrit comme une squence dinstructions. Les machines du calcul physiquement construites
sont dcrites par un automate ni et par consquent, la squence des instructions pour ces machines est
galement un programme dans un langage impratif (langage machine). Le modle du calcul pour ces
langages est la machine de Turing, cest--dire une machine squentielle.
On doit galement souligner que les deux modles sont quivalents et on les appelle Turing-quivalents
car ctait Turing qui a prouv
Tur37
que les deux modles dsignent la mme classe des fonctions cal-
culables. On peut simuler la normalisation des termes lambda par la machine de Turing. Mais on peut
simuler galement la machine de Turing par les termes lambda. Et comme il est dit dans la thse de
Church-Turing
Wik05d
, tout algorithme peut tre calcul par une machine de Turing, donc par quivalence
tout algorithme peut tre calcul par le Lambda calcul.
Nous introduisons le formalisme fonctionnel dans cette thse pour pouvoir tre abstrait dans la des-
cription des algorithmes. En dcrivant seulement les fonctionnalits, nous ne sommes pas obligs de
nous restreindre un type darchitecture donne et dutiliser un langage impratif quelconque. Larticle
intitul Can programming be liberated from von Neumann style
Bac77
discute cette problmatique en d-
montrant les points ngatifs de lapproche imprative la programmation et propose comme solution la
programmation algbraque reprsente par lapproche fonctionnelle la programmation.
Le Lambda calcul dans sa forme thorique est peu utilis dans la pratique o lon prfre travailler
avec un des langages drivs du Lambda calcul un des langages fonctionnels. Les langages fonction-
nels
2
implmentent le Lambda calcul. Ce sont les langages de programmation de haut niveau qui nuti-
1
Souvent crit en utilisant le caractre grec comme -calcul. Nous nutilisons pas cette notation.
2
Comme langages fonctionnels nous pouvons citer Miranda et Haskell ou mme LISP et ML, les deux derniers considrs
comme fonctionnels impratifs car permettant dexprimer aussi les constructions impratives
59
lisent pas la machine dtat pour dcrire un programme comme cest le cas chez les langages impratifs
1
mais ils prfrent exprimer le programme laide des fonctions qui prennent des paramtres dentre et
qui ne retournent quun paramtre de sortie la fois. Lutilisation des types et des structures de haut ni-
veau est propre ces langages. Ils permettent dexprimer dune faon simple les constructions complexes
qui prendraient plusieurs lignes dans un langage impratif. Ces constructions prennent souvent beaucoup
moins de lignes ou seulement une seule dans un langage fonctionnel. Par exemple, lapplication dune
fonction chaque lment dune liste prend une ligne et utilise la rcursion.
4.2 Haskell et les bases des langages fonctionnels
4.2.1 Syntaxe du Haskell
Nous avons choisi la syntaxe du langage Haskell pour exprimer les algorithmes dans cette thse.
Le nom de ce langage, Haskell, est en honneur de Haskell Brooks Curry
Wik06g
dont les travaux dans la
logique mathmatique servent comme bases aux langages fonctionnels. Il sagit dun langage fonctionnel
qui mane du Lambda calcul, qui est bien dni dans sa version actuelle nomme Haskell98
Jon03
mais
qui est galement bien vivant car les travaux de dnition de son successeur se poursuivent ; il est utilis
avec succs dans la recherche y compris par les membres
2
de Microsoft Research
HMJH05
, par exemple.
Notre choix du Haskell a t le rsultat dune petite recherche que nous avons mene et dont le but
tait de choisir un formalisme satisfaisant un certain nombre de desiderata. Dans notre cas, cest Haskell
qui a content nos exigences par la combinaison des proprits suivantes :
les description implicitement formelle des algorithmes travers Haskell,
la proximit de la notation utilise en mathmatiques o mme les lecteurs non instruits peuvent
facilement comprendre les algorithmes exprims en Haskell,
les capacits larges de modlisation qui sont adaptes nos besoins,
pouvoir vrier la bonne construction dune dnition en utilisant le parser pour lanalyse de
syntaxe,
la possibilit de simulation par lexcution dun programme, ce qui nous permet de vrier le bon
fonctionnement sur les donnes relles.
La combinaison de ces proprits nous a men par la suite lutilisation du Haskell pour notre travail et
pour nos explications.
Pourtant, nous ne sommes pas les seuls de se poser de telles exigeances et de choisir Haskell comme
un outil ; il y a dautres chercheurs qui lutilisent pour la description mathmatique, cf. larticle lectro-
nique intitul Eleven Reasons to use Haskell as a Mathematician
Unk06
.
Le Lambda calcul
BB94
travaille avec deux oprations de base, lapplication et labstraction. Lop-
ration dapplication qui est exprime dans le Lambda calcul par
A E
ou galement par plus court
A E
indique lapplication dun algorithme, peru par A, sur une entre, perue par E. Lapplication dans
Haskell correspond, si elle est explicitement mentionne, la fonction $ utilise comme
A$E
mais nous pouvons aussi employer la notation plus courte, de la mme faon que dans le Lambda calcul.
Cette notation omet la fonction dapplication explicite et est utilise comme :
A E
1
Comme langages impratifs nous pouvons citer Basic, Pascal, C, C++, Java, et dautres.
2
Citons les travaux de Simon Peyton Jones portant sur les utilisations du Haskell dans les technologies de Microsoft
60
Jaromr BRAMBOR 4.2. HASKELL ET LES BASES DES LANGAGES FONCTIONNELS
La deuxime opration de base du Lambda calcul est labstraction. Si M = M[x] est une expression qui
contient x (ou autrement dit dpend de x), puis x.M[x] dsigne la fonction x M[x]. Par exemple,
x.x x dnit la puissance de 2. Dans Haskell, nous avons galement la possibilit de dnir une
fonction par le terme comme :
xx x
Cette expression dnit une nouvelle fonction sur place. Elle peut tre utilise dans les dnitions des
fonctions dans Haskell, comme nous pourrons le voir par la suite, par exemple, dans la dnition de la
fonction $, page 62.
Une des spcialits du Lambda calcul est la faon dexprimer les fonctions de plusieurs arguments
par itration de lapplication
1
et nous parlons ainsi dune succession des applications partielles
Wik06c
.
Ainsi, si f(x, y) dpend de deux arguments x et y, nous pouvons dnir dans le Lambda calcul F
x
=
y.f(x, y) qui ne dpend que de y et F = x.F
x
qui ne dpend que de x et nous obtenons par consquent
(F x)y = F
x
y = f(x, y). Haskell suit cette logique et les fonctions de plusieurs arguments sont dnies
exactement de cette manire mme si la syntaxe du Haskell le cache quelquefois. Par exemple
HPF99
, la
fonction add daddition de deux arguments est dnie dans Haskell comme :
add (x ,) = x+
ce qui est un exemple dune dnition uncurried. Cette dnition est quivalente une dnition curried :
add x = x+
qui correspond
add = x x+
ce qui est une notation propre Haskell mais qui nexprime rien dautre que
add = x x+
La dernire dnition correspond dans la notation du Lambda calcul lexpression x.y.x+y qui peut
tre rcrite comme x.(y.x+y) = x.F
x
en utilisant les fonctions partielles comme dcrit auparavant.
Les fonctions standards curry et uncurry du Haskell sont ddies ce travail.
Avant de passer nos propres dnitions et expressions dans Haskell, nous voudrions introduire
certaines notions de base pour que le lecteur non familier avec Haskell ou avec dautres langages fonc-
tionnels puisse poursuivre notre raisonnement et comprendre la syntaxe et la faon de construire les
algorithmes dcrits par la suite. Pour plus dinformations, nous orientons le lecteur vers une brve
introduction du Haskell98
HPF99
.
La fonction de lidentit polymorphe id est un exemple trivial dune fonction dnie par Haskell.
Elle va nous servir pour expliquer la syntaxe de ce langage :
id ::
id x = x
La premire ligne dnit, par le symbole ::, la signature du type de la fonction id pour ses paramtres et
la valeur de retour. Nous lisons la dnition de gauche droite, dans le sens des ches. Dans ce cas,
il sagit dune fonction qui prend un paramtre dun type polymorphe , et transforme sa valeur en une
autre valeur du mme type .
La deuxime ligne dnit, en utilisant le symbole =, le corps de la fonction. Notons que les langages
bass sur le Lambda calcul dnissent les fonctions comme les rgles de rcriture. En dnissant une
fonction dans Haskell, nous prescrivons, en effet, cette rgle de rcriture. Lexpression gauche de =
qui correspond la signature de la fonction sera rcrite par lexpression droite de =.
Dans ce cas prcis de la fonction iJ, nous avons gauche = la signature de la fonction avec un
paramtre x qui sera rcrite par lexpression droite de =, cest--dire en x sans le changer. Cest la
dnition didentit valable pour les valeurs de nimporte quel type.
1
Il sagit dune ide due M. Schnnkel, appele galement currycation
Wik06c
(du terme anglais currying), selon le nom
de Haskell Brooks Curry qui a galement et indpendamment introduit cette ide
BB94
61
La code source de lidentit polymorphe en Haskell est le suivant :
id :: a -> a
id x = x
Le ct pratique de notre approche rside dans la possibilit de vrier automatiquement la syntaxe et le
fonctionnement des dnitions en utilisant le compilateur GHC
GHC
du Haskell, car toutes les dnitions
sont galement les fonctions dnies dans ce langage.
4.2.2 Fonctions de base du Haskell
Les dnitions des fonctions que nous dcrivons cette place appartiennent la base de la program-
mation fonctionnelle et sont incluses dans Haskell. Vu quelles se trouvent abondamment employes
dans nos prochaines descriptions, nous tenons prsenter au lecteur leurs dnitions exactes.
: est le constructeur dune liste qui travaille avec un lment et une autre liste comme les arguments.
Par exemple, lexpression u : [] dnit la liste [u] avec un seul lment u. Les listes contenant
plusieurs lments peuvent tre construites par lapplications successives de ces constructeurs,
e.g. u : I : t : [] construit la liste [u, I, t].
$ est un oprateur dapplication qui applique une fonction sur un paramtre. Il est utilis dans une
criture dense ou l o lon veut explicitement insister sur lapplication de la fonction sur un
paramtre :
( $ ) :: ( )
| $ = x | (x)
est un inxe de composition, il cre partir de deux fonctions une seule fonction compose :
( ) :: ( ) ( )
| p = x | (p(x) )
\\ est un inxe de diffrence de deux listes, e.g. lexpression [1, 2, 3, 4]\\[2, 4] donne comme rsultat une
liste [1, 3].
++ est un inxe de la concatnation de deux listes, e.g. lexpression [1, 2]++[3, 4] donne comme rsultat
une liste [1, 2, 3, 4].
map applique une fonction chaque lment dune liste. Nous pouvons y percevoir le calcul sur les
streams et faire ainsi un lien avec le kernel dapplication que nous avons dcrit dans 3.4.1.1,
page 45. Sa dnition utilise la rcursion :
map :: ( ) [ ] [ ]
map | [ ] = [ ]
map | (x :x) = | x : (map | x)
foldr1, foldl1 La fonction foldr1 prend les deux derniers lments dune liste et applique sur eux une
fonction. Puis elle applique cette mme fonction entre le rsultat obtenu et le troisime lment
partir de la n de la liste. Et ainsi de suite juqsu ce que tous les lments soit traits. Nous
pouvons y percevoir le calcul sur les streams et faire ainsi un lien avec le kernel de rduction que
nous avons dcrit dans 3.4.1.2, page 45 :
foldr1 :: ( ) [ ]
foldr1 | [ x ] = x
foldr1 | (x :x) = | x ( foldr1 | x)
Une autre fonction, foldl1, travaille semblablement mais elle commence le traitement partir du
dbut de la liste et progresse vers larrire.
62
Jaromr BRAMBOR 4.3. PRIMITIVES DE STOCKAGE ET DE REPRSENTATION DES DONNES
foldr, foldl La fonction foldr est une autre fonction de rduction dun stream. Se diffrenciant de la
prcdente, foldr1, elle utilise une valeur dentre dun autre type que celui du stream. Ainsi, elle
permet deffectuer la rduction sur un stream dune manire plus gnrale. Elle commence par
lapplication de la fonction | sur la valeur dentre et rutilise le rsultat itrativement sur tous les
autres lments de la liste.
foldr :: ( ) [ ]
foldr | z [ ] = z
foldr | z (x :x) = | x ( foldr | z x)
Lutilit de cette fonction est vidente. Un exemple que nous pouvons donner pour illustrer les
cas dutilisation de cette fonction peut tre le calcul dun histogramme o nous voulons obtenir,
partir dune liste des lments triviaux, tels que des numros, une structure plus complexe, tel que
lhistogramme.
La fonction foldl travaille pareillement, mais elle excute la rduction partir de la n de la liste
et progresse vers lavant.
lter retourne la liste avec les lments qui satisfont le critre p. Nous pouvons y percevoir le calcul
sur les streams et faire ainsi un lien avec le kernel de ltrage que nous avons dcrit dans 3.4.1.3,
page 45 :
lter :: ( Bool) [ ] [ ]
lter p [ ] = [ ]
lter p (x :x) | p x = x : lter p x
| otherwise = lter p x
zip cre, partir de deux listes, une liste des tuples o chacun des tuples contient, respectivement, un
lment de la premire liste et un lment de la deuxime, e.g. zip [1, 2, 3] [4, 5, 6] a pour rsultat
[(1, 4), (2, 5), (3, 6)] :
zip :: [ ] [ ] [ (,) ]
zip (x :x) (:) = (x ,) : zip x
zip _ _ = [ ]
fst retourne le premier lment dun tuple :
fst :: (,)
fst (x ,_) = x
snd retourne le deuxime lment dun tuple :
snd :: (,)
snd (_,) =
4.3 Primitives de stockage et de reprsentation des donnes
Nous dnissons de nouveaux types pour le stockage et la reprsentation des donnes en nous ap-
puyant sur les types de base du Haskell. Pour la plupart, nous nallons utiliser que la rednition des
identicateurs des types dj existants an dintroduire au type linformation smantique qui nous ser-
vira tre clair et comprhensible dans les dnitions complexes. Notons que les identicateurs de type
dans Haskell doivent commencer par une lettre majuscule.
Deux mot cls du Haskell sont ddis ce but, data et type. Le mot cl data qui dnit un vritable
nouveau type de donnes, e.g. la dnition
data AB = A | B
dnit le type numratif avec deux identicateurs possibles ^ et B. Le mot cl type dnit un nouvel
identicateur du type en se basant sur les types dj existants ou sur leur combinaison. Par exemple,
lexpression
63
type B = A
dnit un nouvel identicateur B comme tant le mme type que lidenticateur ^. Ou encore, lexpres-
sion
type B = (A, A)
dnit un nouvel identicateur B comme un tuple dont les deux lments sont du type ^.
4.3.1 Types de base
4.3.1.1 Indexation
Les numros entiers seront utiliss pour exprimer les indices lors de lindexation des lments des
arrays ou des listes. Nous pourrions utiliser directement les valeurs dun type de Haskell, Int, mais nous
prfrons rednir son identicateur en une forme plus courte, I, qui va savrer trs utile dans les d-
nitions plus longues.
type I = Int
4.3.1.2 Flux de donnes
La structure prsente dans Haskell et convenable pour le stockage et le travail avec les donnes en
stream (sur les ux de donnes) est celle dune liste. La liste dans Haskell est dnie, en utilisant la
classe list, par le constructeur []. La liste est polymorphe et elle ne peut contenir que des lments du
mme type. Par exemple, lexpression [] dnit une liste vide et lexpression
x = [ x , , z ]
dnit une liste x dont les lments sont des caractres, le premier lment a la valeur x, le deuxime
la valeur et le troisime la valeur z.
Lindexation des lments dans une liste est effectue par !! (double point dexclamation) et com-
mence partir de 0. Ainsi, le premier lment dtient lindex 0, le deuxime 1, etc. Par exemple, lex-
pression
x ! ! 1
rendra la valeur du deuxime lment, cest--dire .
La deuxime manire de construire une liste est celle que nous avons dj mentionne (page 62) et
qui utilise le constructeur : (deux-points). Celui est trs utile lors de la composition des listes partir des
lments, e.g. lexpression
= 1:2:3: [ ]
cre une liste qui est gale [1, 2, 3].
La liste est un type essentiel dans les langages fonctionnels, Haskell inclus. Ainsi, les fonctions sur
les listes sont incorpores dans Prelude, le cur du Haskell. Pour plus de prcision nous renvoyons
le lecteur vers le manuel
Jon03
du langage Haskell. Nous allons utiliser les listes par la suite dans nos
algorithmes pour exprimer explicitement la notion dun stream et pour ordonner des donnes lors dun
traitement en ux.
4.3.1.3 Types de donnes paquetes pour le traitement SIMD
Le traitement des donnes sur une architecture SIMD est un traitement en parallle. Ainsi, il faut
avoir des structures de donnes qui seraient convenables un tel traitement. Pour le traitement stream sur
les processeurs avec les capacits SIMD, nous utilisons des blocs de donnes lmentaires du mme type
regroups dans un type compos qui constitue la base pour notre travail. Nous parlons ainsi des types de
donnes paquetes. Ces types sont appels dans la littrature galement les donnes vectorielles.
64
Jaromr BRAMBOR 4.3. PRIMITIVES DE STOCKAGE ET DE REPRSENTATION DES DONNES
Mme si dans nos traitements nous pouvons rencontrer les vraies donnes vectorielles comme cest le
cas chez les coordonns x, , z, v sur les cartes graphiques, dans la plus grande partie de nos algorithmes,
les donnes que nous traitons ne correspondent pas un vrai vecteur dun point de vue mathmatique
mais plutt des groupes de pixels. Cest la raison pourquoi nous prfrons garder le terme donnes
paquetes pour nos propos car nous pensons que lappellation "paquet" rete mieux la ralit. De
plus, elle correspond un terme que nous trouvons dans la littrature anglaise "packed-vector".
En thorie, nous pouvons choisir une taille arbitraire du type de donnes paquetes, en pratique
nous sommes restreints par le choix de larchitecture nale et par ses capacits. La plupart des architec-
tures contemporaines possdent des types paquets de 4 16 lments (cf. les technologies multimdia,
tab. 1.2, page 21, dans le chapitre Motivation). Sur les architectures spciales et ddies nous pouvons
trouver un nombre plus lev dlments dans un type paquet (de 64 256), e.g. prototype du processeur
dynamiquement recongurable Vision chip
KKI04
ou le systme IMAP-VISION
PJ00
.
Un exemple du type paquet iu8vec8 (notation MorphoMedia
Bra05
) regroupant 8 lments unsigned
integer de 8 bit est prsent sur la g. 4.1. Ainsi, la largeur totale du type paquet iu8vec8 est de 64 bit
et nous pouvons lutiliser pour un travail avec des architectures possdant des instructions multimdia
pour ce type, notamment les processeurs compatibles SHmedia
Bra02
, processeurs compatibles MMX,
les processeurs issus de larchitecture IA-64 dIntel ou les processeurs issus de larchitecture AMD64
dAMD.
iu8
7
iu8
6
iu8
5
iu8
4
iu8
3
iu8
2
iu8
1
iu8
0
63 56 55 48 40 32 24 16 8 0 47 39 31 23 15 7 bit no.
FIG. 4.1 : Structure du type de donnes paquetes iu8vec8 (notation MorphoMedia
Bra05
) qui est compose de
8 lments du type iu8 (integer unsigned 8 bit)
Lexpression de ces types en formalisme fonctionnel est simple. Nous allons utiliser le type du Has-
kell Array, mme si dans Haskell nous avions encore une autre possibilit - les listes. Il nous est plus
naturel dutiliser les arrays, car de leur essence, les types paquets sont les arrays 1D. De plus, lutilisa-
tion des arrays pour lexpression des donnes paquetes nous permet de faire une distinction claire entre
les donnes statiques, exprimes par les arrays, et les donnes dynamiques, exprimes par les listes et
dcrivant les streams lors dun traitement en ux, comme dni dans la section prcdente, cf. 4.3.1.2.
Pour ces raisons, nous dnissons un nouvel identicateur du type, PVec (correspondant au pacekd
vector), en nous basant sur le type Array du Haskell.
type PVec = Array
Pour pouvoir initialiser une variable du type PVec, nous dnissons la fonction pvec qui cre un array
dune dimension partir dune liste des lments. Le premier paramtre correspond aux tuples des bornes
minimales et maximales, respectivement. Le deuxime paramtre est la liste des tuples index-lment,
respectivement. Cette dnition est une spcialisation de la fonction standard du Haskell array pour une
dimension.
pvec :: ( I , I ) [ ( I , ) ] PVec I
pvec i a = array i a
4.3.1.4 Images, arrays, vecteurs
Nous allons utiliser un type interne du Haskell, Array, pour le stockage des donnes matricielles et
tensorielles. Ce type va nous servir au stockage dimages, textures, des arrays 2D ou des vecteurs. Pour
des raisons de clart et de simplicit de comprhension dans les dnitions plus longues, nous allons
dnir pour ce type un nouvel identicateur plus court, Ar.
type Ar = Array
65
Expliquons son utilisation sur quelques exemples des signatures de type pour les array polymorphes de
1 et 2 dimensions. Elles seront employes par la suite dans les dnitions des fonctions maniant ces
structures de donnes :
Ar I array dune dimension, dont les index sont du type I et dont les lements sont du type
polymorphe ,
Ar (I, I) array de deux dimensions, dont les index sont des tuples (I, I) et dont les lements sont
du type polymorphe ,
Ar (I, I) Int array de deux dimensions, dont les index sont des tuples (I, I) et dont les lements
sont du type prcis, entier, Int,
Ar (I, I) (Ar (I, I) ) array de deux dimensions, dont les index sont des tuples (I, I) et dont les
lments sont des arrays de deux dimensions Ar (I, I) .
Ar (I, I) (PVec I ) array de deux dimensions, dont les index sont des tuples (I, I) et dont les
lments sont des arrays paquets PVec I .
4.4 Primitives du calcul comme skeletons algorithmiques
Pour pouvoir exprimer la structure des mthodes du calcul sans exposer les dtails de leurs impl-
mentations, nous allons faire appel aux fonctions du Haskell qui seront dnies pour les types poly-
morphes (, , , etc.) Ces fonctions, entirement gnriques ou partiellement spcialises pour des
types concrets, ont le caractre des primitives du calcul et elles sont destines tre utilises dans les
algorithmes plus complexes.
Vu quelles dnissent formellement le principe de fonctionnement dun algorithme, nous allons les
dsigner par le terme skeletons algorithmiques, en reprenant le terme couramment utilis dans la littra-
ture anglaise traitant ce sujet. Nous gardons expressment le terme anglais skeleton plutt quutiliser ses
traductions franaises possibles squelette, qui peut tre confondu avec les oprations morphologiques
dsignes par le mme mot, ou charpente dont la forme nous semble trop loigne du mot anglais ori-
ginal et o son utilisation ventuelle dans la locution charpente algorithmique ne nous semblerait pas
approprie.
4.4.1 Primitives du calcul squentiel
4.4.1.1 Paradigme pipeline, skeleton pipe
Le skeleton pipe
DFH
+
93
capture la faon squentielle et uniforme de traitement des donnes. Il ef-
fectue une composition chane des fonctions, remises dans une liste comme le paramtre dentre,
une fonction de sortie en utilisant la fonction foldr1 de rduction par application de la fonction de com-
position . Le paralllisme est obtenu par lallocation dun processeur distinct pour chaque fonction.
Remarquons que lors du traitement avec ce skeleton, le type polymorphe de la donne ne change pas au
cours de la progression dans le pipeline, il reste toujours .
pipe :: [ ] ( )
pipe = foldr1( )
P
1
P
2
P
3
P
n
FIG. 4.2 : Skeleton algorithmique pipe
66
Jaromr BRAMBOR 4.4. PRIMITIVES DU CALCUL COMME SKELETONS ALGORITHMIQUES
4.4.2 Primitives du calcul parallle
4.4.2.1 Paradigme de rplication fonctionnelle, skeleton farm
Le skeleton farm
1
exprime la forme la plus simple du paralllisme de donnes. Le calcul sur ces
donnes est peru comme liste des tches. Lors de la ralisation matrielle, plusieurs processeurs sont
utiliss pour lvaluation de ces tches.
Dans notre modle mathmatique, nous procdons lapplication dune fonction | toutes les don-
nes dune liste dentre. Dans la dnition du skeleton farm, nous utilisons lapplication partielle,
cf. 4.2.1, de la fonction map pour laquelle nous spcions son premier argument comme la fonction
| . Ainsi, on dnit une nouvelle fonction du type ([] []) qui opre sur les streams, qui prend un
stream dentre dont les lments sont du type et auxquels nous appliquons la fonction | . Le stream
rsultant de cette nouvelle fonction est du type .
farm :: ( ) ( [ ] [ ] )
farm | = map |
Notons que dun point de vue mathmatique, la dnition de la fonction farm est identique celle
de la fonction map. Ce que nous obtenons en dnissant la fonction farm, cest linformation syntaxique
que nous ajoutons la description de la fonctionnalit et qui nous indique expressment lide de la
paralllisation du calcul. Cette information syntaxique est exploiter lors de la compilation pour une
machine parallle.
La gure 3.9, page 44, prsente dans la section ddie au calcul sur les streams, illustre graphique-
ment limpact de cette information syntaxique sur la manire exacte dexcuter le kernel du calcul par
les architectures traitant des donnes en tant que ux. Nous pouvons y percevoir la diffrence entre le
traitement dun stream en squence par la fonction map (cf. g. 3.9(a)) et le traitement en parallle par
la rplication fonctionnelle qui est exprime par le skeleton farm (cf. g. 3.9(b)).
4.4.2.2 Paradigme Divide and Conquer, skeleton dc
La division de traitement dune grande tche en plusieurs plus petites qui sont traites sparment
est une approche courante sur les architectures parallles. Les rsultats partiels issus de ces petites tches
sont combins et constituent le rsultat de la tche originale. Nous parlons dun paradigme divise et
conquiers
2
(de l angl. divide and conquer). Bien sr, nous pouvons lappliquer seulement si notre pro-
blme est divisible et les parties peuvent tre traites indpendamment les unes des autres, ce qui est le
cas pour la plupart des traitements des donnes perues comme un ux.
Dans une architectures matrielle qui implmente ce paradigme, nous pouvons distinguer trois types
de fonctionnement des units excutives. Ces units peuvent tre ddies leur fonction mais elles
peuvent aussi tre gnrales et toutes les mmes au niveau du matriel en diffrant dans la fonctionnalit
souhaite quelles excutent. Le premier type des units est ddi la division du problme, le deuxime
au calcul sur les donnes et le troisime type est ddi linterprtation dun rsultat global partir des
rsultats partiels. La gure 3.17, page 50, prsente dans la section consacre au calcul stream sur les
architectures SWAR plusieurs ls dexcution, illustre bien le principe de la division dun stream, de
lexcution distribue sur les streams partiels et de la collecte des rsultats an dobtenir un seul stream
rsultant.
Le modle mathmatique
DFH
+
93
de ce paradigme est dcrit par la fonction dc. Ici, les tches triviales
(itiv) sont solutionnes (oIv) directement sur le processeur hte. Les tches plus complexes sont divi-
ses (JvJ) en plusieurs tches plus petites qui passent dans dautres processeurs pour y tre solutionnes
1
Nous nutilisons pas la forme de ce skeleton dcrite dans les articles
DFH
+
93, DGTY95b
de Darlington et al. car elle travaille
avec un paramtre supplmentaire dcrivant lenvironnement. Ce paramtre ne gure pas dans notre dnition mais peut
tre ajout comme application partielle | $anv de la fonction | sur lenvironnement anv.
2
Lexpression franaise correspondant au terme anglais divide and conquer est diviser pour rgner. Vu que notre intrt
dans le calcul mathmatique nest pas de rgner mais de conqurir les rsultats partir des units distribues, nous
prfrons utiliser la traduction libre divise et conquiers
67
(oIv) rcursivement. Les rsultats de ces tches divises sont combins (tmI) pour obtenir le rsultat
global.
dc :: ( Bool) ( ) ( [ ] ) ( [ ] )
dc itiv oIv JvJ tmI x
| itiv x = oIv x
| not( itiv x) = tmI (map$ (dc itiv oIv JvJ tmI) ) JvJ $ x
4.4.3 Paquetage et dpaquetage des arrays pour le traitement SIMD
Nous appelons paquetage dun array 1D la transformation dun array 1D en un autre array 1D dont
les lments sont les vecteurs paquets (PVec). Dans la littrature on parle aussi de vectorisation des
donnes (drive dun terme anglais vectorize).
4.4.3.1 Paquetage dun array 1D
La transformation de paquetage est triviale dans le cas dun array 1D o lon na quun seul axe
vectoriser et le procd est ainsi trs simple et direct. Malgr cela, nous tenons dcrire ici cette opration
par lapproche fonctionnelle, car nous pouvons ainsi dmontrer, sur un exemple trivial, la construction,
lindexation et le travail avec les arrays dans Haskell.
La fonction mkAr1DPVec dnit cette transformation :
mkAr1DPVec :: I Ar I Ar I ( PVec I )
mkAr1DPVec n ut = array InJnav
[ ( i , pvec (1,n) [ (I,ut ! ( Io+( i Io) n+(I1))) | I [ 1.. n] ]
) | i range InJnav]
where
( Io, Ii ) = bounds $ut
InJnav= ( Io, Io1+(div ( IiIo+1) n) )
Elle prend deux paramtres. Le premier, n, dnit le nombre dlments qui seront paquets dans les
lments PVec de larray de sortie. Le deuxime paramtre ut est larray dentre, remarquons que sa
taille doit tre divisible par n. La manire de dcoupage de larray dentre est illustr sur la g. 4.3
lo lo+2n lo+n hi
FIG. 4.3 : Dcoupage dun array lors de sa transformation un array paquet, nombre dlments dans un
lment paquet n = 2
4.4.3.2 Paquetage dun array 2D
Le passage dun array de 2D ou de plusieurs dimensions un array de la mme dimension com-
pos de vecteurs paquets PVec ncessite le choix de laxe principal pour la vectorisation. Le choix
simple est prdni par la manire dont les donnes sont stockes dans la mmoire. Sur les processeurs
GPP/GPPMM, toutes les donnes, y compris les structures nD, sont stockes dans un espace linaire 1D
et accdes ainsi. Laccs par les instructions SIMD que nous utilisons sur les architectures GPPMM
pour la lecture et la sauvegarde des donnes nen fait pas exception. Si nous souhaitons utiliser ces ins-
tructions dans nos algorithmes, nous sommes contraints dans notre choix de laxe de vectorisation de nos
donnes par le sens de leur stockage dans la mmoire.
En revanche, si nous souhaitons paqueter les donnes dun array dans laxe perpendiculaire celui
de la mmoire, notre travail exige une autre approche car nous ne pouvons pas accder ces donnes
directement par les instructions SIMD. Nous sommes obligs dutiliser soit la lecture lment par l-
ment, soit une autre approche qui nous permettrait dinterprter correctement les donnes lues dans un
68
f
s
t
snd
(a) array 2D avant
dcoupage
f
s
t
snd
(b) dcoupage par la
direction de la premire
coordonne (fst)
f
s
t
snd
(c) dcoupage par la
direction de la deuxime
coordonne (snd)
FIG. 4.4 : Exemple de vectorisation dun array 2D pour diffrentes versions de dcoupage et la taille du vecteur
paquet n = 2
sens diffrent. Nous montrerons les algorithmes implmentant cette approche dans le chapitre 6 ddi
la permutation des arrays, page 127.
Nous allons prsenter deux possibilits de vectorisation dun array 2D : le paquetage par laxe de
la premire coordonne dni par la fonction mkAr2DPVecByFst et le paquetage dual par laxe de la
deuxime coordonne par la fonction mkAr2DPVecBySnd. Pour prsenter une dnition gnrique et
indpendante dun systme de coordonnes dans limage, nous ne parlons pas des coordonnes x ou
dune image mais nous utilisons la notation matricielle et parlons des coordonnes premire et deuxime,
exprimes par les sufxes Fst ou Snd respectivement.
Dun point de vue pratique, ces dnitions ne correspondent pas un algorithme concret. Il sagit,
en effet, de la formalisation du changement de la perception des donnes stockes dans la mmoire et du
changement de leur mode dadressage. On peut dire que ces dnitions correspondent au changement
du type des donnes partir dun array du type Ar (I, I) un array du type Ar (I, I) (PVec I ) dont
les lments sont les vecteurs paquets, exactement comme cest inscrit dans la signature de type de ces
fonctions.
La fonction mkAr2DPVecByFst dnit la vectorisation par laxe de la premire coordonne et la
manire dont larray est dcoup en donnes paquetes est illustre sur la g. 4.4(b)
mkAr2DPVecByFst :: I Ar ( I , I ) Ar ( I , I ) ( PVec I )
mkAr2DPVecByFst n ut = array InJnav
[ ( ( i , j ) , pvec (1,n) [ (I,ut ! ( |Io +( i |Io) n+(I1),j ) ) | I [ 1.. n] ]
) | ( i , j ) range InJnav]
where
( ( |Io , Io) , ( |Ii , Ii ) ) = bounds $ut
InJnav= ( ( |Io , Io) , ( |Io1+(div ( |Ii |Io+1) n) , Ii ) )
Cette fonction cre un nouvel array par la fonction array. Cet array a une dimension rduite dans laxe
de paquetage. Les lments de cet array sont les vecteurs paquets PVec, crs par la fonction pvec. La
fonction bounds est utilise pour obtenir les limites de larray dentre ut. La variable InJnav dtient
les nouvelles limites de larray de sortie.
La fonction similaire, mkAr2DPVecBySnd, dnit la vectorisation par laxe de la deuxime coor-
donne et la manire de dcouper est illustre sur la g. 4.4(c)
mkAr2DPVecBySnd :: I Ar ( I , I ) Ar ( I , I ) ( PVec I )
mkAr2DPVecBySnd n ut = array InJnav
[ ( ( i , j ) , pvec (1,n) [ (I,ut ! ( i , Io+( j Io) n+(I1))) | I [ 1.. n] ]
) | ( i , j ) range InJnav]
where
( ( |Io , Io) , ( |Ii , Ii ) ) = bounds $ut
InJnav= ( ( |Io , Io) , ( |Ii , Io1+(div ( IiIo+1) n) ) )
69
Nous dnissons galement une fonction commune, mkAr2DPVec qui prend un paramtre de plus
qui nous sert comme cl dans le choix de soit la fonction mkAr2DPVecByFst ou mkAr2DPVecBySnd :
mkAr2DPVec :: [ Char] I Ar ( I , I ) Ar ( I , I ) ( PVec I )
mkAr2DPVec Iov n ut | Iov == "Fst" = mkAr2DPVecByFst n ut
| Iov == "Snd" = mkAr2DPVecBySnd n ut
4.4.3.3 Dpaquetage des arrays
Nous appelons le dpaquetage dun array le processus dobtention dun array compos des lments
de base partir dun array dont les lments sont des vecteurs paquets. Il est possible de dnir les
fonctions de dpaquetage qui auront des fonctionnalits inverses celles que lon vient de dnir pour
le paquetage. Leurs dnitions sont intelligibles et nous ne prsentons que leurs identicateurs et les
signatures de type.
La fonction mkAr1DFromAr1DPVec dnit la fonction de dpaquetage pour un array 1D et sa si-
gnature de type est la suivante :
mkAr1DFromAr1DPVec:: Ar I ( PVec I ) Ar I
Les fonctions mkAr2DFromAr2DPVecByFst et mkAr2DFromAr2DPVecBySnd dnissent le dpa-
quetage dun array 2D dans le sens de la premire/deuxime coordonne, respectivement. La fonction
mkAr2DFromAr2DPVec les englobe dans une seule qui choisit entre la premire/deuxime fonction se-
lon la valeur correspondante | ou SnJ de son premier paramtre textuel (donne par [Char]). Voici
leurs signatures de type :
mkAr2DFromAr2DPVecByFst :: Ar ( I , I ) ( PVec I ) Ar ( I , I )
mkAr2DFromAr2DPVecBySnd :: Ar ( I , I ) ( PVec I ) Ar ( I , I )
mkAr2DFromAr2DPVec :: [ Char] Ar ( I , I ) ( PVec I ) Ar ( I , I )
4.4.4 Sens du parcours, passage dun array un ux de donnes et vice versa
4.4.4.1 Notion du sens du parcours et de lextraction des lments
Le passage dune structure statique de donnes tel quun vecteur ou array 2D une structure utilise
dynamiquement pour le traitement en ux ncessite le choix du sens de parcours.
Pour nos besoins, nous allons comprendre sous le terme parcours dun array une squence des index
qui dsignent les lments dun array. Nous parlons ainsi dun stream des index et ce stream peut, gn-
ralement, ne dsigner quun sous-ensemble des lments de cet array. Si les index de ce stream dsignent
tous les lments dun array, nous parlons dun parcours complet dun array.
Une fois le parcours dni, le passage dun array un ux de donnes sera obtenu par lapplication
de lopration indexation des lments, exprime par la fonction ! du Haskell, sur le stream des index.
cette occasion, nous allons parler dextraction des lments ou galement dchantillonnage dun array.
Ainsi peru, laccs la mmoire qui est ncessaire pour lobtention des lments dun array est
excut en tant quopration sur le stream et la fonction ! dchantillonnage de limage devient, en effet,
le kernel du calcul sur les ux de donnes. Nous pouvons le dcrire dans le formalisme fonctionnel par
lexpression suivante :
(map (ut ! ) ) $ (tm ut )
o ut est larray dentre, tm dsigne la fonction de parcours qui cre un stream des index partir
de larray ut. Elle est suivie par lapplication de la fonction map sur ce stream qui se charge dexcuter
lindexation de larray ut! sur chacun des index de ce stream. La gure 4.5 illustre cette situation. Le
parcours de limage y est reprsent par le bloc de la fonction gnratrice des index qui est succd par
le bloc dextraction des lments de la mmoire.
Cette modlisation mathmatique que nous introduisons ici et qui peroit laccs la mmoire
comme opration sur les streams est trs intressante dun point de vue pratique. En tant quopration
70
Array
Fonction gnratrice
de la squence
des indexes
Fonction dextraction
des lments
de la mmoire
Flux dindexes
dfinissant
le parcours de limage
Flux de donnes
FIG. 4.5 : Passage dun array un ux de donnes est effectu dans la logique des kernels dexcution
sur les streams, elle peut proter de toutes les techniques de paralllisation de traitement des streams,
notamment de celle de la rplication fonctionnelle modlise par le skeleton farm, cf. page 67. Laccs
concurrent la mmoire est difcile imaginer sur les architectures classiques de Von Neumann, mais
cest une technique connue et utilise sur les machines parallles ou des architectures ddies.
Cest cette approche de parcours de larray et dextraction des lments que nous allons utiliser pour
le passage dun array un ux de donnes. Cependant, les fonctions de parcours de limage vont nous
servir galement lors de la recomposition dun array de sortie partir dun ux de donnes. Il sagit, en
effet, du processus inverse au passage ux de donnes et pour lexprimer en formalisme fonctionnel,
nous allons utiliser la fonction standard array du Haskell de cration dun array.
La fonction array prend deux arguments. Le premier argument est un tuple des bornes minimales et
maximales des index. Nous reconstituons un array de sortie partir dun array dentre qui a les mmes
bornes maximales et minimales. Nous pouvons utiliser directement la fonction du Haskell qui fournit
ces informations, bounds avec larray dentre comme paramtre. Le deuxime argument de la fonction
array est une liste des tuples (index, valeur) qui doit contenir tous les lments inclus dans les bornes.
Nous construisons cette liste partir de notre stream des rsultat et partir du stream des index, le mme
que nous avons utilis pour parcourir larray. Nous les associons lment par lment avec la fonction
zip du Haskell.
Voici un exemple de cette construction :
array (bounds $ut ) ( zip ix ( id ) )
whereix = tm ut ; = map (ut ! ) ix
o ut dsigne larray dentre, ix est le stream des index cr par la fonction tm du parcours de
larray et est le stream des valeurs des rsultats. La fonction didentit id nous indique lendroit o
nous plaons des fonctions excutives effectuant un traitement sur le stream des valeurs.
4.4.4.2 Fonction indices, fonction standard du Haskell pour le parcours dun array
Dans le cas o nous avons besoin de parcourir larray entier mais sans poser de contrainte sur le
sens du parcours, nous pouvons utiliser la fonction standard indices du Haskell. Elle nous retourne des
indices de tous les lments de larray par lindexage de ses bornes.
Sachant que nous avons utilis une fonction standard pour le passage un ux de donnes, nous
pouvons utiliser un mcanisme plus simple pour la recomposition de larray de sortie en utilisant la
fonction listArray du Haskell. Cette dernire nexige pas lassociation des lments du ux des rsultat
avec lindex mais travaille directement avec ce stream. Lexemple suivant illustre cette situation :
listArray (bounds $ut ) ( id )
whereix = indices ut ; = map (ut ! ) ix
71
4.4.4.3 Fonctions de parcours dun array
Commenons notre explication par lintroduction de la fonction concrte de parcours dun array 1D.
La fonction streamAr1D dnit un skeleton algorithmique qui cre un stream des index partir dun
array 1D. La valeur passe par son paramtre Iov dtermine le sens du parcours que nous voulons
obtenir, la valeur FW correspond au sens au-devant, la valeur BW correspond au sens en arrire. La
g. 4.6 illustre ces deux cas sur un vecteur de la taille 3.
streamAr1D :: [ Char] Ar I [ I ]
streamAr1D Iov ut
| Iov == "FW" = [ ( Io+i ) | i [ 0.. iza1]]
| Iov == "BW"= [ ( Iii) | i [ 0.. iza1]]
where
( Io, Ii ) = bounds $ut ; iza = rangeSize(Io,Ii)
1,2 1,1 1,3 (1,1) (1,2) (1,3)
(a) sens au-devant, streamAr1D avec "FW"
1,2 1,1 1,3 (1,1) (1,2) (1,3)
(b) sens en arrire, streamAr1D avec "BW"
FIG. 4.6 : Choix du parcours de limage pour un array de 1D
Tandis que pour les structures 1D le choix du sens de parcours est simple et nous utilisons soit
le parcours au-devant, soit le parcours en arrire, pour les structures 2D nous avons beaucoup plus de
possibilits et nous dcrivons celles qui sont utilises le plus souvent. Il nest pas difcile, en cas de
besoin, den dnir davantage qui seraient appropries un traitement particulier.
Mais tout dabord, nous dnissons un type Streamize que nous allons utiliser pour dsigner une
fonction de parcours dun array de 2D dans les signatures de types de nos algorithmes :
type Streamize = Ar ( I , I ) [ ( I , I ) ]
Il sagit des fonctions qui prennent un array 2D comme argument et qui nous retournent un stream des
index.
Nous dnissons un skeleton pour la cration dun stream des index partir dun array 2D par la
fonction streamAr2D qui dnit les parcours bien connus dune image en sens vido et en sens anti-
vido.
streamAr2D :: [ Char] Ar ( I , I ) [ ( I , I ) ]
streamAr2D Iov ut
| Iov == "FWFst" = [ ( |Io +i , Io+j ) | j [ 0.. mux] , i [ 0.. |mux] ]
| Iov == "FWSnd" = [ ( |Io +i , Io+j ) | i [ 0.. |mux] , j [ 0.. mux] ]
| Iov == "BWFst" = [ ( |Ii i,Iij) | j [ 0.. mux] , i [ 0.. |mux] ]
| Iov == "BWSnd" = [ ( |Ii i,Iij) | i [ 0.. |mux] , j [ 0.. mux] ]
where
( ( |Io , Io) , ( |Ii , Ii ) ) = bounds $ut ;
|mux = rangeSize(|Io,|Ii)1
mux = rangeSize(Io,Ii)1
Le type du parcours exact est dtermin par la valeur du paramtre Iov de cette fonction et corres-
pond pour les valeurs FWFst / FWSnd aux sens au-devant par la premire / deuxime coordonne,
et pour les valeurs et BWFst / BWSnd aux sens en arrire par la premire / deuxime coordonne,
respectivement.
Notons que lapplication partielle de cette fonction avec la paramtre Iov concret, e.g. :
(streamAr2D$"FWFst")
72
nous dnit dans Haskell une nouvelle fonction qui est du type Streamize et qui est ainsi directement
utilisable dans les algorithmes comme une fonction du parcours dun array.
La gure 4.7 illustre le fonctionnement de ce skeleton pour un array 2D 3x3.
2,3
1,2
2,1 2,2
3,3
1,1 1,3
3,1 3,2
(1,1) (1,2) (1,3) (2,3) (2,1) (2,2) (3,3) (3,1) (3,2)
(a) sens au-devant par la premire coordonne,
streamAr2D avec FWFst
2,3
1,2
2,1 2,2
3,3
1,1 1,3
3,1 3,2
(1,1) (1,2) (1,3) (2,3) (2,1) (2,2) (3,3) (3,1) (3,2)
(b) sens au-devant par la deuxime coordonne,
streamAr2D avec FWSnd
2,3
1,2
2,1 2,2
3,3
1,1 1,3
3,1 3,2
(1,1) (1,2) (1,3) (2,3) (2,1) (2,2) (3,3) (3,1) (3,2)
(c) sens en arrire par la premire coordonne, streamAr2D
avec BWFst
2,3
1,2
2,1 2,2
3,3
1,1 1,3
3,1 3,2
(1,1) (1,2) (1,3) (2,3) (2,1) (2,2) (3,3) (3,1) (3,2)
(d) sens en arrire par la deuxime coordonne,
streamAr2D avec BWSnd
FIG. 4.7 : Choix du parcours de limage pour un array de 2D 3 3
4.4.5 Concept des "superpixels"
Dans certains de nos algorithmes, nous allons travailler avec un groupe de pixels et avec les pixels
voisins de ce groupe, plutt que de travailler avec un seul pixel et son voisinage. Il serait donc convenable
de dcrire cette place la manire dont on va travailler avec un tel groupe et de donner les bases formelles
ce travail.
Lide de travailler avec des groupes de pixels et des pixels voisins de ce groupe est propre toutes
les implmentations sur les architectures parallles o on procde la division de limage et on effectue
le traitement de ces parties par la distribution sur diffrents processeurs. Cette ide est explore par
Jin Yang qui utilise, q.v. page 57 de sa thse
Yan97
doctorale, les bords partags (galement appels les
halos) qui sont ajouts aux arrays parallles ou aux graphes. Notons que ces bords partags ont dans la
morphologie mathmatique un sens plus large que celui du voisinage proche sur une grille donne car ils
doivent reter le travail avec des lments structurants dans leur forme gnrale et souvent dune taille
importante, pas ncessairement celle qui dnit le voisinage de taille 1.
Dun point de vue formel, cest le travail sur le voisinage qui nous empche dexprimer un tel groupe
de pixels par un array dcoup rgulirement sur les vecteurs paquets ou sur les macro blocs car dans la
perception des arrays comme nous la dcrivons par le formalisme fonctionnel, les voisins dune donne
qui est du type sont les donnes du mme type. Par exemple, le voisinage dun macro bloc concret est
constitu dun ou plusieurs macro blocs voisins.
Ceci ne correspond pas la philosophie de travail que nous voulons employer pour les groupes de
pixels dont le voisinage (proche ou dans le sens large) est constitu galement des pixels et non des
groupes de pixels. Vu que lutilisation de ces groupes de pixels dans les fonctions et la faon de travailler
avec leurs pixels voisins sont semblables celles que nous employons lors du travail lchelle des pixels
non-groups, il nous semble appropri de dsigner ces groupes comme des superpixels, cest--dire des
pixels qui ont une notion largie dune entit de donnes qui peut contenir plus dun seul pixel.
Le concept des superpixels que nous introduisons est pratique pour deux raisons :
il est cohrent avec lide du sens du parcours implmente par la fonction gnratrice des index
et avec lide dune fonction dextraction des pixels (ici de tout un groupe) partir de limage en
utilisant un seul index, comme nous lavons prsent dans la section 4.4.4, page 70.
les superpixels conservent le caractre des pixels. Ainsi, nous navons pas besoin de percevoir
les groupes de pixels trs diffremment (e.g. comme des macro blocs), de dnir un autre type
qui serait spcique aux groupes de pixels et qui nous aurait conduit un travail trs diffrent de
73
celui pour les pixels. Un travail trs diffrent surtout parce que nous aurions besoin dintroduire
des fonctions plus labores dextraction des pixels voisins (ordinaires) partir dun groupe qui
serait de ce nouveau type. Cest pourquoi nous prfrons introduire des superpixels pour lesquels
nous pouvons utiliser, lors de la construction de nos algorithmes, la mme charpente que celle
utilise pour les pixels ordinaires ; mme si, bien sr, nous aurons besoin de modier certains
points spciques.
Remarquons que lide des superpixels nest pas restreinte uniquement aux arrays dnis sur les
grilles rgulires mais peut tre transpose au traitement gnral des graphes. Pour ces derniers, un
superpixel serait dni comme un groupe des sommets du graphe qui peuvent tre traits en mme
temps.
4.4.5.1 Travail avec des superpixels
La position dun superpixel dans larray est dnie par un index que nous allons appeler lindex
dancrage. Sa valeur doit tre incluse dans les bornes minimales et maximales de cet array. De plus,
llment de larray qui est dsign par lindex dancrage dun superpixel doit appartenir au groupe des
lments constituant ce superpixel.
La fonction dchantillonnage des superpixels dcrit la manire dont les lments dun superpixel
sont extraits partir de limage. tant donn un array ut et lindex dancrage i dun superpixel, les l-
ments de ce dernier peuvent tre obtenus par lapplication dune fonction concrte ump|ntSP dex-
traction de superpixels :
sampFncSPut i
Lensemble de tous les superpixels dun array doit obligatoirement composer larray entier. Le nombre
prcis des lments composant un superpixel peut tre variable dun superpixel lautre. Deux cas sp-
ciaux peuvent tre distingus, celui dun superpixel compos dun seul lment et celui dun superpixel
compos de tous les lments dun array. La dnition exacte des superpixels nest pas restreinte par
dautres conditions, on nexige pas une forme gomtrique particulire ni que cette forme soit convexe.
4.4.5.2 Sens du parcours, passage dun array un ux de superpixels et vice versa
Cependant, pour le travail pratique, il est prfrable de dnir des superpixels dune manire unie
comme des ensembles dlments dnissant le pavage de larray aux zones rectangulaires de mmes
dimensions dans lesquelles nous choisissons par convention les index les plus petits comme les index
dancrage. La gure 4.8 illustre cette situation.
i
1
superpixel
index dancrage
i
2
i
3
i
4
i
5
i
6
i
7
i
8
i
9
i
10
array
f
s
t
snd
FIG. 4.8 : Dcomposition dun array aux superpixels rectangulaires de mmes dimensions
Dans ce but, nous dnissons la fonction streamAr2DSPdu sens du parcours pour les superpixels qui
nous retourne un stream des index dancrage des superpixels et dont le fonctionnement est trs semblable
celui de la fonction streamAr2D, page 72 :
74
streamAr2DSP :: [ Char] I I Ar ( I , I ) [ ( I , I ) ]
streamAr2DSP Iov mn ut
| Iov == "FWFst" = [ ( |Io +mi , Io+n j ) | j [ 0.. mux] , i [ 0.. |mux] ]
| Iov == "FWSnd" = [ ( |Io +mi , Io+n j ) | i [ 0.. |mux] , j [ 0.. mux] ]
| Iov == "BWFst" = [ ( |Ii mi , Iinj ) | j [ 0.. mux] , i [ 0.. |mux] ]
| Iov == "BWSnd" = [ ( |Ii mi , Iinj ) | i [ 0.. |mux] , j [ 0.. mux] ]
where
( ( |Io , Io) , ( |Ii , Ii ) ) = bounds $ut ;
|mux = div (rangeSize(|Io,|Ii)1) m
mux = div (rangeSize(Io,Ii)1) n
Le premier argument est la cl avec laquelle nous dsignons la fonctionnalit exacte de cette fonction.
Le deuxime / troisime argument de cette fonction dsigne les dimensions dun superpixel dans la
premire/deuxime coordonne. Le quatrime paramtre est larray dentre que nous voulons parcourir.
Nous dnissons le type StreamizeSP qui va dsigner des fonctions pour le passage dun array un
stream des index dancrage des superpixels. La signature de ce type est, en effet, identique aux fonctions
dsignes par le type Streamize. Tandis que les fonction tant du type Streamize travaillent avec les
index ordinaires, le type StreamizeSP porte, de plus, une information syntactique du type de retour
[(I, I)], car nous le dnissons comme la liste des index dancrage des superpixels :
type StreamizeSP = Ar ( I , I ) [ ( I , I ) ]
Ainsi, la signature de type de la fonction streamAr2DSP que nous venons de prsenter :
streamAr2DSP :: [ Char] I I Ar ( I , I ) [ ( I , I ) ]
peut tre rcrite comme :
streamAr2DSP :: [ Char] I I StreamizeSP
Ayant obtenu un stream des index dancrage par la fonction streamAr2DSP, nous avons encore
besoin des fonctions qui extrairaient partir de ce stream les lments de bases de limage qui composent
les superpixels correspondants. Ces fonction seront du type SampFncSP :
SampFncSP :: ( Ix ) Ar [ ]
et elle diffrent des versions classiques (non-superpixeliques) des fonctions dchantillonnage dans le
type de retours qui est dans ce cas une liste des lments.
Ce procd est assur, dans la version gnrale, par la fonction sampSPGen. Elle va nous retourner,
pour un index dancrage donn, la liste de tous les lments de larray appartenant au superpixel qui est
dsign par cet index.
sampSPGen :: I I Ar ( I , I ) ( I , I ) [ ]
sampSPGen mn ut ( i x| , ix ) = map (ut ! ) ( range(( i x| , ix ) , ( i x| +m1, ix+n1)) )
Notons que la signature de type de cette fonction est compatible avec celle qui utilise le type SampFncSP:
sampSPGen :: I I SampFncSP
et nous pouvons lutiliser, aprs lapplication partielle de ses deux premiers paramtres, comme la fonc-
tion dentre dans les algorithmes exigeants les fonction du type SampFncSP.
Nous utiliserons encore une autre catgorie de fonctions qui est connexe aux superpixels et qui sera
utilise lors de la recomposition de larray de sortie. Il sagit des fonctions qui, partir dun tuple com-
pos de lindex dancrage et de la liste des lments rsultants dun superpixel, crent la liste des tuples
(index, lment). Cette dernire liste sera utilise dans les algorithmes comme un moyen pour pouvoir
recomposer le stream dentre de la fonction standard uttu de Haskell an de crer larray de sortie.
Ces fonctions seront du type ZipSP :
type ZipSP = ( ( I , I ) , [ ] ) [ ( ( I , I ) , ) ]
La fonction qui sera de cette catgorie, qui complte le passage au ux de superpixels, comme dni
par la fonction StreamAr2DSP et leur extraction, comme dni par la fonction sampSPGen, cest la
fonction zipSPGen
75
zipSPGen :: I I ( ( I , I ) , [ ] ) [ ( ( I , I ) , ) ]
zipSPGen mn ( ( i x| , ix ) , ) = zip ( range(( i x| , ix ) , ( i x| +m1, ix+n1)) )
Elle prend deux paramtres supplmentaires, m et n dnissant les dimensions des superpixels dans laxe
de la premire et la deuxime coordonne, respectivement. En effet, la signature de type de cette fonction
est compatible avec la suivante :
zipSPGen :: I I ZipSP
qui utilise le type ZipSP et dmontre plus explicitement sa dsignation.
Regardons maintenant comment nous allons utiliser les fonctions de travail avec les superpixels sur
un exemple trivial. Dans cet exemple, en dehors du passage dun array ut un stream des superpixels de
dimensions m n et de la recomposition dun nouvel array partir de ces derniers, nous nemployons
aucune fonction de traitement des superpixels.
array (bounds ut )
(
( foldl1 (++))
(map (zipSPGen mn) )
( zip ix )
(map (sampSPGen mn ut ) )
$ix
)
where
ix = streamAr2DSP "FWFst" mnut
Tout dabord, nous choisissons le parcours de limage par la fonction streamAr2DSP et nous obtenons
un stream des index dancrage. Sur ce stream, nous appliquons la fonction dextraction des superpixels
sampSPGen pour obtenir le stream des superpixels qui est du type liste des listes, [[]]. Lors de la
recomposition, nous ajoutons chacun des superpixels son index dancrage par la fonction zip pour
obtenir un stream des tuples (index dancrage, superpixel). Sur tous les lments de ce stream, nous
appliquons, par la fonction map, la fonction zipSP retournant une liste des tuples (index, lment). Nous
connectons ces listes distinctes par lapplication de la fonction foldl1 de rduction dun stream par la
fonction ++ de jonction des listes. La gure 4.9 illustre graphiquement le fonctionnement de ce procd.
ar
(Array
dentre)
Array
de sortie
bounds
Cration de larray de sortie
streamAr2DSP extrSPGen
zip zipSPGen
++
stream des indexes dancrage stream des superpixels
FIG. 4.9 : Exemple de travail avec les streams des superpixels
4.5 Modle formel du traitement en pipeline graphique
4.5.1 Types de donnes utiliss dans le modle
Nous allons utiliser la mme logique que celle suivie pour la dnition des types de base, cf. 4.3.1,
galement pour les dnitions de nouveaux types pour le modle du traitement en pipeline graphique sur
les GPU.
Ces dnitions que nous nous apprtons dcrire devraient tre perues par le lecteur comme des d-
nitions smantiques, les nouveaux identicateurs nous permettront de distinguer le sens des paramtres
dans les fonctions plus complexes que nous allons rencontrer.
76
Jaromr BRAMBOR 4.5. MODLE FORMEL DU TRAITEMENT EN PIPELINE GRAPHIQUE
Il existe plusieurs types de donnes qui sont utiliss par les GPU modernes pour le traitement et
peuvent varier le long du calcul, sagissant de nombres entiers ou de nombres une virgule ottante
diverses prcisions. Ainsi, il est possible davoir les donnes stockes dans les textures en nombres
entiers mais deffectuer le calcul dans le pipeline graphique en virgule ottante.
Pour pouvoir rester facilement comprhensible dans nos prochaines explications, nous nallons pas
chercher construire un modle le plus complet possible pour le GPU, mme si cela pourrait tre en-
visag. Pour le stockage de donnes sur le GPU, nous allons utiliser un type de nombres entiers Int du
Haskell. Nous appliquons cette approche sans perte dutilit puisque les algorithmes que nous dcrivons
emploient des nombres entiers pour lexpression des pixels dans les images. Cest galement le cas pour
les oprations morphologiques dans le domaine digital. Les types relatives lindexation seront des types
de nombres entiers, bass sur le type dindexation de base I que lon a dj dni dans 4.3.1.1.
Un autre point est remarquer. Mme si les possibilits des GPU actuels permettent aussi le travail
avec les donnes 3D en utilisant les textures 3D, nous ne travaillerons quavec les algorithmes travaillant
avec les images 2D. Nos donnes pourrons ainsi contenir plusieurs composantes par pixel mais elles
resteront de dimension 2. Cela va nous conduire des dnitions spcialises pour 2 dimensions et
surtout une indexation par tuple (I, I).
Pour donner une vue globale des diffrents types que nous expliquons par la suite, nous prsentons
la table 4.1 qui rcapitule leurs identicateurs, dsignation et dnition.
Type Dsignation Dnition
CElmnt lment de couleur type CElmnt = Int
C Vecteur de couleur type C = PVec I CElmnt
CI Index de couleur type CI = I
Pos Coordonne de position type Pos = I
P Vecteur de position type P = PVec I Pos
Dpth Profondeur type Dpth = I
TXB Bord de la texture type TXB = C
TX Texture type TX = (Ar (I,I) C, [TXB])
TXP Position dans la texture type TXP = (I,I)
TXI Index de texture type TXI = I
Shape Primitive de la gomtrie data Shape = Rect | Line | Point
V Vertex type V = (P, [(CI,C)], [(TXI, TXP)])
F Fragment type F = (P, Dpth, [(CI,C)], [(TXI, TXP)])
FBO Frame buffer object type FBO |Io = Ar (I,I) |Io
FB Frame buffer type FB = (Ar I (FBO C), [FBO Dpth])
PX Pixel type PX = (P, Ar I C)
Env Environnement type Env = (FB, [TX])
Commands Commandes graphiques type Commands = ([Shape],[V])
TAB. 4.1 : Types de donnes pour les algorithmes utilisant le pipeline graphique et les GPU
4.5.1.1 Types pour les couleurs
Nous dnissons deux types pour la manipulation de la couleur sur les GPU. Le type CElmnt repr-
sente une seule composante de la couleur et sera dni pour les besoins de cette thse en utilisant le type
de nombres entiers Int.
type CElmnt = Int
Le deuxime type que nous dnissons ici, type C, reprsente la couleur de plusieurs composantes
que nous percevons comme un vecteur. Dans notre approche, ce vecteur a son correspondant dans le
77
type PVec, cf. 4.3.1.3, page 64. Mme si lon pouvait choisir le type plus gnral dun array Ar et le
spcialiser pour une dimension, nous utilisons ici le type de donnes paquetes PVec car cest ainsi que
la plupart des GPU peroivent les vecteurs de couleurs et peuvent les traiter laide des instructions
SIMD lintrieur des registres. Ainsi nous dnissons le type C comme :
type C = PVec I CElmnt
Pour pouvoir indexer les couleurs lintrieur dun vecteur de couleur C, nous dnissons le type CI.
Il reprsente lindex de couleur et est bas sur le type dindexation de base I, cf. 4.3.1.1 page 64 :
type CI = I
Nous utiliserons galement deux fonctions de manipulation, c3e et c4e, qui crent un vecteur partir
des lments et dont les dnitions exactes sont prsentes en Annexe B, page 201.
4.5.1.2 Types pour les coordonnes
Nous dnissons les types pour la manipulation avec les coordonnes. Le type Pos est le type de
base pour exprimer la position et il sappuiera sur le type dindexation de base I, cf. 4.3.1.1 page 64 :
type Pos = I
Le type P est un type compos et il sera utilis pour dsigner un point dans lespace dune ou
plusieurs dimensions. Nous le dnissons en utilisant le type de vecteur paquet PVec, cf. 4.3.1.3, page
64, car nous supposons que la plupart des GPU utilisent les types et le traitement SIMD des coordonnes.
type P = PVec I Pos
Nous dnissons galement deux fonctions de manipulation, p2D et p3D, qui crent partir dun
tuple ou triple de coordonnes un vecteur des coordonnes 2D ou 3D respectivement et dont les dni-
tions exactes sont prsentes en Annexe B, page 201.
Pour exprimer la profondeur dans le traitement des fragments, nous dnissons le type Dpth (une
abrviation du terme anglais Depth). Puisquil sagit dun type dindexage, nous nous basons sur le type
I, cf. 4.3.1.1, page 64 :
type Dpth = I
4.5.1.3 Types pour les textures
Les textures sont les objets qui stockent sur les cartes graphiques les images de travail. Nous dnis-
sons tout dabord le type TXB qui exprime la valeur de bord dune texture et qui est compatible avec le
type vecteur de couleur C :
type TXB = C
La texture est dnie par le type TX en tant que tuple o le premier lment est un array qui contient
les donnes de couleur. Il est utilis pour stocker les images 2D. Le deuxime lment est une liste qui
peut tre soit vide, dans le cas o nous ne travaillons pas avec les bords, soit contenir linformation sur
la couleur de bord exprim par le type TXB :
type TX = ( Ar ( I , I ) C , [ TXB] )
Nous utiliserons galement trois fonctions de manipulation. La fonction mkTX qui cre une texture
partir de ses composantes, les fonctions getArFromTX et getTXBFromTX nous aident obtenir les com-
posantes partir dune texture. Leurs dnitions exactes sont prsentes en Annexe B, page 201.
Pour pouvoir indexer un lment dans une texture, nous allons utiliser les chantillonneurs (samplers)
qui travaillent avec les positions dans la texture pour ensuite en extraire une valeur. Le type TXP va
exprimer la position dans la texture 2D et est dni comme :
type TXP = ( I , I )
78
Si nous travaillons avec plusieurs textures la fois stockes dans un array, nous aurons besoin dun
index pour y accder. Nous dnissons ainsi un type TXI destin ce travail en nous basant sur le type
dindexation I, cf. 4.3.1.1, page 64 :
type TXI = I
4.5.1.4 Type pour les primitives de la forme
Nous allons travailler avec certaines formes gomtriques pour passer les commandes graphiques
dans les units de calcul dun GPU. Il sagit prcisment dun rectangle (Rect), dune ligne (Line) et
dun point (Point). Pour les stocker, nous avons dni un type numratif Shape :
data Shape = Rect | Line | Point
4.5.1.5 Types pour les vertex
Les vertex constituent un des piliers de traitement sur les GPU. Ce sont les structures de donnes
utilises pour stocker les informations relatives au traitement des vertex dans le pipeline graphique.
Formellement, nous dnissons un vertex comme une structure compose, qui doit contenir obli-
gatoirement un point P exprimant la position dans lespace 2D ou 3D. Il peut contenir une ventuelle
information sur la couleur reprsente, soit par la liste vide dans le cas o le vertex ne possde pas
dinformation de couleur, soit par la liste des tuples (CI,C). Lindex CI, est utilis pour distinguer les
donnes lors du travail avec plusieurs couleurs mais aussi pour mettre la couleur en correspondance avec
les plans de rendu si nous utilisons le pipeline graphique pour le rendu dans plusieurs textures (angl.
render to multiple textures). Un vertex peut contenir galement aucune, une ou plusieurs information sur
les donnes stockes dans les textures exprimes par la liste des tuples (TXI, TXP). Lindex TXI identie
la texture, la position TXP identie la position dun lment dans cette texture.
Dans le formalisme fonctionnel, un vertex V est dni comme :
type V = ( P, [ ( CI , C ) ] , [ ( TXI , TXP) ] )
Nous utiliserons galement une fonction de manipulation mkV qui cre un vertex partir de ses
composantes et dont la dnition exacte est prsent en Annexe B, page 202.
4.5.1.6 Type pour les fragments
Les fragments constituent galement un pilier de traitement sur les GPU. Ce sont les structures de
donnes qui stockent linformation relative au traitement des fragments dans le pipeline graphique.
Un fragment est une donne compose qui contient obligatoirement un point P de position 2D
lcran et la profondeur du fragment Dpth. En effet, il contient encore linformation 3D travers la pro-
fondeur. ces donnes nous ajoutons, de la mme faon que lon a fait pour les vertex, des informations
sur la couleur en utilisant la liste des tuples (CI,C) et des informations sur les donnes stockes dans les
textures en utilisant la liste des tuples (TXI, TXP).
Ainsi, nous dnissons le type F dun fragment comme :
type F = ( P, Dpth , [ ( CI , C ) ] , [ ( TXI , TXP) ] )
Nous utiliserons aussi une fonction de manipulation mkF qui cre un fragment partir de ses com-
posantes et dont la dnition exacte est prsente en Annexe B, page 202.
4.5.1.7 Types pour le framebuffer
Le framebuffer est une structure dans laquelle le pipeline graphique crit les pixels la n du traite-
ment, nous pouvons dire que cest une mmoire de sortie. De nos jours, les possibilits de programmation
79
des GPU nous permettent de connecter plusieurs objets (plusieurs types de zones de mmoire) la sortie
du pipeline graphique et davoir ainsi plusieurs possibilits de stockage des rsultats.
Les objets qui peuvent tre connects un framebuffer sont appels Framebuffer objects et nous
dnissons un type FBO pour ce but. Il sagit dun array de 2D dont les lments sont du type tfbo.
type FBO| Io = Ar ( I , I ) | Io
Le type tfbo est un paramtre dans cette dnition et il nous permettra de distinguer les instances des
objets du framebuffer qui diffrent dans les types dlments. Parmi dautres, nous allons utiliser les
FBO aussi pour le rendu dans les textures, dont la dnition est trs proche et diffre seulement dans la
spcialisation du type pour les couleurs, cf. 4.5.1.3, page 78.
Le Framebuffer, quil ne faut pas confondre avec le framebuffer object, doit contenir au moins un
objet FBO correspondant la couleur et o le pipeline graphique pourrait crire les rsultats. Ainsi, nous
dnissons un framebuffer FB comme :
type FB = ( Ar I (FBO C ) , [ FBO Dpth ] )
Le premier lment de ce tuple est un array des FBO dont le type est la couleur C. Puisque un array doit
contenir au moins un lment, son utilisation ici est convenable. En revanche, le deuxime lment est
dni par une liste qui peut tre soit vide, soit contenir exactement un lment FBO dont le type est la
profondeur Dpth. Cette liste exprime la possibilit, mais pas lobligation, de connecter au framebuffer la
texture de profondeur.
Un pixel est le rsultat du traitement des fragments et il sera inscrit dans les objets du framebuffer
exprimant la couleur : (FBO C). Le type dun pixel va ainsi contenir au moins une information sur la
couleur. Il peut aussi contenir plusieurs informations sur la couleur si le framebuffer contient galement
plus dun objet (FBO C). Cest, en effet, le cas du rendu dans plusieurs textures. Un pixel contient
galement une information sur la position 2D, exprime par le type P. En contraste des fragments, il ne
contient aucune information sur la profondeur car il sagit dun point color dans limage. Un pixel PX
est dnit comme :
type PX = ( P, Ar I C )
4.5.1.8 Type pour lenvironnement de travail
Le pipeline graphique correspond une architecture du calcul. Il est entour, parmi dautres, par la
mmoire qui nous sert stocker les images. Lenvironnement de travail du pipeline graphique est dni
pour les besoins de notre traitement par le type Env et nous y incluons le framebuffer FB et les textures
TX exprims par une liste. Cette liste peut contenir plusieurs textures mais peut tre vide dans le cas o
nous ne travaillerions pas avec les textures.
type Env = (FB, [ TX] )
Pour pouvoir r-inclure les rsultats de traitement perus comme un nouveau framebuffer FB, nous
dnissons une fonction refreshFB de mise jour du framebuffer dans lenvironnement Env :
refreshFB :: Env FB Env
refreshFB (_, x) |I = ( |I , x)
qui insre le framebuffer, pass par largument |I, dans lenvironnement sortant de cette fonction.
Nous utiliserons par la suite la fonction de cration de lenvironnement mkEnv, cf. dnition exacte
en Annexe B, page 202. Et nous utiliserons aussi deux fonctions de manipulation, getTXs et getFB, dont
les dnitions exactes sont prsentes galement en Annexe B, page 202.
4.5.1.9 Les commandes graphiques
Les commandes passs au GPU, exprimes par le type Commands, ont la forme des primitives gra-
phiques, exprims par le type Shape qui spcie le modle de la forme. Ce modle est complt par les
80
donnes descriptives, les vertex V. Chaque forme a un nombre dni des vertex associs qui donnent
la forme des valeurs concrtes et la dnisse prcisment. On inclut dans les vertex galement les infor-
mations supplmentaires telles que la couleur, les coordonnes de la texture lie avec cette forme, dans
le graphisme 3D il pourrait sagir des paramtres de la surface, etc.
type Commands= ( [ Shape] , [ V ] )
4.5.2 Primitive de calcul avec le pipeline graphique
Pour formaliser le fonctionnement du pipeline graphique, nous allons dnir quelques fonctions qui
utiliseront les types dnis pralablement et vont donner les correspondants formels aux blocs opra-
tionnels du pipeline graphiques et la faon de leur fonctionnement. Le tableau 4.2 prsente une liste
complte de ces fonctions.
Nom de la Nom Dsignation Signature de type
fonction du type
Sampler chantillonage des textures (TX TXP C)
vprocessor Processeur des vertex (Env VProg [V] [V])
VProg Vertex programme (Env V V)
fprocessor Processeur des fragments (Env FProg [F] [F])
FProg Fragment programme (Env F F)
rprocessor Oprations du framebuffer (Env RProg FB [F] FB)
RProg Raster programme (Env FB F FB)
TAB. 4.2 : Signatures de type des primitives du calcul du pipeline graphique et les GPU
4.5.2.1 chantillonnage des textures
Lchantillonnage des textures est une des oprations utilises dans deux units - lunit de traitement
des vertex et lunit de traitement des fragments. Elle se prsente lutilisateur par les samplers, les blocs
congurables daccs la mmoires des textures. Dans cette thse, nous dnissons les samplers comme
des fonctions du type Sampler qui, pour une texture TX et une position TXP donnes, extraient une
information partir de cette texture. Le rsultat dchantillonnage se prsente par le vecteur de couleurs
de sortie C.
type Sampler = ( TX TXP C )
Le fonctionnement exact des fonctions dchantillonnage est dpendant des capacits matrielles des
processeurs graphiques et est congurable selon nos besoins. Ces capacits sont largement sufsantes
pour notre travail et nous nen allons utiliser que certaines congurations.
La premire des fonctions dchantillonnage que nous allons utiliser en la morphologie mathma-
tique est la fonction smpBorder qui nous retourne les points de la texture x correspondant la coor-
donne p si cette coordonne est prsente dans ltendue dindexation de la texture, sinon, elle nous
retourne la valeur de bord associe la texture.
smpBorder :: Sampler
smpBorder x p | inbounds2D(bounds$ut) p = ut ! p
| otherwise = getTXBFromTX$x
whereut = getArFromTX$x
4.5.2.2 Traitement des vertex
Les vertex sont traits dans une unit de traitement que nous appelons le processeur des vertex et qui
est dnie dans notre formalisme fonctionnel par la fonction vprocessor. Son fonctionnement exact est
81
dcrit par un programme VProg qui est excut sur chaque vertex du stream dentre. Ce programme
peut obtenir certains paramtres globaux partir de lenvironnement de travail Env ou il peut obtenir des
donnes partir des textures (stockes dans lenvironement Env).
vprocessor :: Env VProg [ V ] [ V ]
vprocessor a vp v = map (vp $a) v
Le vertex programme lui-mme est dni comme une fonction du type VProg qui est connecte
lenvironnement Env et qui effectue une opration sur un vertex V. Le type V du vertex constitue
galement le type de sa valeur de sortie. Nous ne donnons ici que la signature de type VProg du vertex
programme car cest ce programme qui exprime la capacit de programmation des GPU et nous allons
le dnir spciquement pour chacun de nos algorithmes.
type VProg = ( Env V V )
Comme un exemple trivial dun vertex programme, nous prsentons la fonction vpid didentit qui
ne modie pas le vertex dentre et le retourne aussitt :
vpid :: Env V V
vpid a v = v
4.5.2.3 Rastrisation des primitives gomtriques
Un autre bloc fonctionnel dans le pipeline graphique est le rastriseur. Il sagit de lunit qui cre
les fragments partir des donnes dcrivant une forme gomtrique. Nous le dnissons formellement
comme fonction du type Rasterizer qui est connecte lenvironnement Env et qui prend comme argu-
ment un tuple compos du ux des valeurs de la forme gomtrique et du ux de vertex, ([Shape], [V]).
Les fonctions de ce type extraient, selon les valeurs concrtes dcrivant la forme, un nombre dni de
vertex [V]. La sortie de ce bloc est, bien sr, le ux des fragments [F] drivs de cette forme.
type Rasterizer = ( Env ( [ Shape] , [ V ] ) [ F ] )
Nous ne donnons cette place que la signature de type Rasterizer dun rastriseur. Cest d au fait que le
rastriseur est galement une unit congurable. Par consquent, les fonctions de ce type seront dnies
dans nos algorithmes et elles vont correspondre la conguration particulire de cette unit.
4.5.2.4 Traitement des fragments
Lunit de traitement des fragments, appele processeur des fragments, est dnie dune faon si-
milaire au processeur des vertex (dans 4.5.2.2, page 81). Le processeur des fragments est model par la
fonction fprocessor qui excute un fragment programme FProg sur un ux dentre des fragments [F].
Ce processeur peut obtenir des donnes supplmentaires partir de lenvironnement de travail Env ce qui
se prsente comme la capacit dchantillonner les textures. Le processeur de traitement des fragments a
pour rsultat galement un ux des fragments [F].
fprocessor :: Env FProg [ F ] [ F ]
fprocessor a |p | = map ( |p $a) |
Le fragment programme est une fonction du type FProg :
type FProg = ( Env F F )
Nous ne prsentons que la signature de type pour les fragment programmes. Les fonctions seront dnies
spciquement pour chaque algorithmes en assurant la fonctionnalit convenable notre cas dutilisa-
tion. Le programme trivial dun fragment programme est le programme didentit fpid qui ne modie
rien sur le fragment dentre et le retourne inchang aussitt.
fpid :: Env F F
fpid a | = |
82
4.5.2.5 Opration du framebuffer
Les oprations du pipeline graphique qui sont regroupes dans notre diagramme de blocs, g. 3.18,
page 52, sous le nom Raster oprations constitue, en effet, un bloc fonctionnel tout entier qui traite
les fragments, les convertit en pixels et se charge de leur fusion avec le contenu dj prsent dans le
framebuffer.
La manire dont linformation dun fragment est fusionne avec les donnes du framebuffer peut tre
congure par lutilisateur et nous pouvons, si notre matriel dispose de telles capacits, avoir galement
les fonctionnalits de post-traitement des pixels plus ou moins complexes.
Nous avons regroup toutes ces oprations dans un bloc que nous avons nomm raster processor
mais qui ne correspond pas sur les GPU un vrai processeur mais plutt un certain nombre des blocs
fonctionnels qui sont enchans dans un pipeline et dont la fonction peut tre active par lutilisateur.
Pour suivre la mme logique que pour le vertex processeur et le fragment processeur, nous dnis-
sons le raster processeur par la fonction rprocessor. Elle prend un programme RProg comme paramtre
et englobe tous les blocs de post-traitement travaillant avec les informations du framebuffer dans une
seule fonction du Haskell :
rprocessor :: Env RProg FB [ F ] FB
rprocessor a tp |I | = foldl (tp$a) |I |
Ce processeur peut obtenir des paramtres de conguration de lenvironnement Env et applique le pro-
gramme RProg sur tous les fragments du stream dentre [F] en utilisant les donnes du framebuffer FB.
Le raster programme se charge galement de lcriture dun nouveau pixel issu de ces oprations dans
le framebuffer. La fonction du Haskell foldl qui est utilise ici est parfaitement convenable pour notre
travail. Elle correspond la rduction du stream par une fonction dont les arguments sont de deux types
diffrents et qui est parfaitement convenable pour notre travail.
Nous prsentons ici la signature de type RProg du raster programme, la dnition prcise sera sp-
cie ultrieurement selon les besoins particuliers de nos algorithmes.
type RProg :: ( Env FB F FB)
4.5.3 Modle du pipeline graphique des GPU
Nous assemblons un modle mathmatique du pipeline graphique partir des primitives du calcul
que lon vient de prsenter. Ainsi, le pipeline graphique est dni comme fonction pipeGPUqui enchane
dans une squence de traitement le vertex processeur vprocessor, rastriseur tu, fragment processeur
fprocessor, et les oprations du framebuffer exprimes par un processeur abstrait rprocessor. Un nou-
veau framebuffer issu de notre calcul est incorpor dans lenvironnement de sortie de ce pipeline par la
fonction refreshFB.
pipeGPU :: VProg Rasterizer FProg RProg Commands Env Env
pipeGPU vp tu |p tp (, v ) a =
(refreshFB a)
(rprocessor a tp ( getFB a) )
(fprocessor a |p)
(tu a)
$ (, (vprocessor a vp) v )
Le comportement de ce pipeline est modiable par les fonctions passes comme arguments de ce pipe-
line. VProg dnit le programme du vertex processeur, tu dnit la manire exacte de rastrisation des
formes gomtriques, FProg dnit le programme du fragment processeur, RProg dnit le fonction-
nement des oprations sur le framebuffer et la manire dont les fragments sont transforms en pixels et
dont les pixels sont fusionns avec les donnes dans le framebuffer.
83
4.6 Primitives de la morphologique mathmatique
Les mthodes de la morphologie mathmatiques auxquelles sont destins nos skeletons algorith-
miques et les algorithmes drivs de ces derniers sont dj bien dcrites dans plusieurs publications
scientiques. Nous pensons que les dnitions de base, des proprits des oprateurs morphologiques et
les explications standard de leur fonctionnement sont bien connus et il nest pas donc ncessaire dinclure
une introduction dtaille la morphologie mathmatique. Nous adressons le lecteur aux publications
qui sont consacres lexplication des bases de la morphologie mathmatique. Nous recommandons un
article de Henk Heijmans
Hei95
qui prsente sur quelques pages une introduction aux principes de base
de la morphologie mathmatique. Pour une introduction plus profonde, nous recommandons un livre
rcent de Pierre Soille
Soi03
qui familiarisera le lecteur avec les oprations morphologiques le plus utili-
ses dans la pratique. Pour une explication systmatique et les concepts avancs de la morphologie, nous
recommandons les livres de Jean Serra
Ser88, Ser89
comme rfrence.
Dans la suite, nous ne prsenterons que les dnitions qui btissent les briques de bases et qui se-
ront rutilises dans nos prochaines dnitions des algorithmes. Nous allons prsenter les oprations
morphologiques dans le formalisme fonctionnel qui nest pas habituellement utilis pour telles dni-
tions mais qui fait un trs bon lien entre les dnitions mathmatiques classiques, comme prsentes
dans les sources bibliographiques introductives que nous venons de mentionner, et les implmentations
informatiques de ces dnitions par la programmation, fonctionnelle dans notre cas.
4.6.1 Images dans la morphologie mathmatique
Dans la morphologie discrte, nous travaillons avec des images discrtes o cest le domaine de ces
dernires mais galement les valeurs de leurs pixels qui sont digitaliss. Nous mentionnons cela tout en
sachant quune image peut avoir plus quune seule valeur numrique jointe un pixel, ce qui est le cas,
par exemple, pour les images multispectrales o les images dont les valeurs sont les vecteurs paquets.
Ainsi, nous dnissons une image I comme une fonction dnie sur un certain domaine D Z
n
,
n N et dont les valeurs sont dnies par un ensemble V Z :
I{
D V
p I(p)
(4.1)
Cette dnition est gnrale et ne dnit pas les dtails sur la forme exacte du domaine ni sur len-
semble des valeurs. Pourtant, dans les applications pratiques travaillant avec les images des camras
vido, nous choisissons souvent le domaine dune image 2D comme un array 2D. Cette interprtation
mne la forme que nous utilisons dans cette thse pour lexpression dune image en tant quarray en
formalisme fonctionnel, cf. 4.3.1.4, page 65 :
Ar ( I , I )
o le domaine D de la dnition correspond la classe des index Ix dans Haskell que nous spcialisons,
pour nos besoins, un tuple pour une image 2D.
4.6.2 Grilles et voisinages
Pour exprimer les relations de connexit entre les lments dune image, nous dnissons la notion
de la grille. Une grille G est dnie comme :
G Z
n
Z
n
, n N (4.2)
Nous dnissons galement la notion du voisinage. Habituellement, le voisinage est dni comme
un ensemble des voisins du point p et on dnit galement le voisinage largi comme un ensemble des
voisins incluant ce point p. Pour des raisons pratiques, il est convenable de distinguer le terme ensemble
84
Jaromr BRAMBOR 4.6. PRIMITIVES DE LA MORPHOLOGIQUE MATHMATIQUE
des voisins du terme voisinage et dnir le dernier en incluant le point p car cest avec une telle dnition
du voisinage que nous allons travailler le plus en pratique.
Ainsi, nous comprenons sous le terme lensemble des voisins un ensemble des points de lespace qui
sont voisins un autre point en se basant sur les relations locales dnies par une grille donne. Ceci dit,
lensemble des voisins N
G
(p) du point p sur la grille G est dni comme :
N
G
(p) = {p
Z
n
, (p, p
) G, n N} (4.3)
Par extension, N
G
(A) est lensemble des voisins dun ensemble A.
En revanche, le voisinage dit largi que nous allons appeler dsormais voisinage est un ensemble
constitu du point p et de son ensemble des voisins. Ainsi, le voisinage N
G
(p) du point p sur la grille G
est dnit comme :
N
G
(p) = {p} N
G
(p) (4.4)
La grille et la notion du voisinage qui sont associes limage (cf. lquation 4.1) nous dnissent
les relations entre les pixels et dnissent, en utilisant ces derniers, les ensembles des pixels voisins.
Pourtant, les quations 4.2 et 4.3 qui sont devenues classiques dans la morphologie ne sont pas restreintes
au domaine D de limage I. Ce qui nous posera des problmes lors de travail avec les bords de limage
o la grille dnit galement les relation entre les pixels lintrieur du domaine D de limage I et les
index qui ne sont pas inclus dans ce domaine et se trouvent lextrieur de limage. Par consquent, la
dnition de lensemble des voisins ^
C
inclut galement les points de lextrieur du domaine de limage.
Les grilles le plus souvent utilises dans les applications pratiques de la morphologie mathmatique
sont reprsentes sur le g. 4.10. Il sagit notamment de la grille carre avec 4-connexit entre les pixels
(q.v. 4.10(a)) et de la grille carre 8-connexe (q.v. 4.10(b)). Dautres types importants de grilles, lar-
gement utiliss dans la morphologie mathmatique pour leurs proprits de connexion lors du travail
avec les composantes connexes (cf. larticle
Soi03
pour plus de dtails ce sujet), sont appeles les grilles
hexagonales
1
. La grille la plus souvent utilise dans les applications qui traitent des signaux vidos est
celle illustre par la g. 4.10(c) que nous appelons dcale par lignes. Mais il est possible denvisager
lutilisation dune grille dcale par les colonnes, cf. 4.10(d), qui nest pas couramment employe mais
laquelle nous devons faire appel si nous travaillons avec les images que nous transposons lintrieur
de nos algorithmes.
(a) Grille carre
4-connexe
(b) Grille carre
8-connexe
(c) Grille hexagonale
6-connexe, dcale par
lignes
(d) Grille hexagonale
6-connexe, dcale par
colonnes
FIG. 4.10 : Grilles utilises dans la morphologie mathmatique
Le problme majeur avec les grilles hexagonales est quelles emploient les positions dans limages
qui ne sont pas des nombres entier, car la ligne/colonne est dcale de 0.5 de la distance entre les pixels.
Ce qui nentre pas en cohrence avec les dnissions dcrites prcdemment pour la grille (cf. quation
4.2) o nous exigeons les nombres entiers. Ce problme est encore plus marquant lors du stockage des
pixels dans la mmoire laide dun array 2D qui est dcrit, en effet, par la grille carre.
1
Il sagit, en effet, de grilles triangulaires, la notion dhexagone surgit lors du travail avec le voisinage
85
(a) sur les lignes avec index 2i
(b) sur les lignes avec index 2i + 1
FIG. 4.11 : Voisinage dnit sur une grille hexagonale avec 6-connexit (dcale par lignes) et sa transposition
une grille carr avec 6-connexit (dcale par lignes)
Cest pourquoi nous dnissons les grilles carres avec 6-connexit qui font une correspondance
entre le stockage de donnes dans une grille carre (dans un array) mais dont le lensemble des voisins
de chaque point dsigne les points de la grille hexagonale correspondante. La gure 4.11 nous montre
cette mis en correspondance entre la grille carre et la grille hexagonale et le voisinage non symtrique
qui est dni diffremment sur les lignes paires et impaires. La gure 4.12 dmontre le mme principe
pour le travail avec les grilles dcales par colonnes.
4.6.3 lments structurants
Les lments structurants sont dnis comme un sous-ensemble dun espace vectoriel, pas ncessai-
rement celui dnissant la grille. Donc, un lment structurant est dni par un ensemble des vecteurs
de dplacements qui, utiliss pour les oprations de Minkowski, sont employs dplacer lensemble
(image) pour y ensuite appliquer une opration ensembliste, cf. g. 4.13(a) qui prsente laddition de
Minkowski.
Les oprations morphologiques de base, la dilatation et lrosion, sont dnies
1
par les oprations de
Minkowski, mais en utilisant un lment structurant transpos. La diffrence entre les deux oprations est
percevable aprs avoir compar la g. 4.13(b) (pour la dilatation et llment structurant transpos) avec
la g. 4.13(a) (pour laddition de Minkowski et llment structurant dans sa version non-transpose).
Notons que si nous utilisons les approches qui ne travaillent pas lchelle des images mais tra-
vaillent lchelle des pixels laide des kernels et en utilisant lextraction des lments partir des
vecteurs de dplacements, nous ne pouvons pas, pour le calcul des oprations morphologiques de base,
utiliser directement les vecteurs dnis par llment structurant transpos. En effet, lors des extractions
des voisins pour le calcul de la dilatation par un kernel lchelle des pixels, nous utilisons les vec-
teurs de dplacement qui ne correspondent pas ceux qui ont t donns pour la dilatation mais leur
version transpose. Ainsi, nous avons recours double transposition (une pour la dilatation, une pour
lextraction lchelle dun kernel). Cest--dire, les vecteurs de dplacement que nous utilisons lors de
lextraction des voisins sont ceux dnis par llment structurant non-transpos. La g. 4.13(c) illustre
ce raisonnement.
1
Plus de dtail sur les dnitions de la dilatation et de lrosion par les oprations de Minkowski, cf. page 43 du livre
Ser89
de Serra
86
(a) sur les les colonnes avec index 2i
(b) sur les colonnes avec index 2i + 1
FIG. 4.12 : Voisinage dni sur une grille hexagonale avec 6-connexit (dcale par colonnes), deuxime type
et sa transposition une grille carr avec 6-connexit (dcale par colonnes)
lment
structurant
Image dentre Image de sortie
(a) lment structurant et laddition de Minkowski
lment
structurant
lment
structurant
transpos
(b) lment structurant transpos et la dilatation
Liste
des vecteurs
de dplacement
Extraction des lments
pour le calcul par un kernel
(c) Liste des vecteurs de dplacement pour lextractions des
lments lors du travail avec les kernels
FIG. 4.13 : Lutilisation des lments structurants dans les oprations morphologiques et les listes des vecteurs
de dplacement lors du travail avec les kernels
87
Dans notre approche fonctionnelle, les notions du voisinage et de llment structurant (transpos
ou non-transpos) sont trs proches car les deux sont exprimes par la mme structure de donnes : la
liste du Haskell. Dans les implmentations des oprations morphologiques qui vont utiliser la fonction
dextraction des pixels, nous allons travailler avec les listes des vecteurs de dplacement. Ces listes
perdent linformation syntaxique et en les utilisant, nous nallons pas faire une distinction explicite entre
un lment structurant en sens large (transpos ou non-transpos) et entre le voisinage dun pixel. Le
sens exact de ce que cette liste reprsente sera donn par la dnition de lopration effectuer.
Ainsi, nous dnissons le type Ngb pour pouvoir exprimer la liste de ce type.
type Ngb = [ ( I , I ) ]
Comme exemple des dnitions de ces listes, nous montrons la dnition du voisinage de la grille
carre 4-connexe, ngbSQR4 :
ngbSQR4 = [ (0,0) , (0,1) , (1,0) , (0,1), (1,0)] :: Ngb
et la manire dont nous drivons lensemble des voisins ngbSQR4WC partir de ce voisinage :
ngbSQR4WC = ngbSQR4\\[(0,0) ] :: Ngb
Les listes de dplacement utilises sur la grille hexagonale (dcale par lignes) sont dnies en se
basant sur une ligne donne (ici la ligne avec un index pair) comme, par exemple :
ngbSQR6 = [ (0,0) , (0,1) , (1,0) , (1,1), (0,1), (1,1), (1,0)] :: Ngb
Ce qui correspond au voisinage illustr sur la g. 4.11(a). La forme pour le voisinage sur la ligne impaire
est soit dnie exactement pour la ligne impaire, soit dduite de llment structurant pour la ligne paire
par dcalage des index dans la fonction dextraction du voisinage, comme nous le verrons dans la section
suivante.
4.6.4 Extraction du voisinage
4.6.4.1 Concrtisation des index des pixels dsigns par llment structurant
Dans la suite, nous allons utiliser les fonctions pour lobtention des index concrets constituant le
voisinage local dun lment. Les index ne seront pas restreints sur le domaine de limage, cest--dire,
il peuvent dsigner un index au-del du domaine de limage.
Ces fonction seront du type SpecNgb :
type SpecNgb = Ngb ( I , I ) [ ( I , I ) ]
qui vont nous livrer, en se basant sur la liste des dplacement relatifs et pour une position dans limage
concrte, (I, I) la liste des index de dplacement concrets.
Nous dnissons la fonction specNgbSQR qui, tant spcique pour la grille carre, prend la liste
des index de dplacement npI et qui, pour un index dun lment donne (x, ), nous retourne les index
spciques des voisins de ce pixel ou des lments dsigns par llment structurant de ce pixel :
specNgbSQR :: SpecNgb
specNgbSQR npI (x ,) = map ( (Jx,J) (x+Jx, +J)) npI
De la mme manire, nous pouvons dnir dautres fonctions pour dautres grilles. Pour illustrer la
construction dune telle fonction pour la grille hexagonale dcale par lignes (paralllement la deuxime
coordonne), nous prsentons la dnition de la fonction specNgbHEXR qui est plus complexe :
specNgbHEXR :: SpecNgb
specNgbHEXR npI (x ,) | even x = map ( (Jx,J) (x+Jx, +J)) npI
| otherwise=fncnpI(x,) [ ]
where
fnc ( (Jx,J):npI) (x ,) ta | even Jx = fnc npI (x ,) ( (x+Jx, +J):ta)
fnc ( (Jx,J):npI) (x ,) ta | odd Jx = fnc npI (x ,) ( (x+Jx, +J+1): ta)
fnc [ ] _ ta = ta
88
Cette fonction est spcialise pour le travail avec le voisinage dni, par convention, sur la ligne paire de
la grille carre quivalente la grille hexagonale dcale par lignes (eg. ngbSQR6).
4.6.4.2 Traitement de lextrieur du domaine ni de limage
Le traitement des valeurs des voisins ou des valeurs dnies par un lment structurant et qui nap-
partiennent pas au domaine de limage mais son extrieur constitue lactivit la plus problmatique du
traitement par les kernels du calcul. Ce qui nous pose des problmes ici cest le fait que nous navons pas
un lment de limage correspondant aux index de dplacement dnissant les voisins en-dehors du do-
maine ni de limage. Par consquent, nous sommes obligs dutiliser des approches particulires pour
lextraction des valeurs partir des index qui se trouvent lextrieur de limage. Un certain nombre de
techniques existe et leur utilisation prcise est dtermine par lapplication pratique. Lapproche utilise
le plus souvent est celle de la valeur du bord constante.
Pour pouvoir traiter les valeurs extrieurs du domaine de limage, nous dnissons un type BorderFnc
de fonctions qui vont se charger de nous retourner, pour un array donne et pour une position concrte
(I, I) nappartenant pas au domaine de limage, une valeur prcise :
type BroderFnc = ( Ar ( I , I ) ( I , I ) )
La fonction cBorder qui travaille sur les valeurs scalaires nous retourne toujours la constante vuI
indpendamment de la valeur concrte de lindex po.
cBorder :: (Ord) BroderFnc
cBorder vuI = ( ut po vuI )
Pour le traitement SIMD, la dnition de la fonction cBorderSIMD percevant les bords comme les
lments paquets de la valeur constante est un peu diffrente mais elle assure la fonctionnalit du mme
type
cBorderSIMD :: PVec I BroderFnc( PVec I )
cBorderSIMD vuI = ( ut po vuI )
Dautres fonctions de gestion particulire de lextrieur de limage peuvent tre envisages est dnies
de la mme manire. Notons que vu le caractre local des oprations dans la morphologie, nous parlons
loccasion du traitement des index extrieurs au domaine de limage galement du traitement des bords
ou de la gestion des bords de limage.
4.6.4.3 chantillonnage
Pour assurer lextraction du voisinage partir des lments de limage, les accs la mmoire sont
ncessaires. Pourtant, si les index dsigns par llment structurant ne sont pas du domaine de limage,
nous devons faire appel une quelconque technique de gestion des bords, comme on vint de le dcrire
dans la section prcdente.
Il semble convenable de formaliser lchelle des fonctions du Haskell lobtention des valeurs cor-
respondant aux index concrets. Ce processus va intgrer dans un seul type de fonctions les fonctionna-
lits dindexation des lments lintrieur de larray et les fonctionnalits de traitement des valeur
lextrieur du domaine de ce dernier. Nous allons appeler ces fonctions sous un terme commun chan-
tillonnage. Ces fonction seront du type SampFnc :
SampFnc :: ( Ix ) Ar
La fonction dchantillonnage est une fonction qui nous retourne, pour un index concret du type ,
une valeur qui est du type du mme type que les lments de limage. Soit elle va incorporer le
traitement des valeurs de bords dj dans sa dnition, soit, dans le cas o nous savons explicitement que
nous nallons pas indexer les lments au-del du domaine de limage, elle na pas besoin dassurer le
traitement des bords et par consquent, elle nest pas oblige dincorporer une telle fonctionnalit.
89
Dmontrons quelques dnitions de ces fonctions qui seront utilises par la suite dans les descriptions
des algorithmes. La fonction dchantillonnage sampI qui nest spcialise qu lindexage des lments
lintrieur du domaine de limage est dnie comme :
sampI :: ( Ix ) Ar
sampI ut x = ut ! x
Remarquons que sa signature de type est compatible avec celle du type type SampFnc :
sampI :: SampFnc
La fonction sampB ne se spcialise quau traitement des bords et elle est dnie comme :
sampB :: ( Ix ) BroderFnc Ar
sampB ItJ|nt ut x = ItJ|nt ut x
Remarquons que sa signature de type est compatible avec la suivante qui utilise le type SampFnc :
sampB :: BroderFnc SampFnc
Cest--dire, elle prend une fonction traitant le bord comme paramtre et nous retourne la fonction
dchantillonnage.
La fonction sampGen assure le cas gnral o nous pouvons chantillonner avec les index concrets
inclus dans le domaine de limage mais galement avec les index qui ny sont pas inclus. Nous rutilisons
les deux fonctions prcdentes :
sampGen :: ( Ix ) BroderFnc Ar
sampGen ItJ|nt ut x = x if inRange(bounds $ut ) x then
(sampI ut x)
else
(sampB ItJ|nt ut x)
Remarquons que sa signature de type est compatible avec celle qui utilise le type SampFnc :
sampGen :: BroderFnc SampFnc
4.6.4.4 Gnralisation de lextraction du voisinage
Nous appelons les fonctions dextraction du voisinage les fonctions qui, pour un array donn et un
index donne, extraient les valeurs des lments voisins. Elle seront du type ExtrNgb qui est dni
comme :
type ExtrNgb = Ar ( I , I ) ( I , I ) [ ]
Cette faon de voir les fonctions pour lextraction du voisinage est assez gnrale pour pouvoir inclure
tous les cas possibles car elle ne se base pas, dans sa dnition, sur une liste concrte des voisins et ne
soccupe pas lchelle de ses paramtres par la gestion particulire des voisins dpassant les bords de
limage.
En effet, cest le corps de la fonction qui dnira tous ces dtails. Les fonctions que nous dnirons
par la suite seront plus spcialises, e.g. pour la grille hexagonale ou la grille carre, et auront la signature
de type diffrente. Mais aprs lapplication partielle des paramtres concrets, nous obtiendrons une
nouvelle fonction, qui sera du type ExtrNgb des fonctions dextraction du voisinage.
4.6.4.5 Extraction du voisinage des types de base
Lextraction du voisinage des types de base est assure par lutilisation de la fonction de concr-
tisation des indexes, qui est du type SpecNgb, pour une position donne po et pour les indexes de
dplacement donns npI en spciant la fonction exacte dchantillonnage qui est du type SampFnc.
Commenons par la prsentation des dnition de certaines fonction dextraction du voisinage. Pour un
travail le plus gnrique possible dextraction du voisinage, nous dnissons la fonction extrNgb :
90
extrNgb :: (Ord) SpecNgb SampFnc Ngb ExtrNgb
extrNgb pat umpI npI ut po = map (umpI$ut) (pat npI po)
Dans la pratique, nous utiliserons plutt les fonctions spcialises pour un type de grille. La dnition
de la fonction dextraction du voisinage sur la grille carre extrNgbSQR est dnie comme :
extrNgbSQR :: (Ord) SampFnc Ngb ExtrNgb
extrNgbSQR umpI npI ut po = map (umpI$ut) (specNgbSQR npI po)
Parmi les fonctions spcialises pour un travail particulier sur le voisinage, nous montrons la dnition
de la fonction extrINgbSQR qui ne teste pas si lindex du pixel extraire est inclus dans le domaine de
limage et qui est utilise pour lextraction des voisins lintrieur du domaine :
extrINgbSQR :: (Ord) Ngb ExtrNgb
extrINgbSQR npI ut po = extrNgbSQR sampI npI ut po
La fonction dont le fonctionnement est oppos cette dernire et qui, pour une liste de dplacement
donne, suppose que tous les index sont au-del du domaine de limage. Elle appelle, pour chaque index
concret, la fonction du bord ItJ| nt :
extrBNgbSQR :: (Ord) BroderFnc Ngb ExtrNgb
extrBNgbSQR ItJ|nt npI ut po = extrNgbSQR (sampB$ItJ|nt) npI ut po
Suivant la mme logique, nous pouvons dnir les fonctions dextraction du voisinage pour les grilles
hexagonales (dcales par lignes) extrNgbHEXR, extrINgbHEXR et extrBNgbHEXR en remplaant
lappel de la fonction specNgbSQR de concrtisation des index relatifs aux index absolus pour la grille
carre par lappel de la fonction correspondante. Dans le cas dune grille hexagonale dcale par les
lignes il sagit de la fonction specNgbHEXR.
4.6.4.6 Extraction du voisinage partir des vecteurs paquets
Le travail effectu lors dextraction des voisins dans le cas o les lments dun array sont les vec-
teurs paquets nest pas le mme que celui dextraction dun lment voisin scalaire. Les vecteurs de
dplacement dun lment structurant dnissent, en effet, les dplacement en units scalaires. Pourtant,
lchelle des vecteurs paquets, le groupe dlments que nous voulons obtenir comme des voisins
relatifs aux lments dun vecteur paquet peut se trouver localis partiellement dans un vecteur et par-
tiellement dans le vecteur voisin.
Cest pourquoi nous dnissons la fonction extract dextraction dun nouveau vecteur paquet
partir de deux vecteurs paquets voisins. Cette fonction correspond sur les architecture multimdia SIMD
directement aux instructions.
extract :: (Num ) I PVec I PVec I PVec I
extract o| | pv
1
pv
2
= pvec ( Io, Ii )
( [ ( i , pv
1
! ( i +o| | ) ) | i [ Io .. ( Iio| | )] ]
++ [ ( j , pv
2
! ( j Ii+o| | )) | j [ ( Iio| | +1) .. Ii ] ]
)
where ( Io, Ii ) = bounds pv
1
Le premier paramtre de cette fonction dnit le dcalage o| | , le deuxime et le troisime paramtre
dsignent deux vecteurs paquets voisins. Dans le cas spcial o la valeur doffset o| | est 0, cette fonction
nous retourne le premier paramtre pv1, dans lautre cas spcial o la valeur doffset o| | est gale la
longueur du vecteur paquet, cette fonction nous retourne le deuxime paramtre pv2. Dans le cas de
valeur o| | intermdiaire, cette fonction nous retourne, en se basant sur cette valeur, un vecteur paquet
compos partir des lments des deux paramtres pv1 et pv2 relativement cette valeur.
La fonction extract sera utilise en interne dans la fonction unaLoadSQR de la lecture non-aligne
sur la grille carre qui extrait des voisins dun array ut pour un index concret (x, ) et un vecteur de
dplacement concret (Jx, J) ; n est la taille dun vecteur paquet et la fonction ItJ| nt nous dnit la
manire dextraction des valeurs au-del de limage. Le paramtre Iov dnit par sa valeur | ou
SnJ laxe de vectorisation de larray ut. fonction
91
off
Vecteur paquet rsultant
1 2 3 4 5 6 7 8
6 7 8 1 2 3 4 5
1 2 3 4 5 6 7 8
pv1 pv2
FIG. 4.14 : Illustration du fonctionnement de la fonction extract pour les vecteurs paquets de 8 lments et la
valeur do| | gale 4
unaLoadSQR :: (Num ) [ Char] I SampFnc(PVec I )
Ar ( I , I ) ( PVec I ) ( I , I ) ( I , I ) PVec I
unaLoadSQR Iov n umpI ut (x ,) (Jx,J)
| Iov == "Fst" = extract (mod Jx n)
(umpI ut (x+( div Jx n) , +J))
(umpI ut (1+x+( div Jx n) , +J))
| Iov == "Snd" = extract (mod J n)
(umpI ut (x+Jx,+( div J n) ) )
(umpI ut (x+Jx,1++( div J n) ) )
Le processus dcrivant la lecture non-aligne sur les grilles hexagonales peut tre construit suivant la
mme logique et en respectant les particularits du travail avec les lignes/colonnes dcales.
Le principe dextraction des voisins lors du travail avec des vecteurs paquets est illustr sur la
g. 4.15 pour un exemple concret du voisinage comptant 4 voisins sur la grille carre dont les vecteurs
de dplacement sont dnis par ngbSQR4.
Regardons maintenant comment nous mettons tous ces outils pour le travail sur les vecteurs pa-
quets ensemble. Ayant dni dune faon gnrale le type de fonctions dchantillonnage, la fonction
extrNgbSQRSIMD dnit lextraction des voisins des vecteurs paquets et a le caractre dun skeleton
algorithmique car nous ne donnons pas une prescription exacte pour laccs aux lments. Pourtant, lac-
cs aux lments est bien spci par le type SampFnc et cest pourquoi nous pouvons lutiliser dans la
fonction de la lecture non-aligne unaLoadSQR sans restreindre la gnralisation. La manire exacte
de lchantillonnage nest donne quaprs la spcication de la fonction dchantillonnage umpI par
une fonction concrte.
extrNgbSQRSIMD :: (Ord) [ Char] I SampFnc(PVec I ) Ngb
ExtrNgb ( PVec I )
extrNgbSQRSIMD Iov n umpI npI ut po = map (unaLoadSQR Iov n umpI ut po) npI
4.6.5 Kernels de la morphologie mathmatique travaillant sur le voisinage local
Une fois les valeurs du voisinage local extraites (ou plus gnralement les valeurs des lments
dsigns par la liste des vecteurs de dplacement), nous appliquons une fonction locale sur ces valeurs.
La fonction est relative loprateur morphologique que nous construisons et sera du type NgbOp :
type NgbOp = ( [ ] )
Elle peut tre perue comme un kernel de rduction qui partir dune liste des valeurs cre une seule
valeur. Regardons alors les exemples des dnitions des fonctions.
Le kernel de la dilatation morphologique ngbDilate utilise en interne la fonction foldl1 pour im-
plmenter la rduction par la fonciton max du stream x des valeurs du voisinage local pour valuer le
supremum des valeurs discrtes.
ngbDilate :: (Ord) NgbOp
ngbDilate x = foldl1 max x
De la mme manire, nous dnissons le kernel de lrosion morphologique ngbErode qui utilise
la fonction min comme la fonction par laquelle nous rduisons le stream des valeurs du voisinage local
pour valuer linmum des valeurs discrtes.
92
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
Original dans la mmoire
snd
f
s
t
offset
offset
Extraction des voisins de gauche
Extraction des voisins de droite
Voisins de gauche
offset
offset
Rsultat est la liste des vecteurs paquets qui est traite par le noyau du calcul
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
1
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7 8
2 3 4 5 6 7 8
1
Pixels centraux
Voisins de droite
Voisins de gauche
Voisins de haut
Voisins de droite
Voisins de bas
lment structurant
FIG. 4.15 : Extraction des voisins partir dun type vector paquet
93
ngbDilate :: (Ord) NgbOp
ngbDilate x = foldl1 min x
Pour le travail avec les valeurs SIMD, nous allons utiliser les fonctions maximum et minimum op-
rant par lment sur les vecteurs paquets, exprimes respectivement par la fonction maxSIMD :
maxSIMD :: (Ord) PVec I PVec I PVec I
maxSIMD pv
1
pv
2
= listArray (bounds $pv
1
)
( zipWith max (elems$pv
1
) (elems$pv
2
) )
et par la fonction minSIMD :
minSIMD :: (Ord) PVec I PVec I PVec I
minSIMD pv
1
pv
2
1
)
( zipWith min (elems$pv
1
) (elems$pv
2
) )
Ces fonctions correspondent directement aux instructions sur les architectures possdant un jeu dins-
tructions incluant les oprations SIMD. Ainsi, la dnition du kernel local de la dilatation morphologique
ngbDilateSIMD qui opre sur les vecteurs paquets est dnie comme :
ngbDilateSIMD :: Ord NgbOp ( PVec I )
ngbDilateSIMD x = foldl1 maxSIMD x
et le kernel local de lrosion morphologique ngbErodeSIMD pour les mmes lments comme :
ngbErodeSIMD :: Ord NgbOp ( PVec I )
ngbErodeSIMD x = foldl1 minSIMD x
4.6.6 Oprations du voisinage local avec un masque
Le travail sur le voisinage local o la propagation des valeurs est restreinte par une fonction du
masque ajoute une nouvelle valeur dentre pour le traitement. Ainsi, les kernels de calcul seront du type
NgbGOp :
type NgbGOp = ( [ ] )
Par consquent, les oprations locales godsiques sont dnies comme fonctions qui utilisent en
interne les kernels classiques de la morphologie mathmatique mais ils appliquent sur leurs rsultats
la fonctions implmentant la godsie. Le kernel de la dilatation morphologique godsique est dni
comme ngbGDilate :
ngbGDilate :: (Ord) NgbGOp
ngbGDilate x mI = min mI (ngbDilate x)
et nous dnissons, suivant le mme principe, aussi la fonction du kernel de lrosion morphologique
godsique :
ngbGErode :: (Ord) NgbGOp
ngbGErode x mI = max mI (ngbDilatex)
4.6.7 Travail sur le voisinage avec les superpixels
Toutes les techniques de traitement du voisinage local que nous avons prsentes (ou de traitement
des pixels dsigns par la liste des vecteurs de dplacement) sont transposables au travail avec les su-
perpixels, q.v. le concept des superpixels dcrit dans 4.4.5, page 73. Pourtant, si nous ne travaillons pas
avec les pixels reprsents par les lments de base dun array mais nous manipulons des entits plus
grandes reprsentes par des groupes des pixels, toutes les fonctions entrant en jeu lors de la dnition
dlment structurant, de lextraction du voisinage et sa reprsentation en tant que stream et lors du calcul
morphologique sur ces streams issus des superpixels seront plus complexes dans leurs fonctionnement.
94
Ces fonctions ne seront pas, en effet, aussi simples dnir que ctait le cas pour les fonctions
travaillant sur les lments de base. Leurs dnitions exactes, qui peuvent tre trs dpendantes des ca-
pacits spciques dune architecture, de la forme de llment structurant ou des dimensions de limage,
sont dnir spciquement lors de limplmentation concrte dun algorithme.
Cependant, les dnitions de type de ces fonctions exprimant les entres et les sorties des kernels
de calcul lors de traitement des ux de donnes sont sufsantes pour pouvoir dnir les skeletons algo-
rithmiques. Cest pourquoi nous ne prfrons de dsigner cette place les fonctions travaillant sur les
superpixels que par leurs signatures de type. Cest cette signature qui sera utilise pour la description et
pour la comprhension de nos skeletons algorithmiques.
Pour pouvoir extraire le voisinage dun superpixel dcrit par son index dancrage, nous allons avoir
besoin des fonctions qui seront du type ExtrNgbSP :
type ExtrNgbSP = Ar ( I , I ) ( I , I ) [ ]
Il sagit, en effet, de la signature de type qui est compatible avec le type ExtrNgb pour lextraction du
voisinage dun lment de base. La diffrence est dans linformation smantique que porte ce nouveau
type ExtrNgbSP et qui nous dit explicitement que nous travaillons avec les superpixels et que lindex
donn par (I, I) est lindex dancrage dun superpixel. Elle nous indique galement que le stream de sortie
peut tre large si on le compare avec le stream qui est gnr par les fonctions travaillant sur les lments
de base.
Les fonctions qui vont travailler avec ce stream large et vont y appliquer la fonction locale de la
morphologie seront dsignes par le type NgbOpSP :
type NgbOpSP = ( [ ] [ ] )
Ces fonctions vont prendre un stream des pixels composant le voisinage dun superpixel et vont retourner
galement un stream, celui tant le stream des valeurs constituant le superpixel. Nous mettons cela en
contraste avec des fonctions du type NgbOp, cf. 4.6.5, page 92 travaillant sur le voisinage classique qui
ne retournent quune simple valeur.
Ainsi, nous avons prsent tous les outils ncessaires pour pouvoir dcrire les skeletons algorith-
miques travaillant sur les superpixels. Ces outils sont reprsent par les fonctions de
pasage dun array un stream des index dancrage des superpixels (cf. 4.4.5.2) qui sont du type
StreamizeSP,
extraction du voisinage dun superpixel qui sont du type ExtrNgbSP, comme dcrit ci-dessus,
opration locale sur le voisinage qui sont du type NgbOpSP, comme dcrit ci-dessus,
passage partir dune liste des lments dun superpixels et de son index dancrage aux tuples
(index dlment de base, valeur dlment de base) qui sont du type ZipSP, cf. 4.4.5.2, page 75.
et nous allons les rutiliser dans la suite de cette thse dans les algorithmes et les skeletons algorithmiques
spciques aux superpixels.
95
Partie II
Algorithmes
et les skeletons algorithmiques
CHAPITRE 5
Algorithmes de voisinage
non dpendants du sens du parcours
Ce chapitre sera consacr aux oprations de base de la morphologie mathmatique qui travaillent
localement sur le voisinage dun pixel ou sur un autre groupe de pixels dni par llment structurant
et o les rsultats que nous obtenons sont indpendants de lordre dans lequel les pixels sont traits.
Nous parlons ainsi des oprations indpendantes du sens du parcours de limage. Il sagit, en effet,
dun groupe des oprations ensemblistes constituant un des piliers de la morphologie mathmatique qui
sont largement utilises dans dautres algorithmes plus complexes ; cela seffectue trs frquemment
dune faon rptitive (citons comme exemple
Beu90
les oprations godsiques, le SKIZ et la ligne de
partage des eaux (LPE) par SKIZ). Limplmentation directe de la dnition de ces oprations et des
oprations drives de ces dernires nous conduit aux procds utilisant abondamment des oprations
morphologiques de base et des fonctions logiques.
Cest pourquoi il est primordial de pouvoir excuter ces oprations le plus efcacement possible sur
une architecture donne. On ressent ce besoin en particulier lors dun traitement pour les applications
en temps rel o le temps du calcul est trs prcieux et nous ressentons ce besoin dautant plus si nous
utilisons un matriel embarqu pour lexcution. Dans le cas contraire, nous pourrions nous retrouver
avec des temps de traitement non satisfaisants pour un algorithme compos qui fait appel plusieurs
dizaines, centaines ou mme des milliers ditrations de ces oprations de base.
Nous allons prsenter les algorithmes qui dcrivent la faon gnrale du calcul de ces oprations
et puis, nous montrerons des approches plus efcaces au calcul de ces oprations sur les architectures
avec les capacits SIMD. Plus loin dans ce chapitre, nous allons galement prsenter les approches qui
rendent possible lvaluation de ces oprations sur les GPU.
Vu que les oprations morphologiques sur le voisinage local entrent entirement dans la logique du
calcul avec les kernels dexcution, nous transposons leur traitement en traitement en ux de donnes.
Sachant que cest le principe qui est important, nous nallons prsenter dans la suite que les skeletons
algorithmiques de travail sur le voisinage. Un tel skeleton sera exprim formellement par une fonction
du lambda calcul. Les oprations spciques de la morphologie mathmatique seront obtenues par la
spcialisation de fonctionnement de ces skeletons pour des cas dutilisation particulire.
5.1 Algorithmes lmentaires pour les GPP
5.1.1 Approche nave limplmentation des oprations sur le voisinage
La construction la plus simple dun algorithme travaillant sur le voisinage nous conduit limpl-
mentation que nous appelons approche nave. Lappellation nave est due au fait que nous utilisons la
fonction gnrique pour extraire un pixel et ses voisins, une fonction qui est complexe et qui effectue
99
pour chaque pixel tous les tests de dpassement de bord de limage ou de parit de ligne/colonne. Le
terme nave na pas un sens pjoratif et dsigne la mthode la plus simple possible qui peut galement
tre la plus convenable dans la mesure o nous voulions un outil gnrique et rapidement utilisable et
nous ne nous focalisions pas prioritairement sur les performances mais plutt sur le fonctionnement.
5.1.1.1 Skeleton algorithmique ngbAlgo de lapproche nave au travail sur le voisinage
Nous commenons notre explication par la prsentation du skeleton algorithmique ddi la construc-
tion des algorithmes concrets travaillant sur le voisinage. Il se dcompose en quatre phases. Dans la pre-
mire, nous passons dun array 2D un stream des index ; dans la deuxime, nous extrayons le voisinage
local, dans la troisime nous appliquons le kernel travaillant sur le voisinage qui dsigne lopration
morphologique et dans la quatrime et dernire phase, nous reconstituons larray de sortie partir du
stream.
Algorithme 5.1 : ngbAlgo, skeleton algorithmique de lapproche nave pour le travail sur le voisi-
nage
1 ngbAlgo :: Streamize ExtrNgb NgbOp Ar ( I , I ) Ar ( I , I )
2 ngbAlgo tm axt op ut = array (bounds ut )
3 ( ( zip ix )
4 (map op)
5 (map (axt ut ) )
6 $ix )
7 where ix = tm$ut
Lalgorithme 5.1 prsente, par la fonction ngbAlgo, la structure de ce skeleton. Il prend quatre argu-
ments dont le premier, tm qui est du type Streamize , dsigne la manire dont on parcourt limage,
autrement dit, il sagit dune fonction qui retourne un streamdes index dans un ordre choisi. Le deuxime,
axt qui est du type ExtrNgb , dsigne la fonction dextraction des lments du voisinage. Cet argu-
ment est puissant car trs gnral et nous expliquerons plus tard les ventualits de son utilisation. Le
troisime argument, op qui est du type NgbOp , dsigne la fonction de lopration locale sur le voisi-
nage et correspond une opration morphologique que nous voulons effectuer. Le quatrime paramtre,
ut, dsigne larray dentre qui contient notre image traiter.
ar
(Array
dentre)
Array
de sortie
array
bounds
Streamize ExtrNgb NgbOp zip
FIG. 5.1 : Graphe de ux exprimant le fonctionnement du skeleton algorithmique ngbAlgo
Le fonctionnement de ce skeleton est assez simple et nous le prsentons sur la g. 5.1 en tant que
diagramme de ux. Tout dabord (ligne 7), nous obtenons un stream des index par lapplication de la
fonction tm sur larray dentre ut. Vu que le sens de parcours nest pas substantiel dans les traitements
dnis par ce skeleton, la seule obligation pose sur la fonction tm est quelle doit parcourir toute
limage, lordonnancement exact des index dans le stream nest pas important.
Sur chaque lment de ce stream (ligne 6), nous appliquons sur la ligne 5 (en utilisant la fonction
map) la fonction axt qui reprsente le kernel dextraction du voisinage et qui retourne, pour un index
donn, une liste des lments qui constituent le voisinage dun index donn dans larray ut. Il faut prci-
ser que dans la morphologie mathmatique, la structure de cette liste est dnie par llment structurant,
100
Jaromr BRAMBOR 5.1. ALGORITHMES LMENTAIRES POUR LES GPP
et elle peut contenir ainsi (ou pas) le pixel mme, ses voisins mais galement les pixels qui sont plus loi-
gns des voisins les plus proches du pixel concern. Malgr ce fait, nous parlons du voisinage local (ou
de local neighborhood en anglais). Et cest, en effet, la fonction axt qui assure tout en ce qui concerne
la notion du voisinage, le type de la grille, la manire dont on gre les effets de bord et la manire exacte
de lchantillonnage des pixels dans limage. Ainsi, nous obtenons un stream large dont les lments
sont les listes composes des pixels formant le voisinage.
Sur tous les lments de ce stream large, nous appliquons, sur la ligne 4, la fonction map qui se
charge dexcuter le kernel de lopration morphologique op. Il sagit, en effet, dun kernel de rduction,
cf. 3.4.1.2, page 45, qui calcule une nouvelle valeur pour lindex donn partir dun ensemble des voisins.
Nous obtenons un stream des rsultats auquel nous ajoutons (ligne 3) linformation sur la position par la
fonction zip avec le stream des index ix comme argument. Le rsultat de cette opration est un stream
des tuples (index, valeur) partir duquel nous reconstituons, sur la ligne 2, un array de sortie par la
fonction standard array.
Il faut prciser que nous avons obtenu un skeleton algorithmique qui est trs gnral et dont nous
pouvons driver beaucoup de cas particuliers. Il dcrit le principe de fonctionnement et nexhibe pas
explicitement les dtails secondaires. Ainsi, la grande partie du travail lourd nest pas expose et reste
dnir par lutilisateur lors de la spcialisation de ce skeleton travers la fonction dextraction du
voisinage ExtrNgb .
5.1.1.2 Algorithmes concrets utilisant le skeleton algorithmique ngbAlgo
Une fois la structure du mode oprationnel de lapproche nave de travail sur le voisinage prsente,
nous allons procder la construction des algorithmes concrets et utilisables en pratique par la spciali-
sation de ce skeleton.
Mais tout dabord, il faut ajouter une prcision concernant lextraction du voisinage. Lextraction
dun pixel partir dun array 2D est simple. Pour pouvoir extraire les valeurs des pixels voisins ce
dernier, nous avons besoin de dterminer certains dtails. Pour les applications travaillant sur le voisinage
local dans le domaine digitalis
1
, il sagit notamment :
du voisinage utilis 4, 6, 8 voisins ou autres, reprsents par les index relatifs,
du type de la grille hexagonale, carre ou spcique (graphes de voisinage particuliers), repr-
sent, en gnral, par la fonction qui met en correspondance les index relatifs dsignant les voisins
avec lemplacement exact des voisins dans larray dentre,
de la faon de grer les effets de bord valeur de bord constante, valeur du voisin le plus proche
dans limage, gestion particulire du voisinage aux bords, etc.
Cest la fonction dextraction du voisinage qui assure toutes ces activits. Elle nous retourne, pour
chaque index concret qui localise une position lintrieur de larray, une liste des valeurs des pixels
dsignes par llment structurant. Cette liste, qui est le seul argument dentre lopration morpholo-
gique sur le voisinage, peut tre perue par certains algorithmes comme un stream o lordonnancement
nest pas important (e.g. dilatation morphologique), mais nous pouvons utiliser avec avantage la notion
de lordre dans cette liste dans dautres algorithmes (e.g. la transformation tout ou rien).
Expliquons cette implmentation (dnie par la fonction dilSQR) sur un exemple prcis de la di-
latation morphologique sur la grille carre par un lment structurant de 4 voisins. Nous allons utiliser
la fonction dextraction des voisins extrNgbSQR qui est spcialise pour la grille carre. Le voisinage
est dni par la liste des dplacements relatifs pour un point et ses 4 voisins ngbSQR4. La fonction de
traitement des bords que nous avons choisie, cBorder, reprsente le bord de limage dont la valeur est
constante, cest--dire que cette fonction nous retourne pour tous les index la valeur de son premier argu-
ment ItJvuI. Lopration de dilatation morphologique est assure par le kernel de rduction du stream
des voisins, ce kernel est exprim par la fonction ngbDilate. Le dernier point prciser est lutilisation
1
Notons que ce principe est utilis dans le champs plus large des applications et ne se restreint pas seulement la Morpho-
logie mathmatique
101
de la fonction standard du Haskell indices en tant que fonction de parcours de limage. En effet, nim-
porte quelle autre fonction de parcours de limage pourrait tre utilise dans ce cas car nous crons ici
les algorithmes non-dpendants du sens du parcours de limage.
Voici la dnition de la fonction dilSQR :
dilSQR :: (Ord) Ngb Ar ( I , I ) Ar ( I , I )
dilSQR ItJvuI npI ut = ngbAlgo indices (extrNgbSQR ( cBorder ItJvuI ) npI) ngbDilate ut
De la mme manire nous pouvons dnir toutes les autres oprations morphologiques dont le fonc-
tionnement nest pas dpendant du sens du parcours. Par exemple, la dilatation morphologique pour la
grille hexagonale et le 6-voisinage, prsente par la fonction dilHEXR :
dilHEXR :: (Ord) Ngb Ar ( I , I ) Ar ( I , I )
dilHEXR ItJvuI npI ut = ngbAlgo indices (extrNgbHEXR ( cBorder ItJvuI ) npI) ngbDilate ut
Nous pouvons voir que ce nest que la fonction dextraction de voisinage (extrNgbHEXR) qui a chang
dans cet algorithme par rapport lalgorithme dilSQR travaillant sur la grille carre. Le kernel de rduc-
tion qui assure lopration morphologique effectue sur ce voisinage est rest le mme (ngbDilate).
5.1.2 Division du problme en traitement de lintrieur et en traitement du bord
La premire des implmentations plus labores de travail sur le voisinage consiste sparer le
traitement de lintrieur et le traitement du bord. Il sagit, en effet, didentier lensemble des index
des pixels dont le voisinage est inclus entirement dans limage. Pour ces pixels, nous pouvons utiliser
lextraction directe sans nous proccuper du travail spcial effectue aux bords de limage. Les voisins
des pixels restants sont ceux qui ont au moins un voisin au-del des bords et lalgorithme dextraction
des voisins, spcique pour le traitement des bords, peut y tre appliqu.
Quelle est la raison qui nous pousse effectuer cette division ? Dmontrons-la sur lexemple de la
fonction sampGen dchantillonnage gnral. Sa dnition (q.v. page 90) contient un test conditionnel :
x if inRange(bounds $ut ) x then
(sampI ut x)
else
(sampB ItJ|nt ut x)
Nous y testons si lindex qui dsigne un pixel extraire est lintrieur de larray. Si tel est le cas, nous
procdons lchantillonnage de limage de limage sampI. Dans le cas contraire, cest--dire dans le
cas o lindex pointe au-del des bords de larray, nous appelons une fonction dchantillonnage sampB
qui traite les effets de bords par la fonction ItJ|nt avec lindex x comme paramtre et qui nous fournit
la valeur correspondante. Lide que nous exploitons en divisant le traitement en deux parties est la
suivante : le test qui, dans lapproche nave, tait incorpor dans la fonction dextraction du voisinage, est
dplac lchelle de larray. Ce que nous faisons cest la division de larray une zone (de lintrieur)
o la condition dcrite ci-dessus est toujours valable pour tous les pixels du voisinage et une zone
rsiduale (du bord) o cette condition nest pas remplie pour au moins un index du voisinage.
Il est vident que pour la plupart des lments structurants utiliss couramment en pratique dont la
taille est largement plus petite que les dimensions de limage, la zone de lintrieur contiendra une trs
grande portion des pixels et il est donc prfrable de spcialiser le traitement pour cette zone. Le gain
que nous pouvons russir obtenir avec une telle approche est dpendant du fonctionnement de notre
architecture car certaines architectures assurent lexcution de ce type de condition efcacement et sans
dlai supplmentaire. Mais il est galement vident que sil faut tester les dpassements du bord pour
tous les index dun lment structurant et pour tous les pixels de limage avec succs par la condition
if inRange(bounds $ut ) x then
qui est, pour une donne x de deux dimensions, assure en gnral par 4 instructions de test (plus grand
/ plus petit dans la premire / deuxime dimension), il serait plus avantageux de pouvoir viter ce test,
au moins, sur une partie de limage. Sachant que la majorit des pixels convient cette condition, toutes
102
les 4 valuations lmentaires sont effectues ici sur un volume important de donnes et, comme nous le
prsentons par la suite, ces valuations peuvent tre vites.
Intrieur
du domaine lment
structurant
domaine D
(a) rosion par llment structurant
Intrieur
du domaine
bounding box
de llment
structurant
domaine D
(b) rosion par le bounding box de
llment structurant
FIG. 5.2 : Identication de lintrieur du domaine de limage par lrosion morphologique, les rsultats pour
llment structurant et son bounding box employ comme lment structurant sont identiques
Trouver lintrieur du domaine pour nimporte quel lment structurant nest pas difcile car il cor-
respond au rsultat de lrosion morphologique du domaine par llment structurant que nous voulons
employer dans lopration morphologique. De plus, ce rsultat est identique celui de lrosion du do-
maine par son bounding box. La gure 5.2 illustre cette proprit qui nous permettra de dterminer
numriquement et en se basant seulement sur les dimensions de limage et du bounding box la zone de
lintrieur du domaine dans laquelle llment structurant utilis ne dpasse pas les bords, cf. g. 5.3.
Array
dorigine
Zone
de lintrieur
Bounding box
dlment
structurant
Zone du bord
snd
f
s
t
FIG. 5.3 : Division dun array la zone de lintrieur et la zone du bord
La fonction ngbBB se charge de la dtection du bounding box partir de la liste des dplacements
vers les voisins. Le rsultat de cette fonction est une tuple des bornes minimales et maximales dans les
deux directions.
ngbBB :: Ngb ( ( I , I ) , ( I , I ) )
ngbBB ( (| , ) : x) = ngbBB x ( (| , ) , (| , ) )
where
ngbBB ( ( |x , x) : x) ( ( |Io , Io) , ( |Ii , Ii ) )
= ngbBB x ( (min |x |Io , min x Io) , ( max |x |Ii , max x Ii ) )
ngbBB [ ] II = II
Ainsi, nous pouvons dnir une nouvelle implmentation de travail sur le voisinage qui divise le
traitement de larray en deux parties, la partie du traitement de lintrieur et la partie du traitement du
bord. Pour cela, nous divisons limage en deux zones, en zone de bord et en zone de lintrieur, comme
prsent sur la g. 5.4.
Le skeleton algorithmique ngbAlgoIB prsent par lalgorithme 5.2 nous montre la structure de ce
traitement. Son fonctionnement est dductible partir de la structure du skeleton algorithmique de lap-
proche nave que lon a prsente dans 5.1.1.1. la place dutiliser une seule fonction de parcours de
limage, nous en utilisons deux, une pour la zone intrieure de notre domaine, tm|, une pour la zone
103
Zone du bord
snd
f
s
t
FIG. 5.4 : Dcomposition du traitement de limage en traitement de bord et en traitement de la zone intrieure
du bord de notre domaine, tmB. Celles-ci sont reprsentes dans la signature du type de la fonction
ngbAlgoIB par le type Streamize . Remarquons que pour les algorithmes que nous dcrivons dans ce
chapitre, le sens du parcours de ces zones nest pas signiant.
Algorithme 5.2 : ngbAlgoIB, skeleton algorithmique de travail sur le voisinage qui divise le trai-
tement en deux parties, traitement dans la zone du bord et dans la zone de lintrieur
1 ngbAlgoIB :: Streamize ExtrNgb
2 Streamize ExtrNgb
3 NgbOp Ar ( I , I ) Ar ( I , I )
4 ngbAlgoIB tm| axt| tmB axtB op ut = array (bounds ut )
5 $ ( ( ( zip ixB)
6 (map op)
7 (map (axtB ut ) )
8 $ixB )
9 ++(
10 ( zip ix| )
11 (map op)
12 (map ( axt| ut ) )
13 $ ix| )
14 )
15 where ixB = tmB ut ; ix| = tm| ut
La division en deux parties concerne galement les fonctions dextraction du voisinage qui sont
du type ExtrNgb dans la signature du type de la fonction ngbAlgoIB. Ainsi, nous pouvons avoir
deux fonctions dextraction du voisinage, une spcialise pour la zone de lintrieur, axt|, la deuxime
adapte lextraction dans la zone du bord, axtB. En revanche, le kernel de voisinage op reste le mme
pour les deux manires de traitement et la construction de larray de sortie est semblable celle de
lapproche nave. Le graphe de ux prsent sur la gure 5.5 dmontre graphiquement la structure du
skeleton algorithmique ngbAlgoIB sur des blocs fonctionnels et leur interconnexions.
ar
(Array
dentre)
Array
de sortie
strmI extrI NgbOp
array
bounds
zip
strmB extrB NgbOp zip
++
FIG. 5.5 : Graphe de ux exprimant le fonctionnement du skeleton algorithmique ngbAlgoIB
104
5.1.2.1 Algorithmes concrets utilisant le skeleton algorithmique ngbAlgoIB
Nous dmontrons lutilisation pratique du skeleton algorithmique ngbAlgoIBsur les mmes exemples
que ceux prsents pour lapproche nave.
La dilatation par un lment structurant sur la grille carre avec la valeur de bord constante en utilisant
la division du traitement en traitement de lintrieur et en traitement du bord est prsente par la fonction
dilIBSQR :
dilIBSQR :: (Ord) Ngb Ar ( I , I ) Ar ( I , I )
dilIBSQR ItJvuI npI ut =
ngbAlgoIB( streamI II) (extrINgbSQR npI)
( streamB II) (extrBNgbSQR ItJ|nt npI) ngbDilate ut
where II = ngbBB npI; ItJ|nt = cBorder ItJvuI
Nous pouvons constater que nous utilisons une double approche au traitement. Les fonctions de par-
cours de limage sont maintenant distinctes et sont devenues complexes car elles utilisent la fonction
ngbBB pour dterminer le bounding box de llment structurant mais ce sont galement les fonctions
dextraction de voisinage qui sont maintenant distinctes.
Nous dnissons de la mme manire la dilatation morphologique pour la grille hexagonale et le
6-voisinage avec la valeur de bord constante et travaillons en divisant le traitement en traitement de
lintrieur et du bord. Elle est prsente par la fonction dilIBHEXR :
dilIBHEXR :: (Ord) Ngb Ar ( I , I ) Ar ( I , I )
dilIBHEXR ItJvuI npI ut =
ngbAlgoIB( streamI II) (extrINgbHEXR npI)
( streamB II) (extrBNgbHEXR ItJ|nt npI) ngbDilate ut
where II = ngbBB npI; ItJ|nt = cBorder ItJvuI
Suivant la mme logique, nous pouvons dnir toutes les autres oprations morphologiques de base.
5.1.3 Gnralisation du travail sur le voisinage
La spcialisation du traitement de limage lors du travail avec les lments structurants peut aller
encore plus loin que la division en deux zones comme prsente dans la section prcdente 5.1.2.
Nous pouvons, en effet, choisir autant de zones particulires quil nous convient pour notre traite-
ment. Ces zones vont correspondre la spcialisation de traitement pour certains index dans limage
pour lesquelles les congurations de la position dlments structurants et des bords sont particulires.
Dans notre logique, cette spcialisation essaie de minimiser les besoins dchantillonnage inutile au-del
de limage et nous fournit les procdures adaptes ce but. La gure 5.6 nous montre un exemple dune
possible fragmentation du domaine de larray.
Zone du bord
snd
f
s
t
FIG. 5.6 : Dcomposition du traitement de limage plusieurs zones dans lesquelles les traitements distincts
peuvent tre effectus
De plus, pour certaines oprations morphologiques, nous pouvons modier non seulement le par-
cours et la manire dextraire des voisins, mais galement lopration sur le voisinage sans changer
lexactitude du rsultat nal. Un bon exemple de cette situation est la dilatation locale du pixel plac dans
le coin de limage par llment structurant dont plusieurs vecteurs de dplacement pointent lextrieur
105
du domaine de limage, cf. g. 5.7(a). Si la valeur de bord est constante et indpendante de la position de
llment structurant et si lopration arithmtique ou logique de base que nous nous apprtons appli-
quer par la suite sur le voisinage local est idempotente envers les valeurs de bord, e.g. max(x, x) = x, il
semble inutile dappliquer lchantillonnage de lextrieur de limage plus quune fois. Ainsi, nous pou-
vons pargner le temps du calcul lors de lchantillonnage du voisinage mais galement lors du calcul de
lopration morphologique locale sur ce dernier.
La g. 5.7(b) nous montre, sur un exemple concret de la grille carre et de 8-voisinage, la manire
dont nous pouvons modliser ce travail. Cette image est mise en contraste par rapport la manire clas-
sique dchantillonnage du voisinage local pour les pixels touchant le bord de limage qui est prsente
sur la g. 5.7(a). Lors du travail avec llment structurant modi, nous crons une couche imaginaire
des valeurs de bord qui est reprsente sur la g. 5.7(b) superpose limage. Une seule valeur de bord
est dlivre lors de lvaluation des pixels touchant les bords de larray. Ainsi, la fonction dchantillon-
nage ne nous retourne que 5 valeurs du voisinage local la place de 9 lors du travail classique et nous
obtenons un stream moins large.
lment
structurant
Array
(a) Manire standard dappliquer lment structurant
lment structurant
modifi avec une seule
valeur du bord
Array
Couche imaginaire des valeurs de bord
(b) Application dun lment structurant modi qui assume une
seule valeur de bord par pixel touchant le bord
FIG. 5.7 : Exemple de la modication de llment structurant lors du traitement dun pixel du coin de limage
convenable aux dilatations / rosions o une seule valeur de bord est assume.
Dans le cas gnral, la fonction de traitement de voisinage local qui travaille avec ce stream doit
tre adapte pour un tel traitement ce qui se traduit par le besoin de pouvoir spcier non seulement la
fonction de parcours de limage et la fonction dchantillonnage mais galement la fonction travaillant
sur le voisinage local pour des zones distinctes dans limage. Ce qui nous conduit la dnition dun
nouveau skeleton algorithmique qui nous permettra de traiter spciquement chacune des zones sur
lesquelles nous avons fractionn notre image.
5.1.3.1 Skeleton algorithmique gnralis de travail sur le voisinage ngbAlgoGen
Le skeleton algorithmique gnralis de travail sur le voisinage nous permet dexprimer dune faon
formelle la possibilit de diviser le traitement le plus gnral possible, que nous avons prsent dans
106
5.1.1, page 99, en traitements plus spciques ou mme en certain nombre des traitements entirement
adapts un cas particulier. Ce skeleton est reprsent par la fonction ngbAlgoGen dans lalgorithme
5.3.
Algorithme 5.3 : ngbAlgoGen, skeleton algorithmique gnralis de travail sur le voisinage
1 ngbAlgoGen :: [ Streamize ] [ ExtrNgb ] [ NgbOp ] Ar ( I , I ) Ar ( I , I )
2 ngbAlgoGen tm axt op ut = array (bounds ut ) (computetm axt op ut )
3 where
4 compute [ ] [ ] [ ] ut = [ ]
5 compute (: ) (a:a) (o:o) ut =
6 ( ( zip ( ut ) )
7 (map o)
8 (map (a ut ) )
9 $ ( ut )
10 )
11 ++(compute a o ut )
Son fonctionnement exact suit le principe de fonctionnement du skeleton ngbAlgoIB (cf. page 104)
qui divisait le traitement en deux parties. Le skeleton que nous prsentons cette place largit les possi-
bilits de traitement spcique et pour assurer cela, il travaille avec les listes des fonctions de parcours
de limage, dextraction du voisinage et des kernels assurant lopration sur le voisinage.
La division de limage en zones est assure par lensemble des fonctions de parcours de limage
tm qui sont du type [Streamize ] et qui dsignent ces zones par un stream des index. Cette division
a la notion de segmentation avec laquelle nous travaillons couramment en morphologique mathmatique
lors de traitement du contenu des images. Ce qui est fractionn par la segmentation, cest le domaine de
limage, cest--dire lensemble des index dsignant les pixels dans limage. Le critre de la segmentation
que nous utilisons ici est luniformit du calcul effectuer. Donc, nous cherchons des zones o nous
pouvons effectuer le traitement par la mme fonction dextraction du voisinage et le mme kernel de
rduction qui assurerait lopration morphologique lchelle locale. Ainsi, nous posons les restrictions
sur le fonctionnement de ces fonctions de parcours : nous exigeons une intersection vide entre les zones
et nous exigeons que lunion de ces zones compose le domaine complet de limage.
Les fonctions dextraction du voisinage qui sont appliques spciquement dans chacune des zones
sont indiques par la liste axt qui est du type [ExtrNgb ] et les fonctions de lopration sur le voisinage
sont exprimes par la liste op qui est du type [NgbOp ]. Larray dentre est spci par largument
ut.
Le corps de ce skeleton utilise, sur les lignes 6 9, une expression que nous connaissons dj du
skeleton de lapproche nave, cf. lalgorithme 5.1, page 100, et de lapproche qui divisait le domaine
de limage en deux zones, cf. lalgorithme 5.2, page 104. Mais il lencapsule ici dans la fonction interne
compute qui traite les trois streams des fonctions dune faon rcursive et pr-compose le streamrsultant
des tuples (index, valeur) par la fonction de la composition des stream ++ (ligne 11). Ce stream des
rsultats partiels sert la n du traitement la composition de larray de sortie par la fonction array sur
la ligne 2. Notons que lexpression sur la ligne 4 :
compute [ ] [ ] [ ] ut = [ ]
dsigne la n de la rcursion de la fonction compute pour le cas spcial des arguments o les trois streams
dentre sont vides.
La gure 5.8 nous montre linterprtation graphique du fonctionnement de ce skeleton.
107
ar
(Array
dentre)
Array
de sortie
strm
N
extr
N
NgbOp
N
array
bounds
zip
strm
0
extr
0
NgbOp
0
zip ++
strm
1
extr
1
NgbOp
1
zip ++
strms extrs ops
compute
++[]
FIG. 5.8 : Graphe de ux exprimant le fonctionnement du skeleton algorithmique ngbAlgoGen de traitement
gnral de voisinage
5.1.4 Approche des superpixels, algorithmes aux kernels complexes qui exploitent la
localit des donnes
Le travail pixel par pixel que nous avons utilis jusqu prsent dans nos skeletons algorithmiques
et qui sera utilis aussi dans tous les algorithmes spciques de la morphologie mathmatique drivs
de ces skeletons, est seulement une des possibilits. Il sagit du travail qui suit quasi-directement les
dnitions de base des oprations morphologiques et mme sil est facilement transposable aux archi-
tectures massivement parallles, il est loin dtre le plus intressant du point de vue de la structure dun
algorithme et, surtout, du point de vue des performances.
Une catgorie des algorithmes, frquemment utiliss dans la pratique, emploie les lments struc-
turants particuliers qui ont la forme dun disque (ou dune boule) unit. Dans lespace digitalis, nous
employons les lments structurants qui approximent la boule unit et qui, pour la grille donne, dsi-
gnent les voisins dun pixel. Ces algorithmes sont largement utiliss dans les algorithmes godsiques.
Cette catgorie des algorithmes morphologiques utilise les donnes proches dun pixel dans lespace 2D
et sont, lors du traitement, stockes dans la mmoire cache la plus rapide ou prsents dans les registres.
Ainsi, un instant du traitement, nous disposons dun accs aux donnes le plus rapide qui puisse tre.
La localit spatiale dun groupe de pixels qui se partagent mutuellement une partie de leurs voisins
est un phnomne qui nest surtout pas ignorer. Il est donc vident que nous avons la volont dexploiter
au maximum la localit de ces donnes et, sur certaines architectures, galement leur prsence dans les
registres lors du traitement. Ainsi, il serait beaucoup plus intressant de travailler avec un certain groupe
de pixels la fois plutt que de les traiter en employant la mthode pixel par pixel. Il serait intressant
lors dun tel traitement de pouvoir rutiliser certaines des valeurs des voisins dun pixel qui ont t dj
extraites de limage et peut-tre mme de rutiliser les rsultats partiels des oprations du voisinage.
Le phnomne dextraction des valeurs des pixels voisins, plus prcisment des pixels qui sont dsi-
gns par llment structurant, entre galement en jeu. Lextraction du voisinage se modie dans ce cas et
nous procdons, en effet, lextraction du voisinage de ce groupe de pixels. Nous pouvons percevoir ce
travail galement comme le travail sur le voisinage local, mme si la notion "local" concerne maintenant
tout un groupe de pixels et le terme "local largi" serait plus appropri.
Si nous percevons lextraction de tels groupes de pixels comme le traitement en stream avec un kernel
dextraction, le calcul morphologique sur ce voisinage local largi peut galement tre peru comme le
calcul par un kernel de traitement. Dans ce cas, le kernel sera adapt au traitement de tout un groupe de
108
pixels et son fonctionnement sera dcrit par une fonction plus complexe que celles que lon a pu voir lors
de traitement dun voisinage dun seul pixel (e.g. fonction ngbDilate, page 92).
Puisque cette manire de travailler suit la logique du traitement pixel par pixel dcrit prcdemment,
nous avons dcid demployer dans ces algorithmes le concept des superpixels dont le traitement aura une
structure semblable celle dun seul pixel. Rappelons que le concept des superpixels est formellement
introduit dans la section 4.4.5, page 73, du chapitre 4 qui est consacr au formalisme fonctionnel adopt
pour la morphologie mathmatique.
Il faut noter que le traitement dun superpixel est un traitement spcialis et en tant que tel, il exige
une implmentation particulire pour un lment structurant donn et, par consquent, il demande beau-
coup plus deffort lors du dveloppement pour sa mise en uvre. Pour poursuivre lexplication des
algorithmes pour les superpixels, nous allons, tout dabord, dnir un skeleton algorithmique qui nous
formalisera la structure des algorithmes de voisinage qui sont non-dpendants du sens du parcours et qui
travaillent avec les superpixels.
5.1.4.1 Skeleton algorithmique gnralis pour le traitement morphologique par superpixels
La structure des algorithmes travaillant sur le voisinage par lapproche des superpixels va combiner
deux approches, les deux tant dj mentionnes. Nous nous baserons sur le skeleton gnralis de
travail sur le voisinage ngbAlgoGen qui travaillait avec les lments de base dun array. Nous allons
le transposer au travail gnralis avec des superpixels, tout en suivant les principes de passage ux
de superpixels (et vice versa) et les principes dextraction du voisinage des superpixels que nous avons
dcrits dans la section 4.4.5, page 73, ddie cette problmatique.
Ainsi, nous crons un nouveau skeleton algorithmique que nous appelons ngbAlgoGenSP et qui est
prsent par lalgorithme 5.4.
Algorithme 5.4 : ngbAlgoGenSP, skeleton algorithmique gnralis de travail sur le voisinage
pour les superpixels
1 ngbAlgoGenSP :: [ StreamizeSP ] [ ExtrNgbSP ] [ NgbOpSP ] [ ZipSP ]
2 Ar ( I , I ) Ar ( I , I )
3 ngbAlgoGenSP tm axt op zip ut = array (bounds ut ) (compute tm axt op zip ut )
4 where
5 compute [ ] [ ] [ ] [ ] ut = [ ]
6 compute (: ) (a:a) (o:o) (z :z) ut =
7 ( ( foldl1 (++) )
8 (map z)
9 ( zip ( ut ) )
10 (map o)
11 (map (a ut ) )
12 $ ( ut )
13 )
14 ++(compute a o z ut )
Cet algorithme prend quatre listes des fonctions qui spcient le traitement exact des superpixels dans
certaines zones de limage. La philosophie de dcoupage de limage en zones o diffrentes approches
du traitement peuvent tre appliques est la mme que pour les lments de base dune image, cf.5.1.3.1,
page 106.
La premire liste, tm contient les fonctions de passage dun array un stream des index dancrage.
La deuxime liste, axt, contient des fonctions dextraction du voisinage dun superpixel partir de son
index dancrage ; la troisime, op applique un kernel du calcul sur ce voisinage largi et la quatrime
liste nous fournit les fonctions qui assurent le passage dun superpixel aux lments de base indexs par
109
leurs position dans limage et stocks dans un tuple (index, valeur). Le cinquime paramtre dentre est
larray ut.
De toutes ces fonctions, ce sont effectivement celles qui dcrivent le kernel du calcul qui sont les plus
intressantes. Cest pourquoi nous allons nous concentrer sur la description de ces dernires dans la suite
de ce chapitre et nous allons y prsenter 3 cas prcis pour le traitement lintrieur dun superpixel :
pour la grille carr de 4 et 8 voisins et pour la grille hexagonale de 6 voisins. Ces cas sont spcialiss
pour les oprations morphologiques dont la fonction du traitement du voisinage local dun pixel est une
fonction de rduction par une seule opration de base
1
. Donc, nos oprations cibles sont la dilatation
morphologique (rduction par la fonction max) et la fonction de lrosion morphologique (rduction par
la fonction min).
Ces 3 cas ne sont, en effet, que 3 des cas possibles et trs concrets de limplmentation. Dautres
implmentations sont envisageables, par exemple avec des superpixels plus larges, mais nous croyons
que celles que nous prsentons ici sufsent dmontrer le principe de fonctionnement et une brve
analyse des performances.
5.1.4.2 Traitement dun superpixel sur la grille carre et 8-voisins pour la dilatation / lrosion
Le kernel de traitement que nous prsentons ici est spcialis pour les dilatations et les rosions sur
la grille carre et le voisinage constitu du pixel central et de ses 8 voisins. Il sagit, en effet, dun kernel
qui est le plus facile expliquer car la manire dont les donnes sont rutilises dun lment lautre
est facile interprter visuellement.
Expliquons la fonction de ce kernel sur le graphe de ux, q.v. g. 5.9. Cette gure prsente, dans
sa partie gauche, les lments constituant le voisinage dun superpixel. Les lments correspondant au
superpixel y sont entours par une ligne intermittente. Le rseau dinterconnexions qui lie les lments de
limage avec les blocs oprationnels op2 et op3 montre comment on procde pour calculer le superpixel
rsultant (prsent galement entour par une ligne intermittente). Le bloc oprationnel op2(, ) dsigne
une fonction de base prenant deux arguments, le bloc op3(, , ) dsigne une fonction ayant 3 arguments.
(0,0) (0,1) (0,2)
(1,0)
(2,0)
(3,0)
(1,1)
(2,1)
(3,1)
(1,2)
(2,2)
(3,2)
(4,0) (4,1) (4,2)
(2n+1,0) (2n+1,1) (2n+1,2)
(2n,0) (2n,1) (2n,2)
(1,1)
(2,1)
(3,1)
(2n,1)
(4,1)
op3( , , )
op2( , )
op3( , , )
op3( , , )
op3( , , )
op3( , , )
op3( , , )
op3( , , )
op2( , )
op2( , )
op2( , )
op2( , )
op2( , )
op2( , )
op2( , )
FIG. 5.9 : Fonctionnement du kernel traitant un superpixel en 8-voisinage
Lors du travail avec un superpixel, nous pouvons proter au maximum de la localit des donnes,
de leur prsence dans la mmoire la plus rapide de la hirarchie des caches mais galement des rsultats
partiels dvaluation dun lment que nous rutilisons lors du calcul. Tel que prsent sur la g. 5.9,
le kernel du calcul travaille avec un superpixel ayant un nombre pair des lments de base (2n) dans
1
Les kernels du calcul qui ne sont pas de ce type, par exemple le kernel pour la transformation tout ou rien, seraient
construits diffremment.
110
la premire dimension. Cette contrainte est pose par ce cas particulier mais nous pouvons envisager
la construction dun kernel du calcul qui travaillerait avec un nombre impair des lments, mme si
dun point de vue pratique nous prfrons travailler avec des superpixels qui fragmentent limage dune
manire simple et qui sont, par consquent, de dimensions multiples de 2.
5.1.4.3 Traitement dun superpixel sur la grille carre et 4-voisins pour la dilatation / lrosion
La construction dun kernel du calcul pour un superpixel qui utilise la grille carre et le voisinage
constitu dun pixel central et de ses 4 voisins ne nous mne pas une structure dinterconnexions des
lments et des blocs fonctionnels aussi comprhensible que lon a pu le voir dans 5.1.4.2. Cest, en
effet, d au fait que le nombre de voisins qui sont partags entre deux pixels classiques est limit 2,
cest--dire que nous ne pouvons rutiliser quune seule opration de base.
La g. 5.9 nous dmontre le graphe de ux expliquant le fonctionnement de ce traitement. Notons,
comme on la fait pour le superpixel travaillant avec 8-voisins, que le superpixel doit avoir un nombre
pair des lments de base (2n) pour ce traitement prcis. Le traitement dun superpixel dun nombre
impair des lments est envisageable, mme si dun point de vue pratique nous prfrons travailler avec
des superpixels dont les dimensions sont divisibles par 2 pour les mmes raisons que lon a prsentes
pour le traitement de 8-voisins.
(0,1)
(1,0)
(2,0)
(3,0)
(1,1)
(2,1)
(3,1)
(1,2)
(2,2)
(3,2)
op2( , )
(4,0) (4,1) (4,2)
(2n+1,1)
(2n,0) (2n,1) (2n,2)
(1,1)
(2,1)
(3,1)
(2n,1)
(4,1)
op3( , , )
op3( , , )
op3( , , )
op2( , )
op2( , )
op2( , )
op2( , )
op3( , , )
op2( , )
op3( , , )
op2( , )
op2( , )
5.1.4.4 Traitement dun superpixel sur la grille hexagonale dcale par lignes et 6-voisins pour
la dilatation / lrosion
Le traitement sur la grille hexagonale est assez particulier, d au dcalage des lignes lors du traite-
ment. Pour que lexemple de fonctionnement que nous prsentons sur la g. 5.11 soit cohrent avec la
dnition mathmatique de la grille hexagonale (cf. 4.6, page 84), le superpixel doit tre constitu dun
nombre pair des pixels (2n) et llment dsign par lindex dancrage, lindex (1,1) sur cette gure, doit
tre plac sur une ligne impaire. La construction dun kernel du calcul pour la grille hexagonale avec
le dcalage par colonnes est facilement drivable partir du principe de travail que nous prsentons sur
cette gure.
111
(0,1)
(1,0)
(2,0)
(3,0)
(1,1)
(2,1)
(3,1)
(1,2)
(2,2)
(3,2)
(4,0) (4,1) (4,2)
(2n+1,1)
(2n,0) (2n,1) (2n,2)
(1,1)
(2,1)
(3,1)
(2n,1)
(4,1)
op2( , )
(0,2)
(2n+1,0)
op2( , )
op2( , )
op2( , )
op2( , )
op2( , )
op2( , )
op2( , )
op2( , )
op2( , )
op3( , , )
op3( , , )
op3( , , )
op3( , , )
op3( , , )
5.2 Algorithmes lmentaires pour les GPPMM
Le traitement des images par la morphologie mathmatique sur les architectures multimdia pos-
sdant des capacits SWAR est, pour les algorithmes non dpendants du sens de parcours de limage,
directement drivable du style de travail que lon vient de prsenter pour les GPP sans les fonctionnalits
multimdia. Nous allons, en effet, exploiter au maximum les possibilits du calcul vectoriel. Ce travail
est particulier et se traduit :
par lutilisation des blocs de donnes, exprims dans le formalisme fonctionnel par le type du
vecteur paquet PVec.
par le travail particulier que nous allons effectuer lors daccs aux valeurs voisines dun vecteur
paquet dans la mmoire. En gnral, lemplacement des voisins dun vecteur paquet dans la
mmoire ne concide pas avec la perception dun array comme array de vecteurs paquets. Les
voisins dun vecteur paquet, qui sont dsigns par les dplacements relatifs en units de types de
base de larray, peuvent, dans le cas gnral, tre stocks dans la mmoire lemplacement qui est
partag par deux vecteurs paquets voisins. Ce fait nous conduira lutilisation des instructions de
la lecture non-aligne, cest dire de la lecture des donnes vectorielles qui ne sont pas stockes
dans la mmoire sur les adresses alignes (adresses qui sont divisibles sans rsidu par la taille dun
vecteur paquet).
par lutilisation des fonctions SIMD, arithmtiques ou logiques, lors du traitement des valeurs
composant le voisinage ou les valeurs dsignes par la liste des vecteurs de dplacement dans le
cas gnral.
5.2.1 Skeletons algorithmiques GPPMM de base
La structure de fonctionnement des algorithmes morphologiques de base pour les architectures SWAR
est, en effet, la mme que pour les architectures gnrales. Cest cette place que nous allons faire un
parallle entre les algorithmes pour les GPPMM et les algorithmes pour les GPP et cest cette place o
nous allons voir en pratique la force de la gnralisation qui nous est fournie par les skeletons algorith-
miques dnis en formalisme fonctionnel.
En effet, les skeletons algorithmiques que nous avons prsents pour le travail avec les GPP sont
112
Jaromr BRAMBOR 5.2. ALGORITHMES LMENTAIRES POUR LES GPPMM
autant gnraux quils englobent galement le travail avec les types de vecteurs paquets. Ceci dit, les
skeletons algorithmiques pour les GPPMM ne sont que des spcialisations des skeletons pour un type de
donnes particulier le type polymorphe de vecteurs paquets (PVec I ).
Lapproche nave limplmentation des algorithmes morphologiques dans lesprit de travail SIMD
est dnie par le skeleton algorithmique ngbAlgoSIMD prsent par lalgorithme 5.5. Cest la signature
de type qui est importante dans cette dnition car elle nous prcise quil sagit de la fonction qui est une
spcialisation du skeleton gnral ngbAlgo de lapproche nave qui partage avec elle le corps.
Algorithme 5.5 : ngbAlgoSIMD, skeleton algorithmique de lapproche nave pour le travail SIMD
sur le voisinage
1 ngbAlgoSIMD :: Streamize ( PVec I ) ExtrNgb ( PVec I ) NgbOp ( PVec I )
2 Ar ( I , I ) ( PVec I ) Ar ( I , I ) ( PVec I )
3 ngbAlgoSIMD = ngbAlgo
Nous appliquons le mme principe de spcialisation galement sur le skeleton ngbAlgoIB pour en
ensuite obtenir un nouveau skeleton ngbAlgoIBSIMD, dni par lalgorithme 5.6, qui utilise des proc-
ds distincts dans la zone intrieure et dans la zone du bord de limage et qui est spcique au traitement
SIMD.
Algorithme 5.6 : ngbAlgoIBSIMD, skeleton algorithmique de travail SIMD sur le voisinage qui
divise le traitement en deux parties, traitement dans la zone du bord et dans la zone de lintrieur
1 ngbAlgoIBSIMD :: Streamize ( PVec I ) ExtrNgb ( PVec I )
2 Streamize ( PVec I ) ExtrNgb ( PVec I )
3 NgbOp ( PVec I ) Ar ( I , I ) ( PVec I ) Ar ( I , I ) ( PVec I )
4 ngbAlgoIBSIMD = ngbAlgoIB
Dans la cas dune fragmentation gnrale du domaine de limage lors du traitement morphologique
SIMD, nous obtenons le skeleton algorithmique ngbAlgoGenSIMD qui est galement une spcialisa-
tion dun skeleton dni auparavant. Il sagit de la spcialisation du skeleton ngbAlgoGen (cf. lalgo-
rithme 5.3, page 5.3).
Algorithme 5.7 : ngbAlgoGenSIMD, skeleton algorithmique gnralis de travail SIMD sur le
voisinage
1 ngbAlgoGenSIMD :: [ Streamize ( PVec I ) ] [ ExtrNgb ( PVec I ) ] [ NgbOp ( PVec I ) ]
3 ngbAlgoGenSIMD = ngbAlgoGen
5.2.2 Algorithmes concrets GPPMM de base de la morphologie mathmatique
Les algorithmes de base de la morphologie mathmatique concrets pour le traitement SIMD sur les
architectures multimdia se btissent partir des skeletons prsents dans la section prcdente 5.2.1.
Ils emploieront les fonctions qui spcialiseront lusage de ces skeletons pour le travail avec les donnes
paquetes en se basant sur les primitives fonctionnelles que nous avons dnies pour ce type de donnes
dans la premire partie de cette thse, q.v. chapitre 4. Notamment, il sagit des primitives du parcours de
limage, des primitives de lextraction du voisinage et des primitives dopration sur le voisinage pour la
morphologie mathmatique.
113
Prsentons alors un exemple concret. Le premier que nous dcrivons est lalgorithme de la dilatation
morphologique sur la grille carre par llment structurant ngbSQR4. La fonction dilSQRSIMD dcrit
un algorithme qui utilise la fonction gnrale dextraction du voisinage pour la grille carre et pour
lchantillonnage gnral (sampGen) qui travaille avec la fonction de traitement du bord cBorder rendant
une valeur constante pour tous les lments du bord.
dilSQRSIMD :: (Ord) ( PVec I ) Ngb Ar ( I , I ) ( PVec I ) Ar ( I , I ) ( PVec I )
dilSQRSIMD ItJvuI npI ut = ngbAlgoSIMD
indices
(extrNgbSQRSIMD Iov n (sampGen ( cBorder ItJvuI ) ) npI)
ngbDilate
ut
where n = rangeSizebounds$(ut!Io); (Io,Ii) = bounds ut
Dautres fonctions peuvent tre construites en utilisant le schma prsent. En se basant sur un autre
skeleton algorithmique, en choisissant la fonction dextraction du voisinage, dchantillonnage ou de
traitement des bords approprie et en choisissant la fonction du kernel de lopration morphologique,
nous pouvons driver les implmentations des oprations morphologiques de base adaptes un cas par-
ticulier dutilisation, notamment les oprations sur les grilles hexagonales et la mthode plus complexe
de gestion des bords (i.e. par rexion des bords).
5.2.3 Algorithmes SIMD bass sur lapproche des superpixels
Notre ide de travail avec les vecteurs paquets peut galement tre transpose lapproche des
superpixels. Dans ce cas, les superpixels ne seront pas constitus des lments de base mais des vecteurs
paquets.
(0,1)
A
(0,1)
(0,1)
B
(1,1)
A
(2,1)
A
(3,1)
A
(1,1)
(2,1)
(3,1)
(1,1)
B
(2,1)
B
(3,1)
B
(4,1)
A
(4,1)
(4,1)
B
(2n+1,1)
A
(2n+1,1)
(2n+1,1)
B
(2n,1)
A
(2n,1)
(2n,1)
B
(1,1)
(2,1)
(3,1)
(2n,1)
(4,1)
op3( , , )
op2( , )
op3( , , )
op3( , , )
op3( , , )
op3( , , )
op3( , , )
op3( , , )
op2( , )
op2( , )
op2( , )
op2( , )
op2( , )
op2( , )
op2( , )
(0,0) (0,1) (0,2)
(1,0)
(2,0)
(3,0)
(1,1)
(2,1)
(3,1)
(1,2)
(2,2)
(3,2)
(4,0) (4,1) (4,2)
(2n+1,0) (2n+1,1) (2n+1,2)
(2n,0) (2n,1) (2n,2)
unaLoad
unaLoad
FIG. 5.12 : Fonctionnement du kernel traitant un superpixel SIMD en 8-voisinage
Si nous tudions la transposition de cette ide plus en dtail, nous nous apercevons que nous avons
recours, lors de lextraction des voisins dun superpixel, au mme phnomne que celui que lon a pu
rencontrer lors de lextraction des voisins dun vecteur paquet et qui nous a men lutilisation des
lectures non-alignes des donnes vectorielles de la mmoire.
La gure 5.12 illustre cette situation sur le traitement SIMD dun superpixel pour llment structu-
rant dnissant le voisinage avec 8 voisins sur la grille carre. Elle diffre, par rapport la gure 5.9 qui
assure la mme opration morphologique sur les GPP, dans lutilisation des vecteurs paquets la place
des lments de base et surtout dans la prsence des oprations de lecture non aligne, reprsente par
114
Jaromr BRAMBOR 5.3. ALGORITHMES GODSIQUES POUR LES GPP/GPPMM
les blocs unaLoad. Notons que pour ce cas particulier o nous connaissons a priori la dnition exacte de
llment structurant, nous nutilisons pas la lecture non aligne pour lextraction des vecteurs paquets
centraux mais nous lutilisons uniquement pour lextraction des voisins de ces derniers. Ces voisins sont
dnots dans limage par les index ^ et B.
Dautres schmas de travail avec les superpixels SIMD peuvent tre drivs, notamment ceux pour
le travail avec le 4 pixels voisins sur la grille carre, cf. sa version scalaire sur la g. 5.10, page 111, et
pour le travail avec 6 voisins sur la grille hexagonale, cf. sa version scalaire sur la g. 5.11, page 112.
Algorithme 5.8 : ngbAlgoGenSPSIMD, skeleton algorithmique gnralis de travail sur le voisi-
nage pour les superpixels
1 ngbAlgoGenSPSIMD :: [ StreamizeSP(PVecI ) ] [ ExtrNgbSP(PVec I ) ]
2 [ NgbOpSP( PVec I ) ] [ ZipSP( PVec I ) ]
4 ngbAlgoGenSPSIMD = ngbAlgoGenSP
La formalisation de lapproche des superpixels SIMD travaillant avec les types des vecteurs paquets
suit la mme logique que celle employe pour les algorithmes lmentaires. Nous reprenons le skeleton
algorithmique ngbAlgoGenSP (dni par lalgortihme 5.4) et nous spcialisons sa forme gnrique pour
le type polymorphe de vecteurs paquets PVec I en tant que fonction ngbAlgoGenSPSIMD, dnie
par lalgorithme 5.8.
5.3 Algorithmes godsiques pour les GPP/GPPMM
5.3.1 Ide de base
Le traitement godsique constitue un type de traitement de base de la morphologie mathmatique.
On dsigne une opration comme opration morphologique godsique si le traitement est effectu dune
manire itrative, si nous pouvons y percevoir une propagation des valeurs et si cette propagation est
restreinte lors denchanement des itrations par une fonction, exprime le plus souvent en tant quimage
du masque. Citons comme exemple
Ser00
la dnition de la dilatation godsique de taille unit (donn
par llment structurant B) de la fonction g restreinte par la fonction f :
f
(g) = inf(g +B, f) (5.1)
nous travaillons lchelle des fonctions, cest--dire lchelle des images entires. Si on suivait ces
dnitions, la restriction, reprsente dans notre exemple par la fonction inf, devrait oprer sur les images.
Pour les raisons de performance, il est prfrable dimposer la restriction sur la propagation dj
dans le kernel du calcul de lopration sur le voisinage qui travail lchelle des lments de larray.
Ainsi, nous pouvons construire un kernel dune fonction morphologique godsique condition que
nous puissions introduire la valeur restrictive (valeur du masque correspondant au pixel trait) comme
un paramtre supplmentaire dans la fonction dnissant le kernel.
Nous allons nous appuyer sur les kernels godsiques des oprations sur le voisinage. Nous avons
prsent la forme formelle pour ces kernels dans la section 4.6.6, page 94. Elle sera reprsente dans
nos algorithmes par les fonctions du type NgbGOp. De plus, nous devons galement grer dans ces
algorithmes lextraction de la valeur du masque. Pour cette extraction, nous allons nous appuyer sur la
mme fonction du parcours des stream que celle utilise pour limage mme. Mais il nous faut spcier
une fonction dchantillonnage des lments dun array partir dun index qui est du type SampFnc et
qui sera utilise pour obtenir la valeur concrte du masque pour un index concret.
Remarquons que pour extraire correctement les lments qui se correpondent dans limage et dans
le masque, les dimensions de ces deux arrays doivent tre obligatoirement les mmes. Lalgorithme 5.9
115
nous dcrit la dnition du skeleton algorithmique ngbGAlgoGen destin pour le travail godsique sur
le voisinage.
Algorithme 5.9 : ngbGAlgoGen Skeleton algorithmique gnralis de travail godsique sur le
voisinage
1 ngbGAlgoGen :: [ Streamize ] ( [ ExtrNgb ] , [ SampFnc ]) [ NgbGOp ]
2 ( Ar ( I , I ) , Ar ( I , I ) ) Ar ( I , I )
3 ngbGAlgoGen tm (axt
^
,axt
A
) op (ut , mI) = array
4 (bounds ut )
5 (compute tm (axt
^
,axt
A
) op ut mI)
6 where
7 compute [ ] [ ] [ ] ut mI = [ ]
8 compute (: ) ( (a
^
:a
^
), (a
A
,a
A
)) (o:o) ut mI =
9 ( ( zip ( ut ) )
10 $ (map2 o
11 ( (map (a
^
ut ) ) $ ( ut ) )
12 ( (map (a
A
mI))$( mI))
13 )
14 )
15 ++(compute (a
^
,a
A
) o ut mI)
La g. 5.13 nous illustre sur le diagramme du ux la structure et la fonction de ce skeleton dans le cas
spcial o nous ne fractionnons pas limage aux diffrentes zones et o nous avons, par consquent, son
fonctionnement dcrit par une seule fonction de parcours de limage, une seule fonction dextraction des
voisins et une seule fonction de kernel oprant sur le voisinage et sur le masque (tm, ax^, axP,
op sont les listes contenant un seul lment).
ar
(Array
dentre)
Array
de sortie
array
bounds
Cration de larray
de sortie
strm
0
extrM
0
NgbOp
0
zip ++[]
compute
strm
0 extrN
0
Msk
(Array
de masque)
FIG. 5.13 : Fonctionnement du skeleton algorithmique ngbGAlgoGen de traitement du voisinage avec le
masque dans le cas spcial o nous ne fractionnons pas limage aux diffrentes zones
5.3.2 Itrations, n de propagation
Ce skeleton est lmentaire et il ne dcrit quune itration de la propagation godsique. Pour luti-
liser correctement, llment structurant employ doit obligatoirement tre de la taille unit. La propa-
gation godsique elle-mme sera obtenue par lincorporation de ce skeleton dans un skeleton ou un
algorithme grant la propagation. Il existe, en effet, deux types de fonctions godsiques :
fonctions godsiques avec le nombre ditrations donn,
fonctions godsiques itrant jusqu lidempotence.
Pour les premires, le nombre ditrations est connu davance est la construction de lalgorithme peut
sappuyer sur ce fait. Pour les deuximes, nous devons tester larrt de la propagation (test didempotence
de la fonction godsique sur une image donne). Ce test compare les valeurs de limage dentre (avant
116
Jaromr BRAMBOR 5.3. ALGORITHMES GODSIQUES POUR LES GPP/GPPMM
lemploi de lopration godsique) et limage de sortie (aprs avoir effectu cette opration godsique).
Si elles sont les mmes, nous arrtons la propagation car nous avons atteint ltat didempotence.
Ce test est assez coteux en terme doprations arithmtiques car il doit effectuer une comparaison
pixel par pixel et employer ensuite une fonction de rduction qui, pour limage toute entire, ne fournit
quune seule valeur retant lidentit / non-identit des deux images. Cette valeur peut tre binaire ou
pas. En termes de ux de donnes, nous effectuons dabord lopration dapplication dune fonction
(comparaison) sur tous les lments du stream qui est suivie par la rduction de ce stream une seule
valeur.
Pour diminuer limpact de ce test de la n de la propagation, plusieurs approches sont prvoir pour
son implmentation, dpendantes surtout du caractre de notre image. Nous pouvons tester la propagation
chaque itration, ce qui peut savrer coteux. Mais nous pouvons envisager dutiliser la proprit
didempotence qui est atteinte la n de la propagation. Ainsi, nous savons a priori que chaque itration
supplmentaire ne changera pas les rsultats. En se basant sur cette proprit, nous pouvons construire
un algorithme qui ne teste pas la n de la propagation aprs chaque itration mais quaprs un certain
nombre ditrations.
5.3.3 Note sur le travail godsique avec les superpixels
Lapproche des superpixels est galement utilisable pour les algorithmes godsiques de la morpho-
logie mathmatique avec certaines modication de la structure des skeletons algorithmiques. En effet,
la fonction du parcours de limage pour les superpixels (qui est du type StreamizeSP) nous retourne le
stream des index dancrage des superpixels.
Les valeurs des index dancrage issues de ce stream seront utilises par les fonctions qui extraient
le voisinage large dun superpixels (fonctions du type ExtrNgbSP) mais galement par les fonction
dchantillonnage dun superpixels (fonctions du type SampFncSP) qui nous retourne une liste des
valeurs dun superpixel.
La construction du skeleton algorithmique ngbGAlgoGenSP pour le travail godsique sur le super-
pixels, prsent par lalgorithme 5.10, sappuie sur le skeleton algorithmique de base (ngbGAlgoGen)
dont elle utilise le corps. Il sagit, en effet de la spcialisation de cette fonction pour le travail avec le
superpixels, comme nous pouvons le voir sur la signature de type dans lalgorithme 5.10.
Algorithme 5.10 : ngbGAlgoGen Skeleton algorithmique gnralis de travail godsique sur le
voisinage par lapproche des superpixles
1 ngbGAlgoGenSP :: [ StreamizeSP ] ( [ ExtrNgbSP ] , [ SampFncSP ]) [ NgbGOpSP ]
2 ( Ar ( I , I ) , Ar ( I , I ) ) Ar ( I , I )
3 ngbGAlgoGenSP = ngbGAlgoGen
5.3.4 Travail SIMD avec les vecteurs paquets
Les oprations godsiques pour les vecteurs paquets sont directement drivables en tant que sp-
cialisation de fonctionnement du skeleton godsique ngbGAlgoGen (prsent par lalgorithme 5.9)
car ce dernier est assez gnral pour englober galement le travail avec les vecteurs paquets. Lalgo-
rithme 5.11, qui dnit le skeleton algorithmique ngbGAlgoGenSIMD, nous prsente la forme formelle
de cette spcialisation.
Le travail SIMD pour les superpixels est galement possible. La manire dont on construirait un
skeleton algorithmique qui travaillerait avec les superpixels composs des vecteurs paquets et avec des
superpixels de limage du masque est intelligible partir de la description que nous avons faite dans cette
section.
117
Algorithme 5.11 : ngbGAlgoGenSIMD Skeleton algorithmique gnralis de travail godsique
SIMD sur le voisinage
1 ngbGAlgoGenSIMD :: [ Streamize ( PVec I ) ] [ ExtrNgb ( PVec I ) ] [ NgbGOp ( PVec I ) ]
2 ( Ar ( I , I ) ( PVec I ), Ar ( I , I ) ( PVec I ))
3 Ar ( I , I ) ( PVec I )
4 ngbGAlgoGenSIMD = ngbGAlgoGen
5.4 Algorithmes pour les GPU
Cette section sera consacre aux algorithmes morphologiques de base, non dpendants du sens du
parcours de limage, qui utilisent les moyens fonctionnels du pipeline graphique et qui sont destins
tre excuts sur les processeurs graphiques.
Il est possible denvisager plusieurs approches la construction de ces algorithmes. Nous mention-
nons :
Lapproche utilisant les oprations de Minkowski, q.v. page 118.
Lapproche utilisant lchantillonnage de textures dans lunit de traitement des fragments, q.v.
page 120.
Lapproche utilisant les point sprites, q.v. page 120.
5.4.1 Traitement des bords de la texture sur les GPU
Notre explication des algorithmes pour les GPU commencera par lexplication des capacits mat-
rielles particulires des processeurs graphiques pour lchantillonnage des textures avec les index poin-
tant en dehors du domaine de la texture. Il sagit des capacits de la gestion des bords lors de lchan-
tillonnage de la texture. Dans les algorithmes utiliss couramment de la morphologie mathmatique, nous
allons faire appel le plus souvent la fonction de la valeur constante du bord de limage mais dautres
possibilits (les valeurs retes etc.) peuvent tre envisages.
Sachant que limage traiter est reprsente dans le GPU en tant que texture, nous pouvons bn-
cier de ces capacits pour simplier la construction des algorithmes morphologiques travaillant sur le
voisinage dans ce matriel. Ainsi, le calcul effectuer sera le mme pour tout le domaine de limage, y
compris pour les zones dans lesquelles llment structurant dsigne les pixels lextrieur de ce dernier.
Luniformit du calcul est un phnomne important dans ce cas, car nous naurons pas traiter plu-
sieurs zones de limage avec une fonction du kernel spcique pour chacune des zones. Cette uniformit
va se traduire par lutilisation de la commande gomtrique couvrant entirement notre domaine dintrt
rectangle de dimension de limage dans ce cas prcis.
Remarquons que les fonctionnalits de la gestion des bords sont ajustes lors de la cration de la
texture et ne sont effectues quune fois dans la phase de linitialisation de notre algorithme.
5.4.2 Approche utilisant les oprations de Minkowski
Une possible approche pour implmenter les algorithmes de la morphologie mathmatique utilise
les oprations de Minkowski (cf. la section 4.6.3 traitant dlments structurants, page 86). Il sagit de
lapproche qui est dcrite par Hopf et Ertl dans leur article
HE00
, le plus ancien (anne 2000) que nous
ayons pu consulter et qui implmentait les oprations morphologiques sur les GPU utilisant les capacits
matrielles qui taient disposition lpoque.
Sachant que les GPU grand public gardent la compatibilit rtroactive, il est possible denvisager
lutilisation de cette approche galement sur les processeurs graphiques modernes, mais son utilit pra-
tique est moindre car ces nouveaux processeurs nous offrent dautres possibilits pour une implmenta-
tion plus rapide. En revanche, les mthodes qui sont bases directement sur les oprations de Minkowski
118
Jaromr BRAMBOR 5.4. ALGORITHMES POUR LES GPU
peuvent trouver leur emploi sur les architectures des processeurs graphiques ddis (e.g. basse consom-
mation) qui noffrent que les fonctionnalits restreintes par rapport aux processeurs graphiques grand
public.
Le principe de cette approche suit la mthode de travail des oprations de Minkowski, connues
comme les oprations de base dans la thorie de la morphologie mathmatique. Lors du calcul de ces
oprations, nous dplaons limage entire selon les vecteurs dnissant les lments structurants et nous
fusionnons les valeurs places sur la mme position avec une opration logique (a/ou) dans le cas de
traitement binaire ou avec une opration arithmtique (min/mux) dans le cas de traitement en niveaux de
gris.
Dans limplmentation sur les GPU, limage dentre est exprime en tant que texture. Lors du cal-
cul, nous travaillons avec les commandes graphiques en forme de rectangles qui ont les dimensions de
limage. Avant denvoyer la commande graphique dans le GPU, la position des vertex est modie selon
les vecteurs de dplacement de llment structurant. Ainsi, nous obtenons une squence des commandes
contenant les rectangles avec les positions dcales dans lespace mais qui contiennent les mmes coor-
donnes pour lindexation de la texture. De cette manire, nous dnissons les emplacements distincts
dans le framebuffer sur lesquells nous allons effectuer le rendu des pixels partir de la texture. La -
gure 5.14 illustre cette situation.
lment
structurant
framebuffer
FIG. 5.14 : Utilisation des oprations de Minkowski sur les GPU pour le calcul morphologique. Les rectangles
rendre sont dcals selon les vecteurs de llment structurant
Dans ce cas prcis, nous nemployons pas un programme particulier pour le traitement des vertex
et des fragments et nous programmons le pipeline de telle manire quil neffectue quune opration
dchantillonnage pour chaque fragment cr. Lopration morphologique choisie (dilatation ou rosion)
est effectue par les oprations du blending (mux pour la dilatation, min pour lrosion) dans la phase
de post-traitement des fragments lors de leur fusion avec les valeurs dj prsentes dans le framebuffer.
Donc, le kernel de rduction qui rduit le stream de valeurs de voisinage une seule valeur rsultante
intervient dans le bloc des raster-oprations avec le framebuffer prsent dans notre modle formel par
le raster processeur (rprocessor).
Gnralement, le framebuffer doit tre prpar ce traitement et doit tre rempli par une valeur
constante qui a un comportement neutre vis--vis de notre opration morphologique (valeur minimale du
type de stockage pour la dilatation, valeur maximale du type de stockage pour lrosion) dans la phase
de linitialisation de lalgorithme. Dans le cas o notre lment structurant contient galement le vecteur
(0,0) dsignant le pixel central, nous pouvons pr-remplir le framebuffer par limage mme en copiant
les donnes de la texture (qui sont celles de limage) dans le framebuffer
1
. Dans ce cas, la liste des
commandes graphiques contiendra un rectangle de moins, correspondant au dplacement par le vecteur
(0,0), et nous allons, en effet, travailler avec la liste des vecteurs dsignant les voisins plutt que avec
llment structurant entier (qui contient le vecteur dsignant le pixel central).
Les rsultats sont obtenus dans le framebuffer aprs que le rendu du dernier rectangle est effectu.
Ils peuvent tre rcuprs pour le calcul suivant dans le GPP via le transfert des donnes partir du
1
Notons quil nest pas possible dutiliser une zone de la mmoire du GPU pour la lecture et lcriture en mme temps.
Lopration de copie est alors ncessaire dans ce cas.
119
framebuffer. Ou ils peuvent galement tre rutiliss lors de la prochaine application de lopration de la
morphologique mathmatique. Nous proterons partiellement du fait que les donnes sont dj prsentes
dans le framebuffer et linitialisent ainsi dans le cas o llment structurant de lopration suivante
contiendrait le vecteur dsignant le pixel central. Nonobstant que le framebuffer soit ainsi initialis, nous
devons procder une copie de ses valeurs vers une texture qui serait utilise pour lchantillonnage dans
lopration suivante.
5.4.3 Approche utilisant lchantillonnage complexe des textures dans lunit de trai-
tement des fragments
Les processeurs graphiques plus rcents offrent la possibilit dexcuter le programme sur chacun des
fragments. Nous allons exploiter cette capacit matrielle pour pouvoir introduire une autre approche
limplmentation des oprations morphologiques de base sur les processeurs graphiques.
Lide de cette approche consiste utiliser lchantillonnage massif de la texture, effectu dans lunit
de traitement des fragments lors de lapplication du kernel de traitement sur le stream des fragments. La
forme prcise de cet chantillonnage est dicte par la forme de llment structurant, qui, une fois traduit
une liste des vecteurs de dplacement dans le domaine des index, peut tre utilise pour accder aux
valeurs des lments de la texture. Remarquons que lopration morphologique est calcule galement
dans lunit des fragments. Par consquent, le fragment modi rsultat porte linformation sur le rsultat
de cette opration morphologique comme la valeur de la couleur qui est inscrire dans le framebuffer.
Dans les algorithmes de ce type, notre commande graphique ne sera compose que dun seul rec-
tangle qui couvre la surface dans le framebuffer correspondant au domaine de limage et sur laquelle
nous afchons les rsultats du traitement. Notons galement que nous travaillons avec une seule image
de texture. Nous travaillerons avec plusieurs images de texture dans le cas o nous voudrions effectuer
une opration morphologique plus complexe faisant appel plusieurs images, e.g. les oprations god-
siques en font partie.
Linitialisation du framebuffer nest pas ncessaire dans ce cas car lopration morphologique de r-
duction des valeurs du voisinage est calcule entirement par le processeur des fragments (fprocessor).
Ainsi, nous navons pas besoin de faire appel aux oprations du blending dans la phase de post-traitement
des fragments. En effet, nous navons pas besoin des oprations raster pour effectuer le kernel de lop-
ration morphologique de base, mais nous pouvons utiliser la fonctionnalit du blending pour distribuer
le calcul et allger la charge des units de traitement des fragments, notamment lors du travail avec les
oprations godsiques qui utilisent un masque niveaux de gris. Si le masque est binaire, lapplication
du masque par le blending ne semble pas la meilleure solution car les GPU possdent la fonctionnalit du
stencil buffer, galement englob dans le bloc des raster oprations lors du post-traitement des fragments,
qui assure exactement cette opration.
Remarquons que lexcution de ce kernel de traitement des fragments est paralllise dans les pro-
cesseurs graphiques par le paradigme de la rplication fonctionnelle (cf. le skeleton farm, page 67).
Sachant que cest le bloc de traitement des fragments qui est le plus paralllis au niveau du matriel,
cette approche limplmentation a toutes les prdispositions pour proter pleinement des capacits des
GPU modernes. La gure 5.15 illustre le fonctionnement de cette approche. Nous y dmontrons, pour un
exemple concret dun lment structurant, de quelle manire on procde lors de lextraction des texels
(des donnes partir de la texture) dsigns par cet lment structurant.
5.4.4 Approche utilisant les point sprites
Parmi les capacits particulires des GPU pour le calcul destin la synthse des images, nous trou-
vons une fonctionnalit intressante qui peut nous servir, effectivement, pour implmenter les oprations
morphologiques sur les GPU les point sprites.
Il sagit dune technique spciale, mais couramment utilise dans la synthse dimages pour crer
facilement les objets de 2 dimensions et les placer dans limage. Le principe de cette technique est simple.
120
Jaromr BRAMBOR 5.4. ALGORITHMES POUR LES GPU
lment
structurant
Rectangle de rendu
lment
structurant
transpos
chantillonnage de la texture
pour pixel P
pixel P
FIG. 5.15 : Utilisation dchantillonnage de la texture dans lunit de traitement des fragment pour lextraction
du voisinage
Nous voudrions afcher dans le framebuffer un objet rectangulaire et textur partir dun minimum de
commandes. Donc, notre primitive gomtrique qui passera par la commande graphique du GPP au GPU
est un point. Cest dici que lon a driv leur appellation point sprites.
En effet, cest lunit dassemblage des primitives qui, tant pralablement congure pour ce travail,
remplace chaque point dsignant un point sprite par un rectangle dont les vertex contiennent les index
pointant vers la texture associe ce point sprite et dont la position est relative la position du point qui
a t pass par la commande graphique.
En effet, nous voulions exploiter cette technique pour une autre version de limplmentation des op-
rations de Minkowski. Supposant que nous puissions crer un point sprite ayant les dimensions de notre
image traiter, nous pourrions percevoir une squence des point sprites comme la version graphique
de llment structurant. En effet, chaque point de cette liste dnirait le dplacement de limage et si
nous avions bien congur lunit du blending, de la mme manire que nous lavons fait dans 5.4.2,
page 118, pour lapproche utilisant les oprations de Minkowski, nous aurions obtenu les rsultats de
notre opration morphologique de base dans le framebuffer.
Le problme de cette mthode est quil nest pas habituel de traiter les point sprites qui sont de dimen-
sions gales celles de limage et que le support de grandes dimensions lors de ce travail varie dun GPU
lautre. En effet, les GPU dATI devrait avoir cette possibilit tant que notre GPU dexprimentation,
NVidia GeForce 6800, permettrait dafcher les point sprites de seulement 63 63 pixels.
Ainsi, nous laissons cette technique comme problme ouvert pour lavenir. Notons que mme si cette
mthode prsente de grandes similitudes avec celle qui utilisait les oprations de Minkowski (cf. 5.4.2,
page 118), elle permet de passer moins dinformations par une commande graphique ; si cette dernire
ide ne participait pas laugmentation signiante du temps dexcution (car on npargne quun nombre
trs peu important de donnes lors du transfert de la commande graphique par le bus liant le GPP avec le
GPU), les point sprites pourraient se prsenter comme une mthode idale lcriture plus logique des
programmes morphologiques pour les GPU car la signication et la manire de fonctionner des point
sprites sont trs proches des vecteurs dnissant les lments structurants.
5.4.5 Description des algorithmes pour les processeurs graphiques par le formalisme
fonctionnel
Dans cette section, nous voulons dmontrer comment nous construisons des algorithmes pour les
GPU et comment nous pouvons dcrire un tel algorithme formellement utilisant les dnitions mention-
nes dans la section 4.5, page 76, du chapitre 4 qui prsentait le modle formel du traitement en pipeline
graphique.
Nous prsentons dabord lalgorithme 5.12, dni par la fonction gpuTexture, qui est trivial qui ne
fait quchantillonner une texture et napplique aucune opration supplmentaire. Donc, cet algorithme
effectue le rendu de la texture dans le framebuffer. Il prend deux paramtres, tmJ est la commande
graphique qui va dcrire la zone pour le rendu et a est lenvironnement du travail du GPU. Notons que
cet environnement doit tre initialis pour ce travail ; il doit contenir une texture (spcie par son index
xi) et le framebuffer du GPU doit tre galement prt accueillir des rsultats (e.g. une zone de mmoire
de texture connecte au framebuffer).
121
Algorithme 5.12 : gpuTexture, skeleton algorithmique dafchage dune texture dans le framebuf-
fer du GPU
1 gpuTexture :: Commands Env Env
2 gpuTexture tmJ a = pipeGPU vpid rasterize fpTexture rpid tmJ a
3
4 fpTexture :: FProg
5 fpTexture a (p, J, t, [ ( xi , xp) ] ) = mkF p J [ (1,toI ) ] [ ( xi , xp) ]
6 where
7 toI = smpBorder ( ( getTXs $a) ! ! xi ) xp
Le fonctionnement de cet algorithme sappuie sur le bloc de traitement des fragments et, par cons-
quent, lalgorithme spcie le fragment programme fpTexture pour cet afchage. Le reste du pipeline
neffectue que le passage dune unit lautre vertex programme vpid retourne le vertex inchang,
lunit de rastrisation rasterize effectue la rastrisation standard et nous nutilisons aucune fonctionna-
lit spcique de post-traitement des fragments (exprim par rpid).
Le fonctionnement du fragment programme se compose dappel dune seule fonction fonction
dchantillonnage des textures smpBorder. Ses deux arguments sont la texture, spcie par lexpression
( ( getTXs $a) ! ! xi )
et qui rcupre la texture de lenvironnement, et par la position xp du texel chantillonner.
Lalgorithme de la dilatation suit la logique prsente. Nous modions le fragment programme pour
ce but. Plutt quchantillonner un seul texel de la texture, nous procdons lchantillonnage de tout
le voisinage spci par la liste des vecteurs de dplacement npI. Dans le cur de la fonction fpDilate
dnissant le fragment programme, nous crons (ligne 7) la fonction dchantillonnage mp|nt par lap-
plication partielle de la fonction smpBorder la texture qui est rcupre de lenvironnement anv de
la mme manire que dans lalgorithme prcdent. Nous appliquons, ligne 8, la fonction de spcialisa-
tion du voisinage specNgbSQR pour obtenir des index pointant vers les pixels du voisinage. Ensuite,
lchantillonnage par la fonction mp| nt est applique et nous fournit les valeurs des pixels umpIa. La
valeur rsultante toI est obtenue, ligne 9, par lapplication de la fonction morphologique de dilatation,
ngbDilate.
Linitialisation de lenvironnement de travail du GPU doit tre effectu de la mme faon que dcrit
prcdemment.
Algorithme 5.13 : gpuTexture, skeleton algorithmique de la dilatation, image est stocke dans la
texture, rsultat sera crit dans le framebuffer du GPU
1 gpuDilate :: Ngb Commands Env Env
2 gpuDilate npI tmJ a = pipeGPU vpid rasterize ( fpDilate $npI) rpid tmJ a
3
4 fpDilate :: Ngb FProg
5 fpDilate npI a (p, J, t, [ ( xi , xp) ] ) = mkF p J [ (1,toI ) ] [ ( xi , xp) ]
6 where
7 mp|nt = smpBorder ( ( getTXs $a) ! ! xi )
8 umpIa = map mp|nt (specNgbSQR npI xp)
9 toI = ngbDilate umpIa
122
Jaromr BRAMBOR 5.5. RSULTATS EXPRIMENTAUX
5.5 Rsultats exprimentaux
Le sujet expos dans ce chapitre est fondamental pour les implmentations des oprations de base
de la morphologie mathmatique. Vu que ces dernires sont abondamment utilises dans les applications
de traitement des images par la morphologie, il est primordial de pouvoir excuter ces oprations le plus
rapidement possible.
Cest pourquoi nous voulions explorer les performances des mthodes proposes dans ce chapitre et
pourquoi nous prsentons, dans la tab. 5.1, les rsultats des tests comparatifs de lopration de dilatation
morphologique pour les mthodes que nous avons dveloppes nous-mmes (GPU et MorphoMedia) au
cours de cette thse et des mthodes assurant les mmes fonctionnalits mais qui sont incorpores dune
manire standard dans les produits commerciaux (Aphelion et MATLAB) qui reprsentent ainsi la rf-
rence industrielle. Une autre implmentation que nous avons mise en relation avec nos rsultats est celle
qui utilise les mthodes de loutil logiciel Morphe, dvelopp au Centre de Morphologie Mathmatique
pour les besoins de la recherche algorithmique et qui peut tre considr comme rfrence dune bi-
bliothque des fonctions spcialement ddi aux algorithmes morphologiques mais programmes dune
faon gnrique.
Notons que notre implmentation, dsigne par MorphoMedia, utilise lapproche des superpixels
SIMD, cf. 4.4.5, page 73, lors de lvaluation avec les macro blocs ayant 64 pixels dans laxe de sto-
ckage des donnes et la dimension de limage dans la coordonne perpendiculaire. Limplmentation de
la dilatation sur les processeurs graphiques, dsigne par GPU, utilise lapproche de lchantillonnage
complexe des textures dans les units de traitement des fragments, cf. 5.4.3, page 120.
La g. 5.16 prsente graphiquement les donnes de la tab. 5.1. Nous constatons que pour une opra-
tion aussi basique que la dilatation, les temps de calcul pour les implmentations commerciales existantes
sont excessivement longs si on les compare avec les temps des implmentations des algorithmes pour les
GPP issus de cette thse. Ces derniers offrent des taux dacclration intressants, allant jusqu 230 par
rapport au logiciel MATLAB; cela pour une image de 256 ko et le cas de llment structurant de 4
voisins sur la grille carre ("SQR DISC2D 4") de taille 10.
Des temps encore plus intressants sont ceux des processeurs graphiques. Nous constatons des taux
dacclration suprieurs 2 par rapport notre implmentation des superpixels SIMD, la meilleure ob-
tenue sur le processeur gnral. Ce sont, en effet, ces rsultats-l qui valorisent leffort que nous avons
investi dans lexploitation de lutilisation des processeurs graphiques pour le calcul morphologique. Ces
rsultats sont dautant plus encourageants si nous mentionnons les caractristiques de notre matriel.
Tandis que le processeur GPP Intel Pentium 4 a t cadenc 2.4 GHZ, la carte graphique NVidia Ge-
Force 6800 LT ("light edition") est dote dun GPU qui appartient au bas de gamme parmi les processeurs
offrant les fonctionnalits qui nous intressent et a t cadence 375 MHz.
5.6 Rcapitulation
Nous avons prsent, dans ce chapitre, la construction des algorithmes de la morphologie mathma-
tique dont le point commun est lindpendance du traitement sur le sens du parcours de limage. Il sagit,
en effet, des algorithmes qui exposent le paralllisme des donnes et des tches et sont ainsi les bons
candidats lexcution en parallle.
Nous avons explor la piste de lutilisation des moyens matriels qui sont disposition dans les
architectures multimdia - la paralllisation appartenant la catgorie SIMD qui est effectue lchelle
des registres (o on parle galement du traitement SWAR). Nous avons propos la mthodologie pour la
cration des algorithmes traitant des donnes en tant que ux pour ce type darchitectures et nous avons
dmontr leur description dans le formalisme fonctionnel.
Une autre piste que nous avons explore dans ce chapitre est celle de lutilisation des processeurs
graphiques pour le calcul massivement paralllis des algorithmes de la morphologie. Vu que les proces-
seurs graphiques sont les architectures particulires de traitement des donnes en tant que ux, il nous
semblait appropri dajouter lexprience avec ces processeurs dans ce chapitre.
123
SQR DISC2D 8 Taille = 1
GPU GPP
Image MrphMedia Morphe Aphelion* MATLAB 7.0**
ms ms ms ms ms
256 ko 0.372 50.0 86.0 84
1 Mo 1.1 2.587 171.9 223.5 331
4 Mo 36.376 631.2 609.4 1312
GPU GPP
ms ms ms ms ms
256 ko 0.216 46.7 pas de fonction 200
1 Mo 0.65 1.956 156.9 pas de fonction 858
4 Mo 32.876 586.0 pas de fonction 3046
GPU GPP
ms ms ms ms ms
256 ko 3.769 460.6 118.7 75
1 Mo 21.081 1574.0 346.9 260
4 Mo 386.876 5821.9 1117.2 929
GPU GPP
ms ms ms ms ms
256 ko 2.281 423.8 pas de fonction 527
1 Mo 6.6 13.544 1463.8 pas de fonction 1727
4 Mo 352.252 5465.7 pas de fonction 6216
* Fonctions dAphelion non-MMX; ** MATLAB utilise la dcomposition dlment structurant SQR DISC2D 8 aux lments structurant
segments lors de ce calcul. Dimensions des images : 256 ko = 256x256x4x8bit, 1 Mo = 512x512x4x8bit, 4 Mo = 1024x1024x4x8bit. GPP =
Intel Pentium 4 2.4 GHz (single thread, 8 ko L1, 512 ko L2) ; GPU = NVidia GeForce 6800 LT AGP 4x 375 MHz
TAB. 5.1 : Rsultats exprimentaux de diverses implmentations de la dilatation morphologique
124
Jaromr BRAMBOR 5.6. RCAPITULATION
SQR DISC2D_8 taille 1
0,1 1 10 100 1000 10000
256 ko
1 Mo
4 Mo
temps / ms
Matlab 7.0
Aphelion (sans MMX)
Morphee
MrphMedia
GPU
(a) grille carre, lment structurant de 8 voisins, taille 1
1 10 100 1000 10000
256 ko
1 Mo
4 Mo
temps / ms
Matlab 7.0
Aphelion (sans MMX)
Morphee
MrphMedia
GPU
(b) grille carre, lment structurant de 8 voisins, taille 10
0,1 1 10 100 1000 10000
256 ko
1 Mo
4 Mo
temps / ms
Matlab 7.0
Aphelion (sans MMX)
Morphee
MrphMedia
GPU
(c) grille carre, lment structurant de 4 voisins, taille 1

1 10 100 1000 10000
256 ko
1 Mo
4 Mo
temps / ms
Matlab 7.0
Aphelion (sans MMX)
Morphee
MrphMedia
GPU
(d) grille carre, lment structurant de 4 voisins, taille 10
FIG. 5.16 : Comparaison des temps dexcution de la dilatation pour diffrents logiciels et diffrentes im-
plmentations, sur les GPP/GPPMM (Intel Pentium 4 2,4 GHz ; 512 ko L2 ; classe 0-F-2-4-1E) et les GPU
(NVidia GeForce FX 6800 ; AGP 4x 375 MHz). Les temps pour les GPU nincluent pas les transferts.
Ce fait nous a permis galement de comparer leurs performances avec les implmentions correspon-
dantes excutes sur le processeur gnral lors de ltude comparative de lexcution de lopration de
base de la morphologie la dilatation. Les rsultats ont non seulement prouv la supriorit de notre
approche des superpixels SIMD pour lexcution des oprations morphologiques sur les GPP par rapport
aux produits commerciaux existants, mais ont galement dmontr que limplmentation de la mme
opration sur les GPU est encore plus rapide (avec le taux dacclration suprieur 2) par rapport
lapproche des superpixels SIMD qui assurait la meilleure excution sur les GPP.
125
CHAPITRE 6
Permutation SIMD des arrays applique
au changement de stockage des donnes vectorielles
Les processeurs du calcul gnral prsentent, en ce qui concerne le traitement dimages, certains
dsavantages. Lun de ceux-ci, propre toutes les architectures du type von-Neumann, est sans doute la
faon linaire dorganisation et dadressage des donnes dans la mmoire de travail. Lespace de mmoire
est peru par le processeur comme unidimensionnel car il est prsent comme tel par le sous-systme de
gestion de la mmoire
Les donnes composes qui prsentent laspect rgulier dune grille et qui possdent 2 ou plusieurs
dimensions, i.e. arrays, matrices, images, tenseurs, sont stockes dans la mmoire linaire et laccs
ces donnes est assur par une fonction de mapping des index. Ainsi, chaque index dune structure ayant
2 ou plusieurs coordonnes est mis en correspondance avec un index dans la mmoire linaire. Cette
organisation linaire de la mmoire est souvent lorigine des problmes considrables dans le domaine
du traitement dimages, particulirement ressenti lors de lutilisation de lapproche vectorielle SIMD o
lon a besoin daccder plusieurs lments de limage la fois par le biais des donnes paquetes.
Cest pourquoi nous constatons un besoin essentiel de rorganiser les donnes vectorielles. Pour
cela, nous introduisons les algorithmes qui changent mutuellement laxe principal de stockage avec laxe
secondaire, i.e. laxe x pour y et vice versa. Nous ninsistons pas pour autant sur lutilisation de la mme
fonction dindexation des donnes. En effet, notre besoin prioritaire est de pouvoir accder aux donnes
par les instructions vectorielles SIMD et nous pouvons nous contenter dune autre manire dindexation
car celle-ci joue un rle secondaire.
Les oprations qui satisfont notre demande pour le changement mutuel de laxe principal avec laxe
secondaire sont :
transposition par diagonale,
transposition par antidiagonale,
rotation de +
2
,
rotation de
2
.
Dans la section suivante 6.1 intitule Transpositions et rotations des arrays, nous allons prsenter les
dnitions de ces oprations. Elles nous seront utiles dun ct pour donner des dnitions formelles
doprations peu courantes dans le calcul matriciel (notamment les rotations des arrays), dun autre ct,
elles vont constituer automatiquement les descriptions des algorithmes triviaux qui travaillent lment
par lment. Dans la section suivante, 6.2, nous prsenterons lapproche qui utilise les macro blocs pour
lvalutation de toutes ces oprations. Cette approche nous servira plus tard, dans la section 6.3, page 133,
intitule Algorithmes rapides SIMD de transposition et de rotation, o nous allons prsenter lapproche
SIMD aux transpositions et aux rotations des arrays pour les architectures SWAR et qui va utiliser les
macro blocs pour son travail.
127
6.1 Transpositions et rotations des arrays
La premire catgorie des algorithmes convenant la rorganisation des donnes pour lchange
mutuel des axes est constitue par les algorithmes de transposition dun array par la diagonale et lanti-
diagonale. La deuxime catgorie est constitue par les algorithmes de rotation dun array de +
2
de
2
.
Dans la pratique, nous allons nous servir plus souvent des transpositions, surtout pour leur proprit
dauto-inversion, o le mme algorithme appliqu sur un array X deux fois de suite donne comme
rsultat larray dorigine X. Pour les transpositions par la diagonale, T
D
, et les transpositions par lanti-
diagonale, T
A
, les expressions suivantes sont valides :
X = T
D
(T
D
(X))
X = T
A
(T
A
(X))
Ce qui nest pas le cas pour les rotations de +
2
, R
+
, et de rotation de
2
, R
, qui assurent mutuellement

les oprations inverses. Cette proprit est dcrite par les expressions suivantes :
X = R
(R
+
(X))
X = R
+
(R
(X))
Mme si en pratique nous nutiliserons que les transpositions, nous ajoutons notre explication
galement les rotations car elles sont connexes au sujet de changement de la manire de stocker et,
comme nous le verrons par la suite, entrent entirement dans la logique de la construction des algorithmes
suivants.
6.1.1 Dnitions des transpositions et des rotations
6.1.1.1 Dnition de la transposition par diagonale
La dnition de la transposition par la diagonale (principale) dun array de 2 dimensions, comme
nous le dnissons par la fonction tr2DDiag, est identique la dnition dune transposition matricielle.
tr2DDiag :: Ar ( I , I ) Ar ( I , I )
tr2DDiag ut = array ( (1,1) , (q,p) ) [ ( ( i , j ) , ut ! ( j , i ) ) | i [ 1.. q] , j [ 1.. p] ]
where (p,q) = dimsAr2D ut
Dans cette dnition, nous utilisons la fonction array qui cre un nouvel array partir de ltendue
des index et dun liste des tuples (index, lement). La dnition est simple, pour un lment avec lindex
(i, j) dans larray de sortie nous associons un lement avec lindex (j, i) de larray dentre.
6.1.1.2 Dnition de la transposition par antidiagonale
La transposition par lantidiagonale, dnie par la fonction tr2DADiag, est similaire la dnition
prcdente lexception du travail avec les index :
tr2DADiag :: Ar ( I , I ) Ar ( I , I )
tr2DADiag ut = array ( (1,1) , (q,p) )
[ ( ( i , j ) , ut ! (pj+1, qi+1)) | i [ 1.. q] , j [ 1.. p] ]
6.1.1.3 Dnition de la rotation de +
2
Nous dnissons la rotation de +
2
par la fonction rot2DPlus90 de la mme manire en appliquant
un travail diffrent sur les index :
rot2DPlus90 :: Ar ( I , I ) Ar ( I , I )
rot2DPlus90 ut = array ( (1,1) , (q,p) )
[ ( ( i , j ) , ut ! ( j , qi+1)) | i [ 1.. q] , j [ 1.. p] ]
128
Jaromr BRAMBOR 6.2. APPROCHE MACRO BLOCS AUX TRANSPOSITIONS ET ROTATIONS
6.1.1.4 Dnition de la rotation de
2
Pareillement, la rotation de
2
dun array est dni par la fonction rot2DMinus90 :
rot2DMinus90 :: Ar ( I , I ) Ar ( I , I )
rot2DMinus90 ut = array ( (1,1) , (q,p) )
[ ( ( i , j ) , ut ! (pj+1, i ) ) | i [ 1.. q] , j [ 1.. p] ]
6.1.1.5 Dnitions de la fonction commune pour les transpositions et les rotations
Nous dnissons lalgorithme 6.1, un algorithme trivial pour le changement du sens de stockage, qui
travaille lment par lment et selon les dnitions de ces quatre oprations. Cet algorithme dnit la
fonction commune pour ces quatre oprations, trRot2D. Nous utiliserons avantageusement cette fonction
qui choisit lopration exacte selon une cl dans nos prochains algorithmes :
Algorithme 6.1 : trRot2D, dnit la fonction commune des transpositions par diagonale et par
antidiagonale et des rotations de +
2
et de
2
travaillant lment par lment directement selon
les dnitions de ces oprations
1 trRot2D :: [ Char] Ar ( I , I ) Ar ( I , I )
2 trRot2D Iov ut | Iov == "TD" = tr2DDiag ut
3 | Iov == "TA" = tr2DADiag ut
4 | Iov == "R+" = rot2DPlus90 ut
5 | Iov == "R" = rot2DMinus90 ut
6.2 Approche macro blocs aux transpositions et rotations
Bien que nous puissions utiliser les transpositions des arrays selon leurs dnitions travaillant l-
ment par lment, notre intrt pour les architectures ux nous incite exploiter le paralllisme de
donnes, trouver les algorithmes qui seraient plus intressants pour le traitement en parallle et, par
consquent, plus efcaces que si on utilisait le traitement squentiel.
Le coeur de notre approche se situe dans le travail par blocs. Nous allons dcouper un array dune
faon rgulire et prdnie des macro blocs. La gure 6.1 illustre cette situation pour le dcoupage
dun array 3 3 macro blocs.
D
(2,1)
A
(1,1)
G
(3,1)
E
(2,2)
B
(1,2)
H
(3,2)
F
(2,3)
C
(1,3)
I
(3,3)
FIG. 6.1 :
Dcoupage dun
array 3 3 macro
blocs
Il est remarquer quen thorie, les dimensions dun macro bloc peuvent ne
pas tre gales et de plus, elles ne sont pas obliges dtre ni de puissance 2, ni
un multiple de 2. La transposition dun bloc M N dune dimension impaire est
possible, en se rduisant, pour les dimensions gales 1 1, un cas trivial de
dcoupage par lment. En pratique, nous allons utiliser plutt les blocs conve-
nables notre architecture matrielle, le plus souvent des dimensions de multiples
de 2 et de puissance 2. Mais il est possible denvisager, pour les architectures d-
dies, une solution diffrente, e.g. des dimensions de multiples de 2 mais pas de
puissance 2.
Une fois larray dcoup, les oprations de transposition ou de rotation vont
se diviser en deux sous-problmes :
transposition/rotation lchelle des macro blocs et,
transposition/rotation lintrieur de chacun des macro blocs.
En effet, les transpositions/rotations partielles lintrieur des macro blocs sont des tches indpendantes
et peuvent tre excutes ainsi. La transposition lchelle globale qui manipulera les macro blocs va
assurer la mme opration au niveau de la granularit crue. La gure 6.2 illustre cette philosophie.
129
D
(2,1)
A
(1,1)
G
(3,1)
E
(2,2)
B
(1,2)
H
(3,2)
F
(2,3)
C
(1,3)
I
(3,3)
D
A
G
E
B
H
F
C
I
B
TD
(2,1)
A
TD
(1,1)
C
TD
(3,1)
E
TD
(2,2)
D
TD
(1,2)
F
TD
(3,2)
H
TD
(2,3)
G
TD
(1,3)
I
TD
(3,3)
(a) Transposition dun array par la diagonale
D
(2,1)
A
(1,1)
G
(3,1)
E
(2,2)
B
(1,2)
H
(3,2)
F
(2,3)
C
(1,3)
I
(3,3)
D
A
G
E
B
H
F
C
I
H
TA
(2,1)
I
TA
(1,1)
G
TA
(3,1)
E
TA
(2,2)
F
TA
(1,2)
D
TA
(3,2)
B
TA
(2,3)
C
TA
(1,3)
A
TA
(3,3)
(b) Transposition dun array par lantidiagonale
F
R+
(1,2)
B
R+
(2,1)
E
R+
(2,2)
A
R+
(3,1)
D
R+
(3,2)
I
R+
(1,3)
H
R+
(2,3)
G
R+
(3,3)
D
(2,1)
A
(1,1)
G
(3,1)
E
(2,2)
B
(1,2)
H
(3,2)
F
(2,3)
C
(1,3)
I
(3,3)
D
A
G
E
B
H
F
C
I
C
R+
(1,1)
(c) Rotation dun array de +
2
A
E D F
H G I
B C
D
(2,1)
A
(1,1)
G
(3,1)
E
(2,2)
B
(1,2)
H
(3,2)
F
(2,3)
C
(1,3)
I
(3,3)
G
R-
(1,1)
D
R-
(1,2)
A
R-
(1,3)
H
R-
(2,1)
E
R-
(2,2)
B
R-
(2,3)
I
R-
(3,1)
F
R-
(3,2)
C
R-
(3,3)
(d) Rotation dun array de
2
FIG. 6.2 : Transpositions et rotations dun array utilisant lapproche macro blocs
130
Jaromr BRAMBOR 6.2. APPROCHE MACRO BLOCS AUX TRANSPOSITIONS ET ROTATIONS
Lapproche de travail par les macro blocs est gnrale et peut tre implmente sur nimporte quelle
architecture, parallle ou squentielle. Nous nous en servons sur les architectures SWAR et nous allons
en dcouvrir lutilit pratique en exploitant les capacits SIMD, ce qui aboutira aux algorithmes plus
rapides. Des performances encore meilleures peuvent tre obtenues sur les architectures o nous pouvons
exploiter le paralllisme de donnes et de tche, implicitement prsent dans ces algorithmes, e.g. sur les
architectures multithread.
6.2.1 Dcoupage des arrays en macro blocs et leur recollage
Commenons notre explication du fonctionnement par macro blocs avec lintroduction formelle du
dcoupage et du recollage des arrays.
Nous avons besoin de dnir une fonction de dcoupage dun array 2D en arrays 2D plus petits,
tous ayant des dimensions identiques. La fonction arrayToMxNBlocs dnit ce dcoupage. Elle prend
comme arguments un array et deux paramtres, m et n, qui indiquent le nombre de macro blocs voulus
dans larray de sortie, respectivement dans la premire et deuxime dimension. La fonction retourne un
array de dimensions (m, n) dont les lments sont galement des arrays :
arrayToMxNBlocs :: I I Ar ( I , I ) Ar ( I , I ) ( Ar ( I , I ) )
arrayToMxNBlocs m n ut =
array ( (1,1) , (m,n))
[ ( ( i , j ) , array ( (1,1) , (p,q) ) [ ( (I, l ) , ut ! ( ( i 1)p+I, ( j 1)q+l ) )
| (I, l ) range ( (1,1) , (p,q) ) ] )
| ( i , j ) range ( (1,1) , (m,n)) ]
where
(J
:
,J
z
) = dimsAr2D ut ; p = div J
:
m; q = div J
z
n
Nous dnissons galement une fonction de composition, duale la fonction de dcoupage, qui
construit un array complet partir dun array dcoup en macro blocs. La fonction arrayFromMxNBlocs
effectue cette tche :
arrayFromMxNBlocs :: Ar ( I , I ) ( Ar ( I , I ) ) Ar ( I , I )
arrayFromMxNBlocs ut =
array ( (1,1) , (p,q) )
[ ( ( ( i 1)J
:
+I, ( j 1)J
z
+l ) , ut ! ( i , j ) ! (I, l ) )
| ( i , j ) range ( (1,1) , (m,n)) , (I, l ) range((1,1) , (J
:
,J
z
) ) ]
where
(m,n) = dimsAr2D ut ; (J
:
,J
z
) = dimsAr2D (ut ! (1,1) ) ; p = J
:
m; q = J
z
n
6.2.2 Lalgorithme gnrique travaillant sur les macro blocs
Nous avons dj mentionn, dune faon informelle, comment les algorithmes de transposition et de
rotation vont travailler sur les macro blocs. Ce qui nous reste dtailler maintenant, cest la reprsentation
formelle dun algorithme qui dcrirait ce procd.
Nous nous apercevons que les algorithmes de transposition (par la diagonale et antidiagonale) et de
rotation (de +
2
et de
2
) sont trs similaires dans leur fonctionnement. En effet, la structure de ces
algorithmes est la mme, ce qui change cest lopration exacte qui est effectue. Nous allons en proter
pour introduire un algorithme qui assure la structure de fonctionnement de ces quatre algorithmes et qui
est dcrit par lalgorithme 6.2 comme fonction trRot2DMB.
Pour dnir une opration spcique, nous devons choisir les valeurs des arguments de ce skeleton.
Les paramtres m et n dsignent les nombres de blocs dans le premier et le deuxime axe sur lesquelles
larray dentre ut sera dcoup. Le paramtre Iov est un paramtre textuel et dsigne lopration
excuter. Les valeurs que nous pouvons passer par ce paramtre sont TD, T^, P + et P et
correspondent aux clefs de la fonction de dnition commune pour les transpositions et les rotations,
trRot2D. Cest en utilisant cette fonction que nous dnissons les fonctions globales, |p, et locales, |I,
lintrieur de cet algorithme.
131
Algorithme 6.2 : trRot2DMB, algorithme de la transposition/rotation par macro blocs. Les para-
mtres m et n dsignent en combien de macro blocs larray dentre ut sera dcoup pour le travail,
le paramtre Iov dnit lopration souhaite.
1 trRot2DMB :: [ Char] I I Ar ( I , I ) Ar ( I , I )
2 trRot2DMB Iov m n ut =
3 arrayFromMxNBlocs
4 |p
5 ( listArray ( (1,1) , (m,n)) )
6 (map |I )
7 elems
8 (arrayToMxNBlocsmn)
9 $ut
10 where
11 |p = trRot2D Iov
12 |I = trRot2D Iov
Expliquons son fonctionnement. Il est, en effet, assez simple. Nous commenons la lecture sur la
ligne 9 o nous voyons larray dentre ut et nous allons continuer vers les lignes prcdentes. Nous
appliquons sur cet array la fonction de dcoupage arrayToMxNBlocs (sur la ligne 8). Ainsi, nous ob-
tenons un array 2D dont les lments sont des arrays 2D plus petits qui constituent nos macro blocs.
Aprs lapplication de la fonction elems, standard du Haskell, nous obtenons un stream des macro blocs,
exprim comme une liste. Sur la ligne 6, nous appliquons la fonction locale |I sur tous les lments de
ce stream en utilisant la fonction map du Haskell. Sur la ligne 5, en utilisant la fonction listArray, nous
reconstituons un array de A ^ macro blocs partir du stream des lments pour y appliquer, sur la
ligne 4, la fonction globale |p. la n, sur la ligne 3, nous passons, aprs lapplication de la fonction
arrayFromMxNBlocs, partir dun array des macro blocs un array classique 2D qui est retourn par le
skeleton comme rsultat.
Notons que selon la prescription de cet algorithme, nous appliquons dabord la fonction locale |I et
puis la fonction globale |p. Mais lapproche duale peut tre galement effectue avec dabord lapplica-
tion de la fonction globale |p et puis la fonction du grain n |I, exprim formellement par le changement
des lignes 4 7 dans lalgorithme 6.2 pour :
4 ( listArray $ ( (1,1) , (m,n)) )
5 (map |I )
6 elems
7 |p
Cette manipulation est plutt thorique et philosophique pour les architectures GPP car pour elles, cest
notre manire dindexer lors des lectures/critures des donnes de/ la mmoire qui assure la fonction
globale. En revanche, le changement de ces lignes peut correspondre, sur les architectures matrielles
ddies, la modication du rseau dinterconnexions. Remarquons que les deux possibilits dlivrent
les mmes rsultats.
Utilisant le skeleton algorithmique dcrit prcdemment, les dnitions des transpositions et des ro-
tations des arrays par macro blocs sont faciles driver. La fonction tr2DDiagMB dnit la transposition
dun array par la diagonale en utilisant lapproche macro blocs et travaille lintrieur des macro blocs
lment par lment :
tr2DDiagMB :: I I Ar ( I , I ) Ar ( I , I )
tr2DDiagMB m n ut = trRot2DMB "TD" m n ut
La fonction tr2DADiagMB dnit la transposition dun array par lantidiagonale en utilisant lapproche
macro blocs et travaille lintrieur des macro blocs lment par lment :
tr2DADiagMB :: I I Ar ( I , I ) Ar ( I , I )
tr2DADiagMB m n ut = trRot2DMB "TA" m n ut
132
Jaromr BRAMBOR 6.3. ALGORITHMES RAPIDES SIMD DE TRANSPOSITION ET DE ROTATION
La fonction rot2DPlus90MB dnit la rotation dun array de +
2
en utilisant lapproche macro blocs et
travaille lintrieur des macro blocs lment par lment :
rot2DPlus90MB :: I I Ar ( I , I ) Ar ( I , I )
rot2DPlus90MB m n ut = trRot2DMB "R+" m n ut
La fonction rot2DMinus90MB dnit la rotation dun array de
2
en utilisant lapproche macro blocs
et travaille lintrieur des macro blocs lment par lment :
rot2DMinus90MB :: I I Ar ( I , I ) Ar ( I , I )
rot2DMinus90MB m n ut = trRot2DMB "R" m n ut
6.3 Algorithmes rapides SIMD de transposition et de rotation
Nous allons nous intresser aux algorithmes qui exploiteraient les possibilits des architectures SIMD
et qui rendraient les transpositions et les rotations plus rapides quune approche directe et triviale de la
transposition ou rotation effectue lment par lment.
Mais avant de dcrire les algorithmes SIMD destins aux architectures GPPMM, nous allons prsen-
ter un outil qui va nous servir dans tout ce chapitre - les fonctions shufe.
6.3.1 Fonctions shufe
Les shufes sont les fonctions de rarrangement des lments dans les vecteurs. Dans notre cas, elles
font alterner les lments de deux vecteurs paquets selon un paramtre dnissant la faon exacte de
leur chevauchement et les placent dans un nouveau vecteur paquet de sortie. Ainsi, on les catgorise
comme les cas spciaux de la permutation des lments dun vecteur. Puisque notre intrt est de rester
abstrait dune architecture quelconque, nous introduisons les fonctions gnralises du low-shufing et
du hi-shufing qui, mme gnralises, ont leurs correspondants directs dans tous les jeux dinstructions
des architectures multimdia.
Dans les dnitions des shufes, nous utilisons deux fonctions auxiliaires, ielems et alter. La fonction
ielems prend un vecteur et une tendue dindex et retourne les lments inclus dans cette tendue :
ielems :: ( Ix ) Ar (,) [ ]
ielems ut tnp = [ ut ! i | i range$tnp]
La fonction alter cre, partir de deux listes x et de la mme taille N, une seule liste de sortie de
la taille 2N en alternant les entres. Le paramtre n rgle lalternance de cette manire : les premiers n
lments de la premire liste sont inscrits comme premiers dans la liste de sortie et suivis par n premiers
lments de la deuxime liste. Ce processus se rpte pour tous les groupes suivants de n lments des
listes dentre. Notons que la taille N des listes dentre doit tre un multiple de n.
alter :: I ( [ ] , [ ] ) [ ]
alter n (x,) = select n [ ] (x,)
where
select I z (x :x,) | I , 0 = select (I1) (z++[x ] ) (x,)
select I z (x,) | I == 0 = select n z (,x)
select I z ( [ ] , _) = z
Le low-shufing est dni par la fonction sho. Les moitis infrieures des deux vecteurs dentre
sont extraites en utilisant la fonction ielems. Leurs lments sont alterns, en utilisant la fonction alter,
avec lalternance n commenant avec le premier vecteur. La fonction dimsAr1D, dnie en Annexe B,
page 202, retourne la taille dun vecteur.
sho :: I ( PVec I , PVec I ) PVec I
sho (x ,) = listArray (1,p) ( alter ( (ielems x (1, I) ) ,
(ielems (1, I) ) ) )
where p = dimsAr1D x ; I = div p 2
133
Par dualit, le hi-shufing, est dni par la fonction shfhi. Il assure la fonctionnalit similaire sur les
moitis suprieures des deux vecteurs dentre.
shfhi :: I ( PVec I , PVec I ) PVec I
shfhi (x ,) = listArray (1,p) ( alter ( (ielems x (I+1, p) ) ,
(ielems (I+1, p) ) ) )
where p = dimsAr1D x ; I = div p 2
Notons que les arrays dentre des fonctions shufe sho et shfhi doivent avoir la mme dimension et
celle-ci doit tre de 2
m
, m N. La gure 6.3 illustre la gamme complte des shufes drivables partir
des dnitions prcdentes pour les arrays de 2
3
lments.
1,A
2,B 3,C 4,D 5,E 6,F 7,G 8,H 1,I 2,J 3,K 4,L 5,M 6,N 7,O 8,P 1,A
2,B 3,C 4,D 1,I 2,J 3,K 4,L
X Y
shflo 1 (X,Y) shfhi 1 (X,Y)
5,E 5,M 6,N 6,F 7,G 7,O 8,H 8,P 1,A
2,B 3,C 4,D 1,I 2,J 3,K 4,L
X Y
5,E 5,M 6,N 6,F 7,G 7,O 8,H 8,P
1,A
2,B 3,C 4,D 1,I 2,J 3,K 4,L
X Y
5,E 5,M 6,N 6,F 7,G 7,O 8,H 8,P
FIG. 6.3 : La gamme des fonctions shufe pour les vecteurs paquets de 8 lments
6.3.2 Dcoupage sur les macro blocs et leur recollage sur les architectures SWAR
Dans notre travail SIMD avec les architectures SWAR, il est convenable de dcouper larray dentre
en macro blocs dont les dimensions sont gales la taille N du registre qui hberge les donnes des types
multimdia. Les processeurs GPPMM les plus courants (SH-5, Intel IA-64, AMD64, Intel MMX) ont la
taille du registre multimdia de 64 bits ce qui prdestine, pour le travail avec les donnes de 8 bits, le
dcoupage en macro bloc de 8 8 lments. Le type de 8 bits est couramment utilis dans le traitement
dimages comme le type de base pour le stockage des pixels. Si nous utilisons le type de 16 bits, notre
macro bloc serait rduit 4 4 lments.
Sur les architectures diffrentes avec les registres plus larges, telles quIntel SSE2/3 dont les registres
sont de 128 bits, le choix du macro bloc peut tre diffrent. Notons que ces architectures ont la taille de
leurs registres dune puissance n de 2, N = 2
n
, ce qui satisfait les exigences des fonctions shufes sur
les dimensions des vecteurs dentre.
En plus du choix de dcoupage, nous allons accder aux donnes dans la mmoire en utilisant les
types paquets. Ainsi, nous allons percevoir les arrays dans nos dnitions comme paquets. Ce qui veut
dire qu la place de travailler avec les macro blocs de dimensions N N du type
Ar ( I , I )
nous allons travailler, aprs le paquetage, comme dni dans 4.4.3 page 68, avec les macro blocs du type
Ar ( I , I ) ( PVec I )
qui auront les lments du type PVec de taille N et o une dimension de cet array sera rduite 1.
Ainsi, nous allons travailler avec un array dune dimension qui sera stock dans un type pour les arrays
2D. Celle des dimensions qui sera rduite 1 dpendra de notre choix du sens du paquetage. Cette
perception est, en effet, un cas spcial issu du choix particulier des dimensions du macro bloc.
134
Par la suite, nous allons travailler avec ces macro blocs comme sil sagissait de ux de donnes.
Pour passer dun macro bloc un stream et vice versa, nous pourrions utiliser les fonctions gnriques
que nous avons dnies dans ce but dans le chapitre 4.4.4, page 70. Mais vu que le sens de parcours
dont nous avons besoin ici est simple et se rduit au sens au-devant, nous allons utiliser deux fonctions
standard du Haskell, elems et listArray. La premire, elems retourne une liste de tous les lments dun
array, la deuxime, listArray construit un array partir dune liste des lments. Nous allons les utiliser
dans des expressions pour passer dun array 2D exprim par la variable ut un stream comme :
elems$ut
et pour passer partir dun stream un array dont les dimensions seront les mmes que celles du array
ut comme :
listArray (bounds $ut )
Cest la mme manire de travailler que nous avons dj mentionne dans lalgorithme gnral par macro
blocs, cf. lalgorithme 6.2, et elle est sufsante et assez intuitive pour les explications qui sont dcrites
dans la suite de ce chapitre.
6.3.3 Shufes utiliss pour les transpositions et rotations dun macro bloc
Notre approche par macro blocs dont la taille est drive de la taille du registre multimdia dune ar-
chitecture nous mne une application trs intressante des fonctions shufe. En choisissant leur bonne
combinaison et leur bon enchanement suivi par lapplication sur les donnes paquetes dun macro-bloc,
nous pouvons assurer les quatre oprations qui nous intressent (transposition par diagonale/antidiago-
nale, rotation de +
2
et de
2
).
Pour prsenter une explication claire et facile comprendre, nous allons expliquer lutilisation des
shufes sur un exemple prcis de la transposition par diagonale dun macro bloc 8 8. Une fois le pro-
cd expliqu, nous continuerons par la gnralisation de cette approche aux macro blocs de dimensions
N N, o N = 2
n
, qui inclura galement les trois oprations restantes.
6.3.3.1 Transposition par diagonale avec les shufes
Expliquons en dtail le fonctionnement de lalgorithme de la transposition par diagonale dun macro
bloc de 8 8 lments. Lalgorithme travaille sur un macro bloc exprim en tant que liste (stream) de 8
vecteurs paquets qui comptent 8 lments chacun. Il applique sur ce stream des groupes de diffrentes
fonctions shufe. Ainsi, nous percevons le traitement comme divis en tapes, en total log
2
N tapes, ce
qui implique 3 tapes pour le bloc 8 8. La gure 6.4 illustre cette situation
shflo$1
shfhi$1
shflo$1
shfhi$1
shflo$1
shfhi$1
shflo$1
shfhi$1
shflo$1
shflo$1
shfhi$1
shfhi$1
shflo$1
shflo$1
shfhi$1
shfhi$1
shflo$1
f
s
t
snd
1,1 1,2
2,1 2,2
3,1 3,2
4,1 4,2
1,3 1,4
2,3 2,4
3,3 3,4
4,3 4,4
1,5 1,6
2,5 2,6
3,5 3,6
4,5 4,6
1,7 1,8
2,7 2,8
3,7 3,8
4,7 4,8
5,1 5,2
6,1 6,2
7,1 7,2
8,1 8,2
5,3 5,4
6,3 6,4
7,3 7,4
8,3 8,4
5,5 5,6
6,5 6,6
7,5 7,6
8,5 8,6
5,7 5,8
6,7 6,8
7,7 7,8
8,7 8,8
shflo$1
shflo$1
shflo$1
shfhi$1
shfhi$1
shfhi$1
shfhi$1
1,1 2,1
1,2 2,2
1,3 2,3
1,4 2,4
3,1 4,1
3,2 4,2
3,3 4,3
3,4 4,4
5,1 6,1
5,2 6,2
5,3 6,3
5,4 6,4
7,1 8,1
7,2 8,2
7,3 8,3
7,4 8,4
1,5 2,5
1,6 2,6
1,7 2,7
1,8 2,8
3,5 4,5
3,6 4,6
3,7 4,7
3,8 4,8
5,5 6,5
5,6 6,6
5,7 6,7
5,8 6,8
7,5 8,5
7,6 8,6
7,7 8,7
7,8 8,8
FIG. 6.4 : Transposition par diagonale SIMD par shufes
Lalgorithme 6.3 dcrit formellement ce procd. Il dnit une fonction principale, tr2DDiag8x8bf,
dans le corps de laquelle nous retrouvons 3 applications successives des blocs composs de plusieurs
shufes, prsentes par les application successives de la fonction tr2DDiag8x8bf1, puis de la fonction
tr2DDiag8x8bf2 et nalement de la fonction tr2DDiag8x8bf3. Chaque tape utilise plusieurs shufes
135
Algorithme 6.3 : tr2DDiag8x8bf, Algorithme de tranposition dun macro bloc 8 8 qui utilise 3
shufes partiels (tr2DDiag8x8bf1, tr2DDiag8x8bf2, tr2DDiag8x8bf3)
.
1 tr2DDiag8x8bf :: [ PVec I ] [ PVec I ]
2 tr2DDiag8x8bf = tr2DDiag8x8bf3 tr2DDiag8x8bf2 tr2DDiag8x8bf1 $
3
4 tr2DDiag8x8bf1 :: [ PVec I ] [ PVec I ]
5 tr2DDiag8x8bf1 x = alter 4 ( (map ( sho $1) puit) , (map ( shfhi $1) puit) )
6 where puit = listDivAlter 4 x
7
11
dans une conguration diffrente. la n du traitement, nous obtenons le macro bloc, exprim par la
liste des vecteurs paquets, transpos par la diagonale.
P
V
e
c
3
P
V
e
c
7
P
V
e
c
4
P
V
e
c
8
P
V
e
c
1
P
V
e
c
5
E F G H
shflo$1
P
V
e
c
1
P
V
e
c
2
P
V
e
c
3
P
V
e
c
4
P
V
e
c
5
P
V
e
c
6
P
V
e
c
7
P
V
e
c
8
shfhi$1
listDivAlter$4 alter$4
A B C D
E F G H
A B C D
P
V
e
c
2
P
V
e
c
6
FIG. 6.5 : Illustration du fonctionnement de la fonction tr2DDiag8x8bf1
Dans les 3 fonctions partielles, la variables puit contient la liste dont les lments sont les arguments
pour les fonctions shufes. Cest notre fonction utilitaire listDivAlter qui se charge de bon ordonnan-
cement pour obtenir une liste des paires (PVec I , PVec I ) qui sont prtes tre employes sur les
fonctions shufes. La fonction alter nous sert ici la bonne organisation des rsultats dans le ux de
sortie. La g. 6.5 illustre ce processus pour la fonction tr2DDiag8x8bf1.
En effet, cette faon de diviser des streams dentre et leur alternance exprime formellement le r-
seau dinterconnexions particulier entre les donnes et les blocs excutifs. Ce rseau est galement connu
comme des papillons (angl. butteries) et il est illustr sur la g. 6.4. Notons que les ches sup-
rieures resp. infrieures lentre de chacun des blocs des oprations shufes dsignent les premiers
resp. deuximes lments dans les tuples qui constituent les arguments dentre de ces oprations.
La fonction alter tait dj prsente, page 133, mais la dnition exacte de la fonction listDivAlter
est nouvelle :
listDivAlter :: I [ ] [ (,) ]
listDivAlter n x = select n ( [ ] , [ ] ) x
where
select I ( Io, Ii ) (x :x) | I , 0 = select (I1) (Io++[x ] , Ii ) x
select I ( Io, Ii ) x | I == 0 = select n ( Ii , Io) x
select I ( Io, Ii ) [ ] = (uncurry$zip) ( Io, Ii )
Cette fonction dnit le rseau dinterconnexions. Pour une liste dentre x dont la taille est N =
2
k
, k 1, cette fonction cre une liste de taille
N
2
dont les lments sont des tuples. La cration de cette
liste de sortie passe par une phase intermdiaire o la liste dentre x est divise dune faon alterne
en deux listes, chacune de taille
N
2
, qui ne sont pas explicitement mentionnes dans la dnition mais
136
que nous pouvons nommer
1
et
2
et qui sont places dans un tuple (
1
,
2
) et sur lesquelles nous
excutons rcursivement la fonction interne select. Ainsi, les lments de la liste x sont distribus en
alternance vers les deux listes
1
et
2
, les premiers n lments vers la liste
1
, les n lments suivants
dans la liste
2
, les n suivants vers la liste
1
, etc... Quand nous arrivons la n de la liste dentre, la
liste des tuples de sortie est cre en utilisant lexpression (uncurry$zip).
Pour mieux comprendre lemploi de cette fonction, nous concrtisons la dnition du stream des
tuples des vecteurs paquets puit dans lalgorithme 6.3. Pour un stream concret [1, 2, 3, 4, 5, 6, 7, 8]
nous obtenons :
aprs lapplication de IiDiv^Iat$4 sur ce stream (comme dans tr2DDiag8x8bf1) :
puit = [ (1,5) , (2,6) , (3,7) , (4,8) ]
puit = [ (1,3) , (2,4) , (5,7) , (6,8) ]
puit = [ (1,2) , (3,4) , (5,6) , (7,8) ]
Ce qui correspond au rseau dinterconnexions des papillons pour cette opration, comme prsent sur
la g. 6.4.
Les dnitions des fonctions tr2DDiag8x8bf1, tr2DDiag8x8bf2 et tr2DDiag8x8bf3, bien quelles
soient explicites, utilisent une prescription qui numre les lments. Nous pouvons apercevoir ga-
lement quelles sont trs semblables car le cur de leur fonctionnement est donn par une et mme
expression :
( (map ( sho $1) puit) , (map ( shfhi $1) puit) )
Ils diffrent dans la manire de composer le stream des paires dentre puit par la fonction listDivAlter,
mais galement dans la composition du stream de sortie par la fonction alter.
Nous allons exploiter des points communs et nous allons rcrire ces dnitions dune faon encore
plus simple et gnralise non seulement pour les macro blocs de 8 8 lments, mais galement pour
un cas gnral dun macro bloc de N N lments, N = 2
n
et n = 1, 2, 3, ... Ainsi, nous arrivons
la dnition de lalgorithme gnralis qui nutilise que deux fonctions, tr2DDiagNxPVecNb et de
tr2DDiagNxPVecNbf et qui est dni par lalgorithme 6.4 :
Algorithme 6.4 : tr2DDiagNxPVecNbf, fonction gnralise de transposition dun macro bloc par
diagonale. Elle utilise en interne la fonction tr2DDiagNxPVecNb
1 tr2DDiagNxPVecNbf :: [ PVec I ] [ PVec I ]
2 tr2DDiagNxPVecNbf = pipe ( map tr2DDiagNxPVecNb t ) $
3 where n = rangeSize bounds $ ( ! ! 0) ; t = seqPow2 ( div n 2)
4
5 tr2DDiagNxPVecNb :: I [ ( PVec I ) ] [ ( PVec I ) ]
6 tr2DDiagNxPVecNb p x
7 = alter p ( (map ( sho $1) puit) , (map ( shfhi $1) puit) )
8 where puit = listDivAlter p x
Une seule fonction, tr2DDiagNxPVecNb, dnit maintenant tous les groupes des shufes pour la
transposition par diagonale. Cette fonction modie son comportement selon le paramtre p choisissant
ainsi la bonne conguration des lments dentre. La valeur de p est une des valeurs de squence t des
puissances de 2 dnie par la fonction seqPow2.
seqPow2 :: Int [ Int ]
seqPow2 x = fnc x [ ]
where
fnc I x | I 1 = fnc ( div I 2) ( [ I ]++x)
fnc I x | I == 0 = x
137
Cette fonction retourne une liste des nombres de puissance 2. La liste contient des numros commen-
ant par 1 et allant jusqu lgalit avec le paramtre x, e.g. [1, 2, 4, 8, 16, 32] pour la valeur de x gale
32. La valeur du paramtre doit tre une puissance de 2.
La fonction tr2DDiagNxPVecNbf dnit tout lalgorithme et applique log
2
N tapes de shufes bien
choisis en utilisant la fonction pipe. Tout le travail est cach dans lexpression
pipe (map tr2DDiagNxPVecNb t)
Une liste t est cre par la fonction seqPow2 et contient les valeurs 2
0
, 2
1
, ..2
m1
, 2
m
o m est une
puissance de 2 qui est, dans ce cas, gale m = log
2
N 1. Ainsi, lexpression peut tre rcrite, dune
faon informelle et aprs lapplication de map, comme une liste :
pipe ( [ tr2DDiagNxPVecNb$1,
tr2DDiagNxPVecNb$2,
.. ,
tr2DDiagNxPVecNb$(log
z
N1)])
Ainsi, nous avons dcrit dune faon gnrale, le fonctionnement de la transposition par diagonale pour
un macro bloc de NxN lments, N = 2
n
et n = 1, 2, 3, .., organis comme une liste dont les lments
sont les vecteurs paquets.
De la mme faon, nous allons dnir les algorithmes pour la transposition par lantidiagonale, pour
la rotation de

2
et de
2
. Lapproche est directe et mne aux dnitions dans lesquelles nous allons
remarquer le changement mutuel, soit des fonctions shufe, soit de lordre dans la prparation des argu-
ments pour les shufes, soit des deux.
6.3.3.2 Transposition par antidiagonale avec les shufes
La transposition par antidiagonale dun macro bloc qui utilise les shufes est dnie par la fonc-
tion tr2DADiagNxPVecNbf qui utilise linterne la fonction tr2DADiagNxPVecNb. Nous remar-
quons que cette dnition a la mme structure que la transposition par diagonale, dnie par la fonction
tr2DDiagNxPVecNbf dans lalgorithme 6.4.
1 tr2DADiagNxPVecNbf :: [ PVec I ] [ PVec I ]
2 tr2DADiagNxPVecNbf = pipe ( map tr2DADiagNxPVecNb t) $
4
5 tr2DADiagNxPVecNb :: I [ ( PVec I ) ] [ ( PVec I ) ]
6 tr2DADiagNxPVecNb p x
7 = alter p ( (map ( shfhi $1) (xchng$puit) ) , (map ( sho $1) (xchng$puit) ) )
Ce qui a chang, cest lexpression sur la ligne 7, o nous pouvons percevoir lchange mutuel des
fonctions shufe shfhi$1 et sho$1 et galement lapplication de la fonction xchng sur la variable puit
qui change lordre dans les arguments pour les fonctions shufe. La dnition exacte de la fonction xchng
qui, pour une liste des tuples donne, change lordre dans tous les tuples de cette liste, est la suivante :
xchng :: [ (,) ] [ (,) ]
xchng [ ] = [ ]
xchng ( (x ,) : ) = (,x) : (xchng )
6.3.3.3 Rotation de +
2
avec les shufes
La rotation de

2
peut tre dnie de la mme manire. La fonction rot2DPlus90NxPVecNbf qui
utilise linterne la fonction rot2DPlus90NxPVecNb a la mme structure que les deux oprations
prcdentes. Un changement est prsent, cest celui de la ligne 7 qui change mutuellement lordre des
arguments des fonctions shufe. Il est exprim via lapplication de la fonction xchng applique sur la
variable puit.
138
1 rot2DPlus90NxPVecNbf :: [ PVec I ] [ PVec I ]
2 rot2DPlus90NxPVecNbf = pipe ( map rot2DPlus90NxPVecNb t) $
4
5 rot2DPlus90NxPVecNb :: I [ ( PVec I ) ] [ ( PVec I ) ]
6 rot2DPlus90NxPVecNb p x
7 = alter p ( (map ( sho $1) (xchng$puit) ) , (map ( shfhi $1) (xchng$puit) ) )
6.3.3.4 Rotation de
2
avec les shufes
De la mme manire, nous dnissons la rotation de

2
par la fonction rot2DMinus90NxPVecNbf
qui utilise linterne la fonction rot2DMinus90NxPVecNb. Ces dnitions diffrent de la fonction de
transposition par diagonale dans lchange mutuel des fonctions shufe shfhi$1 et sho$1 sur la ligne 7.
1 rot2DMinus90NxPVecNbf :: [ PVec I ] [ PVec I ]
2 rot2DMinus90NxPVecNbf = pipe ( map rot2DMinus90NxPVecNb t) $
4
5 rot2DMinus90NxPVecNb :: I [ ( PVec I ) ] [ ( PVec I ) ]
6 rot2DMinus90NxPVecNbp x
7 = alter p ( (map ( shfhi $1) puit) , (map ( sho $1) puit) )
6.3.3.5 Algorithme gnralis de transposition et de rotation dun macro bloc par les shufes
Les similitudes que lon a pu apercevoir dans les dnitions prcdentes des transpositions et des
rotations par macro blocs nous incitent penser que lon pourrait regrouper les quatre fonctions en un seul
algorithme gnralis qui rutiliserait les parties qui se rptent.
En effet, cest possible et lalgorithme 6.5 dcrit cette gnralisation. Comme nous pouvons le voir, la
structure donne par la fonction trRot2DNxPVecNbf reste la mme, le fonctionnement de lalgorithme
est modi par le premier paramtre qui exprime le type dopration excuter. Celui-ci est pass
la fonction interne de cet algorithme, trRot2DNxPVecNb, qui se charge du bon choix de lopration.
Les valeurs de ce paramtre, les abrviations "TD", "TA", "R+" et "R-", dsignent respectivement la
transposition par diagonale, la transposition par antidiagonale, la rotation de

2
et nalement la rotation
de
2
.
Algorithme 6.5 : trRot2DNxPVecNbf, algorithme gnralis de transposition et rotation dun ar-
ray 2D ^xPVat^, utilise la fonction trRot2DNxPVecNb
1 trRot2DNxPVecNbf :: [ Char] [ PVec I ] [ PVec I ]
2 trRot2DNxPVecNbf Iov = pipe ( map (trRot2DNxPVecNb$Iov) t) $
4
5 trRot2DNxPVecNb :: [ Char] I [ ( PVec I ) ] [ ( PVec I ) ]
6 trRot2DNxPVecNb Iov p x
7 | Iov == "TD"
8 = alter p ( (map ( sho $1) puit) , (map ( shfhi $1) puit) )
9 | Iov == "TA"
10 = alter p ( (map ( shfhi $1) (xchng$puit) ) , (map( sho $1) (xchng$puit) ) )
11 | Iov == "R+"
12 = alter p ( (map ( sho $1) (xchng$puit) ) , (map( shfhi $1) (xchng$puit) ) )
13 | Iov == "R"
14 = alter p ( (map ( shfhi $1) puit) , (map( sho $1) puit) )
139
Ce skeleton algorithmique est important car il nous permet, par la suite, de dnir facilement lalgo-
rithme complet pour les quatre oprations en les distinguant par un seul paramtre.
6.3.4 Algorithme complet pour les transpositions et les rotations par SIMD
Une fois expliqu ce qui se passe lintrieur dun macro bloc, nous allons dtailler le processus pour
les transpositions et les rotations des arrays. Pour cela, nous allons revenir lalgorithme 6.2, prsent
prcdemment sur la page 132, qui dcrivait le skeleton algorithmique pour les transpositions/rotations
par macro blocs en travaillant lment par lment. Il va nous servir comme modle pour la construction
dun nouvel algorithme.
Ce nouvel algorithme, que nous prsentons ici comme lalgorithme 6.6, va utiliser pour son travail
lapproche SIMD. Ainsi, laccs aux donnes sera effectu en utilisant les types des vecteurs paquets.
Ce qui signie que cet algorithme va percevoir larray dentre comme un array dont les lments sont
du type des vecteurs paquets PVec. Par la suite, il dcoupera cet array en macro blocs et il effectuera
lopration choisie localement lintrieur de chacun des macro blocs en utilisant, bien sr, les algo-
rithmes SIMD dcrits prcdemment. Puis il effectuera la mme opration globalement avec les macro
blocs en utilisant lalgorithme de base issue de la dnition de cette opration.
Algorithme 6.6 : trRot2DMBSIMD, algorithme complet de la transposition et rotation dun array
2D utilisant lapproche macro bloc et les fonctionnalits SIMD
1 trRot2DMBSIMD :: [ Char] [ Char] I Ar ( I , I ) Ar ( I , I )
2 trRot2DMBSIMD Iov uxa mIiza ut =
3 (mkAr2DFromAr2DPVec uxa)
4 arrayFromMxNBlocs
5 |p
6 ( listArray ( (1,1) , (m,n)) )
7 (map ( listArray ( (1,1) , (1, mIiza ) ) ) )
8 (map |I )
9 (map elems)
10 elems
11 (arrayToMxNBlocs mn )
12 (mkAr2DPVec uxa mIiza )
13 $ut
14 where
15 (p,q) = dimsAr2D ut ; (m,n) = ( ( div p mIiza ) , ( div q mIiza ) )
16 |p = trRot2D Iov
17 |I = trRot2DNxPVecNbf Iov
Les paramtres de cet algorithme sont les suivants : Iov dsigne le type dopration effectuer et
peut avoir les valeurs TD pour la transposition par diagonale, T^ pour la transposition par lantidia-
gonale, P + pour la rotation de +
2
et P pour la rotation de
2
. Le paramtre uxa dsigne le
sens de vectorisation et peut avoir les valeurs | pour le premier axe et SnJ pour le deuxime. Le
paramtre mIiza dsigne la taille des macro blocs et ut dsigne larray dentre.
Expliquons alors, pas pas, la construction exacte de cet algorithme. La lecture commence sur la
ligne 13 et on va progresser vers les lignes prcdentes. La premire tape est constitue du passage
dun array ut (ligne 13) avec les lments du type un array avec les lments paquets PVec I .
Pour effectuer cela, nous allons utiliser la fonction mkAr2DPVec (ligne 12) avec la bonne cl, soit |,
soit SnJ. Le choix du sens de la vectorisation est prdni par laxe de stockage des donnes dans la
mmoire. Ensuite, en utilisant la fonction elems, nous extrayons tous les lments de cet array vectoris
et nous les plaons dans un stream (ligne 10). Pour pouvoir appliquer les fonctions macro blocs SIMD
comme dcrites prcdemment, nous devons passer, pour chacun des macro blocs, son expression en
140
Jaromr BRAMBOR 6.4. NOTES SUR LIMPLMENTATION, RSULTATS EXPRIMENTAUX
tant que stream. Cest effectu par le mapping (map elems) sur la ligne 9. Nous obtenons ainsi un stream
des streams, formellement dcrit comme :
[ [ PVec I ] ]
Sur la ligne 8, nous appliquons la fonction locale par lexpression (map |I) chacun des macro blocs
exprims en stream. Ensuite, sur la ligne 7, nous passons lexpression des macro blocs en tant que
array 2D et nous reconstituons nouveau un array dont les lments sont les macro blocs sur la ligne 6.
Lopration globale, |p, est applique sur cet array reconstitu (sur la ligne 5) achevant ainsi notre opra-
tion. Ce qui reste faire cest de passer partir dun array des macro blocs un array dont les lments
sont les vecteurs paquets (sur la ligne 4) pour, la n, appliquer une opration inverse la vectorisation
qui donne comme rsultat un array du mme type que celui dentre de la fonction, du type Ar (I, I) .
Ainsi, nous avons obtenu lopration souhaite en utilisant lapproche macro bloc et en employant
les oprations SIMD sur les macro blocs.
6.4 Notes sur limplmentation, rsultats exprimentaux
Il y a, en effet, autant de faons dimplmenter les algorithmes dcrits dans ce chapitre quil y a
darchitectures, de programmeurs pour lcriture et de compilateurs pour la compilation du code.
Les implmentations sur les architectures parallles peuvent tre facilement dduites de nos des-
criptions formelles des algorithmes prsents dans ce chapitre. Le paralllisme le plus simple, utilisable
dans ces cas, est celui de la replication fonctionnelle reprsente par le skeleton algorithmique farm,
cf. 4.4.2.1, page 67. Pour lemployer, nous nous intressons toutes les parties de notre algorithme qui
utilisent la fonction map de lapplication dune fonction sur tous les lments dun stream. Toutes ces
parties peuvent tre rcrites en utilisant le skeleton algorithmique farm la place de la fonction map.
Ainsi, nous changeons compltement la manire de travailler dune telle partie de notre algorithme et
nous passons de lexcution en squence, exprime par map, lexcution en parallle, exprime par
farm. Le choix exact dpend de nos exigences et de nos possibilits matrielles lors de limplmentation.
De plus, ces algorithmes entrent dans la logique du paradigme Divide and Conquer, prsent par
le skeleton algorithmique dc, cf. 4.4.2.2, page 67. La division dun problme global des problmes
plus petits et locaux est propre aux algorithmes de ce chapitre travaillant sur les macro blocs. Il serait
galement envisageable dexprimer ces algorithmes en termes du Divide and conquer et en utilisant le
skeleton algorithmique dc car la manire de travailler de ce skeleton est identique ce que nous faisons
par le dcoupage dun array sur les macro blocs, lapplication de la fonction locale et son recollage
effectu la n.
Concernant limplmentation SIMD, la premire chose que nous devrions souligner est la demande
dalignement des donnes de limage dans la mmoire aux bornes qui sont les multiples de la taille N
du registre multimdia. Si limage a des dimensions qui sont des multiples de N et si, de plus, elles
est aligne aux blocs de mmoire par N, notre implmentation se rvle simple. Dans le cas contraire,
nous devrions faire face aux effets particuliers du travail avec les donnes non-alignes. Laccs aux
donnes non-alignes est possible sur les architectures multimdia via les instructions spcialises pour
un accs non-align mais le cot dun tel accs est, en gnral, suprieur un accs aligne. Cest du
au fait que pour la lecture dune donne non-aligne vers un registre, larchitecture utilise deux lectures
conscutives des zones alignes couvrant les donnes voulues suivies par leur extraction vers le registre.
Ces instructions peuvent avoir un cot relativement faible, mesur dans les cycles dhorloge, comme
cest le cas pour les instructions Intel SSE3. La gure 6.7 illustre un exemple de la transposition dune
image aligne mais dont les dimensions ne sont pas un multiple de la taille du registre multimdia.
Nous prsentons galement deux exemples du code en langage C implmentant la transposition dun
macro bloc par la diagonale.
Le premier, prsent sur la g. 6.6, est un code qui provient du MorphoMedia, un outil logiciel que
nous avons dvelopp dans le cadre de cette thse. Il sagit dun code programm comme les direc-
tives du prprocesseur (cf. #define) qui utilise les fonctions commenant par mrph_asm_ qui nous
141
f
s
t
64-bit
(8x8-bit)
snd
lments
infortmatifs
de limage
A
f
s
t
snd
B C
D E F
G H I
A
TD
D
TD
B
TD
E
TD
G
TD
C
TD
F
TD
H
TD
I
TD
FIG. 6.7 : La transposition dun array dont les dimensions ne sont pas un multiple de la taille dun registre
multimdia de 64 bits ; TD = macro bloc transpos par la diagonale
servent comme les invariables architecturales dans notre code. Ainsi, le mme code peut tre rutilis sur
plusieurs architectures multimdia.
#define MRPH_MACRO_TrByMainDiagonal_8x8_t8(\
A0, A1, A2, A3, A4, A5, A6, A7, \
B0, B1, B2, B3, B4, B5, B6, B7 \
) \
{\
B0 = mrph_asm_mshflo_iu8vec8(A0, A4);\
B4 = mrph_asm_mshfhi_iu8vec8(A0, A4);\
\
A0 = mrph_asm_mshflo_iu8vec8(B0, B2);\
A2 = mrph_asm_mshfhi_iu8vec8(B0, B2);\
\
}
FIG. 6.6 : Code de la transposition par diago-
nale dun macro bloc 8 8 en langage C uti-
lisant loutil de dveloppement multiplateforme
MorphoMedia
Le deuxime exemple est prsent sur la g. 6.8. Il
sagit dun code crit manuellement qui assure la mme
fonctionnalit de transposition dun macro bloc par la
diagonale mais qui utilise les fonctions intrinsques
du compilateur pour les processeurs compatibles Intel
MMX/SSE2.
La table 6.1 prsente les rsultats exprimentaux
pour la transposition par la diagonale et par lantidia-
gonale dune image 512 512 dont les lments sont
du type unsigned integer de 8 bits sur le processeur In-
tel Pentium 4 de 2.4 GHz par lexcution en un seul
thread. La zone de mmoire o sont stockes les don-
nes est distincte lentre et la sortie. Nous consta-
tons un gain de temps dj entre limplmentation g-
nrique qui consiste en lutilisation des fonctions dac-
cs au pixel et une implmentation qui utilise le tra-
vail avec les pointeurs. Mais le gain que nous obtenons
lors de lutilisation des instructions MMX est plus int-
ressant, surtout si nous comptons utiliser la transposi-
tion comme une des oprations de base dans nos algo-
rithmes de morphologie mathmatique.
Ce qui peut tre assez surprenant cest la dure
de limplmentation gnrique et mme celle via poin-
ter++ pour un tel algorithme de base sur une machine relativement puissante de nos jours et cadence
2.4 GHz. Ainsi, nous accueillons avec plaisir la possibilit dobtenir, sans aucun investissement dans le
matriel existant, un algorithme plus rapide.
La gure 6.9 nous montre les reprsentations graphiques des tests de performance que nous avons
effectu pour lalgorithme de la transposition par diagonale et plusieurs tailles dimages. lchelle
logarithmique, nous verrons bien que la diffrence entre les implmentations non-SIMD (gnrique et
via pointer++) o nous avons laiss toutes les optimisations au compilateur, et celles qui implmentent
notre algorithme SIMD est importante pour toutes les tailles dimages. Avec grands taux dacclrations
slevant jusqu 33.8 pour les images de 1024 1024 de 8 bits si on compare limplmentation SIMD
utilisant la technologie Intel SSE2 et limplmentation classique via pointer++ (cf. tab. 6.1).
142
Image
Transposition par
Mthode diagonale antidiagonale
dimplmentation Temps Taux Temps Taux
ms dacclration ms dacclration
512
2
8 bits
gnrique lment par lment 2.61 0.58 3.02 0.50
via pointer++ 1.51 1.00 1.51 1.00
instructions MMX 0.30 5.03 0.31 4.87
instructions SSE2 0.23 6.57
1024
2
8 bits
gnrique lment par lment 61.3 0.99 61.9 0.99
via pointer++ 60.9 1.00 61.7 1.00
instructions MMX 2.2 27.7 2.2 28.0
instructions SSE2 1.8 33.8
Implmentation sur Intel Pentium 4 @ 2.4 GHz (single thread, 8 ko L1, 512 ko L2). La zone de mmoire de sortie est distincte de
celle dentre. Compilateur Intel ICC 8. Taux dacclration est calcul par rapport limplmentation via pointer++ que nous
prenons comme talon (en gras).
TAB. 6.1 : Algorithmes de transposition par diagonale et antidiagonale ; comparaison des temps de calcul et
des taux dacclration pour diverses implmentations et des tailles dimages
void inline Transpose8x8_SSE2(
Iu8vec8 & mm0, Iu8vec8 & mm1,
Iu8vec8 & mm6, Iu8vec8 & mm7
)
{
__m128i xmm0, xmm1, xmm2, xmm3,
__m128i xmm4, xmm5, xmm6, xmm7;
xmm0 = _mm_movpi64_epi64( (__m64 &) mm0 );
xmm4 = _mm_unpacklo_epi8(xmm0, xmm4);
xmm2 = xmm6;
xmm3 = xmm7;
xmm6 = _mm_unpackhi_epi8(xmm4, xmm6);
xmm1 = xmm3;
xmm5 = xmm7;
(__m64 &)mm0 = _mm_movepi64_pi64(xmm1);
xmm1 = _mm_srli_si128(xmm1, 8);
_mm_empty();
return;
}
FIG. 6.8 : Code de la transposition par diagonale
dun macro bloc 8 8 crit manuellement en
langage C en utilisant le jeu dinstructions 128
bits Intel SSE2
Le deuxime graphique de la mme gure, 6.9(b),
nous prsente encore un comportement intressant des
processeurs sur les chiffres des temps dexcution nor-
maliss pour 1 pixel. Il sagit de limpact de la mmoire
cache sur le calcul des images dont la taille excde celle
de la mmoire cache. Il sagit, dans ce cas prcis, de la
mmoire cache L2 de notre processeur Intel Pentium 4
et dont la taille est de 512 ko.
Il y a, en effet, deux points remarquer. Premire-
ment, on voit bien que pour les images qui entrent en-
tirement dans la mmoire cache (images 128
2
, 256
2
et
512
2
), le cot du calcul est moindre celui des images
qui ny entrent pas (1024
2
, 2048
2
, 4096
2
). Pour les
dernires, nous ne protons pas dun accs rapide aux
donnes et le surcot devrait correspondre au temps
dattente relative la prparation des donnes non-
prsentes dans la mmoire cache.
Deuximement, nous pouvons apercevoir un com-
portement particulier pour les images 1024
2
, 2048
2
,
4096
2
, cest--dire les images dont la taille est plus
grande que celle de la mmoire cache L2. Pour ces
dernires, lcart entre les implmentations SIMD et
non-SIMD est beaucoup plus important que pour les
images qui entrent entirement dans la mmoire cache.
Pourtant, le surcot des transferts des donnes entre la
mmoire cache et la mmoire principale devrait tre,
en thorie, le mme pour les deux manires dimpl-
mentation, puisque le volume de donnes transfres
est identique.
Lexplication de ce comportement na pas pu tre
identie mais vu que les temps de traitement de-
viennent importants pour les grandes images, nous
nexcluons pas la possibilit que ce comportement soit
li la manire dexcution de notre programme dans le systme dexploitation multi-tche, Linux Man-
143
0,01 0,1 1 10 100 1000 10000
128x128x8
256x256x8
512x512x8
1024x1024x8
2048x2048x8
4096x4096x8
temps / ms
SSE2
MMX
p++
gnrique
(a) Temps du calcul
0,1 1 10 100
128x128x8
256x256x8
512x512x8
1024x1024x8
2048x2048x8
4096x4096x8
temps / ns
SSE2
MMX
p++
gnrique
(b) Temps du calcul normalis pour 1 pixel
FIG. 6.9 : Rsultats de diverses implmentations de la transposition par diagonale pour diffrentes tailles
dimages
drake 9.1 dans ce cas-l, la manire de mesure du temps (plusieurs itrations, temps moyen) ou un
autre phnomne connexe lenvironnement dexcution.
6.5 Rcapitulation, perspectives
Nous avons prsent, dans ce chapitre, quatre oprations possibles pour pouvoir changer le sens de
stockage des arrays qui sont notre structure des donnes de base pour les images. Nous avons prsent
galement trois approches possibles leurs implmentations.
Il sagit de lalgorithme 6.1 qui dnit, travers de la fonction trRot2D, un algorithme travaillant
lment par lment et implmentant la dnition de ces oprations. Le deuxime algorithme que nous
avons prsent tait lalgorithme 6.2 qui dnit, travers la fonction trRot2DMB, un algorithme tra-
vaillant avec le dcoupage de larray dentre en macro blocs et qui excute les oprations localement
lintrieur de chacun de ceux-ci lment par lment mais qui excute la mme opration galement
lchelle des macro blocs. Le troisime algorithme, lalgorithme 6.6, qui dnit, travers la fonction
trRot2DMBSIMD, un algorithme qui travaille en utilisant les macro blocs mais qui emploie lintrieur
de ceux-ci les instructions spcialises des architectures multimdia les fonctions shufe.
144
Jaromr BRAMBOR 6.5. RCAPITULATION, PERSPECTIVES
Le dernier algorithme sera le plus utile dans les applications morphologiques que nous allons dcrire
par la suite car il rduit le temps ncessaire pour le changement de stockage des images. Les rsultats
exprimentaux prsents dans la tab. 6.1 dmontrent bien son utilit par rapport aux implmentations
naves qui travaillent par la dnition et implmentent, en effet, lalgorithme trivial 6.1.
Dans nos explications pour 2D, nous nous sommes spciquement concentrs sur les macro blocs de
taille 8 8. Cela pour la bonne raison que les architectures des ordinateurs qui sinstallent sur le march
grand public sont, en effet, les architectures de 64 bits (Intel IA-64, AMD64, SuperH SHmedia) et nous
pouvons voir directement les aspects applicatifs de nos algorithmes pour ces architectures. Pour dmon-
trer que ce sujet est dun intrt majeur pour les application, nous pouvons citer les articles
Lee00, LFB01
qui traitent dun sujet connexe (ils sont focaliss sur larchitecture Intel IA-64) mais qui ne sont pas
directement orients vers un changement du sens de stockage des image pour un traitement SIMD.
Lapproche macro bloc lment par lment peut galement trouver son emploi lors dun travail avec
des images plus grandes que les mmoires caches de larchitecture cible. Dans ce cas prcis, il serait
avantageux pour un meilleur emploi de la mmoire cache de travailler par macro blocs et de combiner,
sur les architectures multimdia, lapproche de dcoupage en macro blocs plus grands que la taille des
registres avec lapproche SIMD lintrieur des registres.
145
CHAPITRE 7
Algorithmes de voisinage
dpendant du sens prdni de parcours de limage
Les algorithmes travaillant sur le voisinage et dont le traitement dpend du sens de parcours de
limage forment un autre groupe dalgorithmes de la morphologie mathmatique. En effet, nous pouvons
y classer tous les algorithmes qui utilisent la propagation dune valeur dans un sens dni. De ce point
de vue, les algorithmes les plus naturels de ce travail sont ceux qui calculent la fonction distance
1
.
Dans les applications destines au traitement en temps rel, nous nous intressons aux fonctions
distance qui peuvent nous rendre une approximation de la distance le plus rapidement possible. De ce
point de vue, nos cibles prioritaires seront les algorithmes des fonctions distances non-euclidiennes. Ces
algorithmes, comme on le verra par la suite, utilisent des techniques particulires pour le traitement et
elles sont transposables galement au traitement SIMD des images sur les architectures multimdia.
Lapproche que lon va dcrire ne se restreindra pas seulement aux fonctions distances. Dautres types
dalgorithmes peuvent tre implments suivant la mme approche. Les oprations morphologiques qui
peuvent en bncier sont reprsentes par la reconstruction morphologique (cf. livre
Soi03
de rfrence)
et par tous les algorithmes drives de cette dernire. Nous nous consacrerons dans ce chapitre plus
particulirement aux nivellements qui sont des ltres morphologiques dune importance cruciale pour
les applications de ltrage et de segmentation dimages.
7.1 Particularit du sens du parcours pour le traitement SIMD du voisinage
Dans les traitements qui nutilisent pas lapproche vectorielle et, par consquent, nexploitent pas le
paralllisme des donnes lchelle dun registre, les sens du parcours plus que classiques sont ceux qui
parcourent limage en sens vido et anti-vido, bien connus des algorithmes dvaluation de la fonction
distance chamfer. La gure 7.1 illustre cette situation.
Le calcul standard des fonctions distance approximatives est assur par les mthodes qui dcom-
posent le kernel en deux parties et le calcul en deux parcours (vido et anti-vido) et sont appeles les
distances chamfer. Formellement, nous pouvons dcrire les parcours complets par la composition de
deux fonctions p
1
et p
2
:
parcours ut = p
1
p
2
$ ut
Ces types de parcours nous offrent la propagation des valeurs, lchelle des pixels, en deux axes en
mme temps. Donc, lavantage de cette approche pour le calcul de la fonction distance est, sans aucun
doute, dans lutilisation de seulement deux parcours de limage entire.
1
Nous renvoyons le lecteur la thse
Cui99
dOlivier Cuisenaire pour plus de dtails thoriques sur les fonctions distance.
147
f
s
t
snd
f
s
t
snd
Parcours p
V
Parcours p
AV
FIG. 7.1 : Dcomposition du kernel en deux parties et en deux parcours de limage lors de lvaluation des
fonctions distance chamfer. Lexemple dlment structurant pour le 4-voisinage et la grille carre.
De plus, certaines architectures matrielles ddies la morphologie mathmatique implmentent
ces algorithmes en utilisant le stockage local de plusieurs lignes vido, on parle des lignes retard. Les
lments du voisinage local dune partie du kernel dcompos est extrait partir de ces lignes par des
mcanismes standards de lextraction du voisinage.
Ayant disposition des architectures avec les capacits SIMD, nous nous demandons comment pro-
ter du paralllisme de donnes pour ces traitements. Et nous nous apercevons que le fait dutiliser les
parcours vido et anti-vido, qui taient prsents comme avantageux pour le traitement lchelle des
pixels, devient gnant pour les traitements lchelles des vecteurs paquets. Il est, en effet, extrmement
coteux deffectuer la propagation dune valeur lment par lment lintrieur dun vecteur paquet,
surtout cause du non-support dun tel traitement par les jeux dinstructions multimdia
1
.
Pourtant, le traitement lchelle des vecteurs paquets peut utiliser la force du calcul SIMD. Cest
pourquoi nous nallons pas utiliser le parcours vido ou anti-vido directement mais nous les diviserons
en quatre phases en total. Dans chacune des phases, nous allons utiliser une direction de propagation
diffrente et nous allons travailler lchelle des vecteurs paquets. La gure 7.2 illustre cette situation.
Nous pouvons y percevoir la diffrence entre le traitement lchelle des lments de base, q.v.
g. 7.2(a), et le traitement lchelle des vecteurs paquets, q.v. g. 7.2(b). La dernire gure montre
galement de quelle manire on regroupe les lments de limage dans les vecteurs paquets. Notons
que laxe de vectorisation est, dans les quatre phases, perpendiculaire au sens du parcours. Le kernel du
calcul est galement dcompos en quatre parties, chacune delles utiliser dans une phase diffrente.
La formule suivante
parcours ut = p
D
p
C
p
B
p
A
$ ut
dcrit formellement ce procd. Notons que lordre dapplication de ces phases, comme prsent par la
formule prcdente, nest quune possibilit parmi dautres. Il existe, en effet, quatre manires dordon-
ner les phases et nous pouvons les utiliser dans les algorithmes ayant la mme structure de fonctionne-
ment que la fonction distance :
parcours ut = (p
D
p
C
) (p
B
p
A
) $ ut
= (p
D
p
C
) (p
A
p
B
) $ ut
= (p
C
p
D
) (p
B
p
A
) $ ut
= (p
D
p
C
) (p
A
p
B
) $ ut
La problmatique de la vectorisation a dj t discute dans la section ddie au paquetage et dpa-
quetage des donnes (cf. 4.4.3, page 68). En pratique, laxe de vectorisation est choisi comme identique
celui de stockage des donnes dans la mmoire. Ce qui veut dire que deux (p
A
et p
D
) des quatre phases
de la propagation SIMD sont applicables directement comme prsent ci-dessus. Pour pouvoir appliquer
lapproche SIMD dans les deux phases restantes (p
B
et p
C
), nous devons faire appel aux techniques de
1
Nous nous basons sur les jeux dinstructions que nous avons pu consulter Intel IA-32 (MMX, SSE, SSE2, SSE3) et
SuperH SHmedia
148
Jaromr BRAMBOR 7.1. PARTICULARIT DU SENS DU PARCOURS POUR LE TRAITEMENT SIMD DU VOISINAGE
f
s
t
snd
f
s
t
snd
f
s
t
snd
f
s
t
snd
Parcours p
A
Parcours p
B
Parcours p
C
Parcours p
D
(a) Travail avec les lments de base
f
s
t
snd
f
s
t
snd
f
s
t
snd
f
s
t
snd
Parcours p
A
Parcours p
B
Parcours p
C
Parcours p
D
Vecteur
paquet
Vecteur
paquet
Vecteur
paquet
Vecteur
paquet
(b) Travail SIMD avec les vecteurs paquets
FIG. 7.2 : Dcomposition du kernel en quatre parties et en quatre parcours de limage. Lexemple dlment
structurant pour le 4-voisinage et la grille carre.
changement de laxe de stockage des donnes. Il sagit des techniques prsentes dans le chapitre 6,
page 127, et nous allons utiliser la transposition par diagonale en particulier.
Ceci dit, les deux phases de propagation (p
B
et p
C
) dont lorientation est parallle laxe de stockage
des donnes dans la mmoire (laxe snd dans ce cas) vont faire appel la transposition de limage dans
la mmoire. Aprs cette transposition, les donnes avec lesquelles nous voulons travailler seront prtes
pour le traitement par les instructions SIMD. En mme temps, le sens du parcours que nous devons utili-
ser lors de travail avec ces donnes transposes ne sera pas celui appliqu aux donnes originaires, il doit
galement tre transpos. Aprs lapplication dun kernel, nous devons faire appel une deuxime trans-
position pour obtenir les donnes orientes dans le bon sens. La g. 7.3 illustre cette ide sur lexemple
de la phase p
B
pour laquelle les donnes, aprs tre transposes, utilisent le mme sens de parcours que
celui de la phase p
A
. Formellement, nous pouvons dcrire ce procd par la formule suivante :
p
B
$ ut = t
D
p
A
t
D
$ ut
Suivant la mme ide, nous pouvons driver galement la formule pour le calcul de la phase p
C
qui
utilisera pour les donnes transposes, le mme sens de parcours que la phase p
D
p
C
$ ut = t
D
p
D
t
D
$ ut
Si nous assemblons toutes ces ides, nous pourrons construire un schma global de fonctionnement
qui sera utilis lors du travail avec les donnes paquetes. Formellement, nous pouvons crire :
parcours ut = p
D
p
C
p
B
p
A
$ ut
= p
D
(t
D
p
D
t
D
) (t
D
p
A
t
D
) p
A
$ ut
= p
D
t
D
p
D
(t
D
t
D
) p
A
t
D
p
A
$ ut
= p
D
t
D
p
D
p
A
t
D
p
A
$ ut
149
f
s
t
snd
Parcours p
B
Vecteur
paquet
f
s
t
snd
Application de la transposition
par diagonale
Vecteur
paquet
+
=
f
s
t
snd
Parcours p
A
Vecteur
paquet
f
s
t
snd
+
Vecteur
paquet
Application de la transposition
par diagonale
FIG. 7.3 : Remplacement de la propagation SIMD en direction parallle au sens du stockage par les trans-
positions par diagonale de larray et par lapplication de la propagation en sens perpendiculaire laxe de
vectorisation. Lexemple dlment structurant pour la grille carre et le 4-voisinage.
o la dernire ligne prsente le schma aprs llimination de la double transposition qui est redondante.
Dans le cas o les donnes sont paquetes dune faon diffrente de celle prsente sur la g. 7.3, les
formules analogiques peuvent tre construites en retant ce sens de paquetage particulier.
7.2 Skeletons applico-rductifs pour la propagation
Pour pouvoir exprimer formellement la manire dont on travaillera lors des propagations, nous d-
nissons deux skeletons : mfoldl et mfoldl1. Nous les avons nommes les skeletons applico-rductifs car
ils combinent deux oprations de base, lapplication et la rduction dans leurs corps. Leurs fonctionne-
ments sont trs proches de deux skeletons du Haskell : scanl et scanl1, mais ils diffrent par certains
dtails et leurs dnitions ne sont pas exactement les mmes.
Le skeleton mfoldl :
mfoldl :: ( ) [ ] [ ]
mfoldl _ _ [ ] = [ ]
mfoldl | v (a:a) = t : ( mfoldl | t a) where t = | v a
prend trois arguments. Le premier est la fonction | de deux arguments qui assure la fonctionnalit
dapplication. La fonction | est applique sur largument v de ce skeleton et sur le premier lment
a de la liste (a : a). Son rsultat est inscrit dans le stream rsultant mais galement rutilis comme
argument dans lapplication suivante de la fonction | sur le deuxime lment du stream dentre. Cette
propagation se poursuit jusqu ce que le stream dentre soit vide. La gure 7.4 illustre graphiquement
ce fonctionnement. Notons que ce skeleton retourne un stream qui est le rsultat de lapplication de la
fonction | . Le rsultat de la rduction nest pas retourn explicitement mais incorpor dans le stream
rsultant. Cest, en effet, le dernier lment de ce stream qui porte la valeur rsultante de la rduction.
v
e
0
e
1
e
N-1
r
0
r
1
r
N-1
f r
0
f r
1
f
f r
N-1
FIG. 7.4 : Fonctionnement du skeleton applico-rductif mfoldl.
Dans certains cas, il sera plus pratique dutiliser le skeleton algorithmique mfoldl1 qui assure la
fonctionnalit applico-rductive sur le stream. Par rapport au skeleton mfoldl dcrit prcdemment, nous
ne passons que la fonction | et le stream dentre (a : a) comme arguments :
150
Jaromr BRAMBOR 7.3. SKELETON ALGORITHMIQUE DE LA PROPAGATION SIMD EN 4-VOISINAGE
mfoldl1 :: ( ) [ ] [ ]
mfoldl1 _ [ ] = [ ]
mfoldl1 | (a:a) = a : ( mfoldl | a a)
Ce skeleton napplique pas la fonction | sur le premier lment a du stream et le retourne aussitt dans
le stream rsultant. En revanche, sa valeur est utilise comme argument dentre pour la rduction qui
est assure, pour tous les lments suivants a du stream, par lapplication de la fonction mfoldl. La
gure 7.5 illustre cette situation.
e
0
e
1
e
2
e
N-1
r
0
r
1
r
2
r
N-1
f r
1
f r
2
f
f r
N-1
FIG. 7.5 : Fonctionnement du skeleton applico-rductif mfoldl1.
7.3 Skeleton algorithmique de la propagation SIMD en 4-voisinage
Aprs avoir expliqu la particularit du sens du parcours pour les propagations dans le cas o on
travaille avec les vecteurs paquets et aprs avoir expliqu le principe de fonctionnement des algorithmes
qui sappuient sur les techniques de changement de laxe de stockage de donnes, nous sommes prts
construire le premier skeleton algorithmique qui utilisera ce type de propagation.
Il est vident quen utilisant les parcours de limage pour la propagation, comme illustrs sur la
g. 7.3, nous utiliserons le dcoupage de larray en macro blocs. Un macro bloc sera constitu par les
donnes qui sont parcourues lors de la propagation. Ainsi, la propagation seffectuera lchelle des
macro blocs et les valuations lintrieur de chacun des macro blocs seront indpendantes les unes des
autres.
7.3.1 Propagation lintrieur dun macro bloc
Expliquons alors le fonctionnement dune telle propagation lintrieur dun macro bloc. Par la suite,
nous allons btir notre algorithme entier partir de ce fonctionnement de base.
Le skeleton pGenMB dnit la propagation dans un macro bloc, dont les lments sont les vecteurs
paquets, laide de la fonction | qui dnit lopration exacte effectuer. Il est naturel que dans le cur
de ce skeleton, nous nous appuyons sur un des skeletons applico-rductifs ; mfoldl1 dans ce cas prcis.
La dnition que nous prsentons ici ne fait, en effet, que concrtiser lutilisation de ce dernier pour une
situation qui nous intresse la propagation lintrieur dun macro bloc :
Tout dabord nous construisons le stream des index (ligne 10) en utilisant la fonction streamAr2D
avec les paramtres Iov, qui dnit le sens du parcours, et mI, qui est un array des vecteurs paquets
et qui reprsente le macro bloc. Notre algorithme commence par lutilisation de ce stream dindex ix
(ligne 8). Sur chaque index de ce stream, nous appliquons (ligne 7) la fonction extraction des lments
partir du macro bloc (mI!). Notons que dans ce cas, nous ne traitons pas les bords de limage et, par
consquent, nous navons pas besoin dassurer lextraction des lments par une fonction particulire
qui grerait les effets de bord. Ainsi, nous obtenons le stream des vecteurs paquets sur lequel nous
appliquons (ligne 6) directement le skeleton applico-rductif mfoldl1 avec la fonction | comme argument
qui assure la propagation. Les expressions restantes (lignes 5 et ligne 4) qui utilisent les fonctions zip
et array constituent la manire standard de crer un macro bloc de sortie partir des rsultats de la
propagation.
151
Algorithme 7.1 : pGenMB, skeleton algorithmique de la propagation SIMD lintrieur dun
macro bloc compos des vecteurs paquets pour le 4-voisinage et la grille carre
1 pGenMB :: (Ord) [ Char] ( PVec I PVec I ( PVec I , PVec I ))
3 pGenMB Iov | mI =
4 (array (bounds $mI))
5 ( zip ix )
6 ( mfoldl1 | )
7 (map ( mI! ) )
8 $ix
9 where
10 ix = streamAr2D Iov mI
7.3.2 Phase gnralise de la propagation
Montrons maintenant la structure dune phase de propagation entire qui utilisera le skeleton pGenMB
pour les macro blocs que lon vient de dnir. Cest la fonction pGen, dnie par lalgorithme 7.2, qui
prsente la description formelle dune telle phase de propagation sur limage entire. Son fonctionne-
ment est assez simple, elle ne fait que vectoriser (ligne 10) larray dentre ut, applique ensuite (ligne 9)
le dcoupage de cet array aux m n macro blocs et cre partir dun array des macro blocs le stream
des macro blocs (ligne 8). Sur la ligne 7, on applique chaque macro bloc de ce stream la fonction
de la propagation lintrieur dun macro bloc pGenMB. Les expressions sur les lignes restantes ne
font que reconstruire, partir dun stream des macro blocs rsultant, larray des lments de base par
lapproche inverse. Nous transformons (ligne 6) le stream des macro blocs en un array des macro blocs.
partir de ce dernier, nous construisons (ligne 5) un array des vecteurs paquets et nous procdons
la dvectorisation (ligne 4) pour obtenir larray rsultat dont les lments sont les lments de base du
type
Algorithme 7.2 : pGen, skeleton algorithmique gnral dune phase de propagation SIMD pour le
4-voisinage et la grille carre
pGen :: (Ord) [ Char] [ Char] I ( PVec I PVec I ( PVec I , PVec I ))
Ar ( I , I ) Ar ( I , I )
pGen |votIv uxa pvatz | ut =
(mkAr2DFromAr2DPVec uxa)
arrayFromMxNBlocs
( listArray ( (1,1) , (m,n)) )
(map (pGenMB Iov | ) )
elems
(arrayToMxNBlocs mn)
(mkAr2DPVec uxa pvatz)
$ut
where
Iov = if (uxa == "Fst" ) then (|votIv ++ "Snd") else (|votIv ++ "Fst" )
(p,q) = dimsAr2D ut
(m,n) = if (uxa == "Fst" ) then ( div p pvatz, 1) else (1, div q pvatz)
Ce skeleton algorithmique est gnral et commun pour les deux sens de parcours que nous allons
employer (Fwd et Bwd) et qui sont prciss par largument |votIv. Le deuxime argument de ce
skeleton, uxa, nous dnit laxe de stockage des donnes dans la mmoire (Fst ou Snd) et pvatz
dnit la taille du vecteur paquet que nous voulons utiliser et qui correspond au nombre dlments qui
152
peuvent tre traits par les instructions SIMD de notre architecture multimdia en mme temps. | est la
fonction qui dnit lopration de propagation (notons quelle est dnie pour les vecteurs paquets) et
ut est larray dentre.
7.3.3 Propagations SIMD sur limage entire pour le 4-voisinage et la grille carre
Ainsi, nous avons prsent les outils de base pour pouvoir nalement dnir le skeleton propAlgSQR4
de la propagation SIMD pour le 4-voisinage et la grille carre. Cest lalgorithme 7.3 qui dnit ce ske-
leton.
Algorithme 7.3 : propAlgSQR4, skeleton algorithmique de la propagation SIMD pour la grille
carre et le 4-voisinage
propAlgSQR4 :: (Ord) [ Char] I ( PVec I PVec I ( PVec I , PVec I))
Ar ( I , I ) Ar ( I , I )
propAlgSQR4 uxa pvatz | ut = p
2
t
D
p
2
p
1
t
D
p
1
$ ut
where
p
1
= pGen "FW" uxa pvatz |
p
2
= pGen "BW" uxa pvatz |
t
D
= trRot2DMBSIMD "TD" uxa pvatz
Nous voyons que sa dnition est beaucoup plus claire que celles des skeletons prcdents. En effet,
nous avons cach tout le travail lourd dans la fonction de parcours pGen et nous obtenons une structure
dnissant le strict ncessaire pour la description de ce type de propagation.
Nous y reconnaissons, sur la ligne 3, lenchanement des oprations :
p
2
t
D
p
2
p
1
t
D
p
1
$ ut
que nous avons dj mentionn dans la section 7.1, page 7.3 et qui nutilise que 2 sens de parcours princi-
paux, appliquant ainsi lapproche de la transposition pour contourner les propagations parallles laxe
de stockage des donnes dans la mmoire, comme illustres sur la g. 7.3, page 7.3. Mais nous utilisons
lapproche plus gnrale qui travaille avec les phases de propagation p
1
et p
2
, qui ne sont concrtises
qu lintrieur de la phase de propagation pGen selon la valeur de laxe de stockage transmise par le
paramtre uxa. Le paramtre pvatz dnit le nombre dlments qui peuvent tre traits en parallle
par les instructions SIMD de notre architecture et | dnit lopration effectuer lors de la propagation ;
ut est larray dentre.
Remarquons que pour changer laxe de stockage de donnes, nous utilisons la fonction gnralise de
la transposition /rotation dun macro bloc trRot2DMBSIMD que nous avons dnie dans le chapitre 6
ddi ce sujet. Rappelons que cette fonction est concrtise par le paramtre TD pour effectuer la
transposition par diagonale et quelle utilise lapproche des macro blocs lors de son valuation. La taille
dun macro bloc est dnie par la taille du vecteur paquet pvatz.
7.3.4 Calcul de la fonction distance
Les skeletons que nous venons de prsenter ne dnissent que la structure du traitement. La fonction-
nalit concrte va utiliser ces skeletons pour les spcialiser et leur donner la forme nale de lalgorithme
qui excute lopration souhaite. Dans notre cas, lopration que nous ciblons tout dabord est la fonc-
tion distance chamfer calcule sur le 4-voisinage et la grille carre.
Pour pouvoir la dnir, nous devons prciser certains paramtres dpendant de lapplication concrte.
Il sagit notamment de laxe de stockage des donnes dans la mmoire uxa et de la taille du vecteur
paquet pvatz.
En ce qui concerne les donnes dentre, nous devons avoir deux arrays : le premier avec limage du
masque, qui est une image binaire et o les valeurs True dnissent la zone dans laquelle nous calculons
153
la fonction distance, et les valeurs False dans le cas contraire. Et puis, il nous faut un deuxime array qui
contiendra les rsultats de la distance et dont le type de stockage serait sufsant pour contenir les valeurs
calcules. Ces valeurs doivent tre initialises avant le dbut de lvaluation 0 dans la zone dsigne
par les valeurs False du masque et la valeur la plus grande possible (+ou la valeur maximale du
type de stockage) dans la zone dsigne par les valeurs True du masque. La gure 7.6 illustre cette
situation.
msk
Image du masque
False
True
val
Image des rsultats
0
FIG. 7.6 : Initialisation des images avant lexcution de lalgorithme de la fonction distance.
Pour pouvoir exprimer le fonctionnement dune manire simple, il est utile dassocier dans un seul
lment le masque et la valeur calcule de la fonction distance. Ceci nous permettra de travailler avec un
seul array dont les lments sont des tuples (masque,rsultat). Lalgorithme de la fonction distance aura
ensuite la forme :
fncDistanceSQR4 :: [ Char] I Ar ( I , I ) (Bool, ) Ar ( I , I ) (Bool, )
fncDistanceSQR4 uxa pvatz ut = propAlgSQR4 uxa pvatz
( (vmI,vvuI) (amI,avuI) (amI, cndmoveSIMD (testSIMD amI (==) True)
(minSIMD (vvuI+1) avuI)
(avuI)
)
ut
o lexpression dnit lopration de propagation. Dans ce cas prcis, il sagit de la fonction dis-
tance directionnelle avec une distance entre les pixels gale 1. (vmI, vvuI) dnit llment voisin et
(amI, avuI) dnit llment central pour lequel nous effectuons lvaluation, les deux exprims par un
tuple (masque, valeur).
7.3.5 Calcul des nivellements
7.3.5.1 Nivellements
Outre la fonction distance, le style de travail que nous avons dcrit par les skeletons algorithmiques
de la propagation peut tre utilis galement pour dnir les algorithmes valuant des nivellements
Mey03
,
cela non seulement pour les nivellements plats, cf. g. 7.7(a), mais galement pour les lambda-nivellements,
cf. g. 7.7(b). Ainsi prsents, nous pouvons percevoir les nivellements plats en tant que cas spcial des
lambda-nivellements pour la valeur = 0.
Notons galement que la technique de propagation des valeurs lors du travail avec les nivellements est
trs semblable celle que nous utilisons lors du travail avec la fonction distance, mme si les nivellement
constituent une opration plus complexe que la fonction distance.
En revanche, ils diffrent de la fonction distance par leur caractre godsique et par la propagation
des valeurs jusqu lidempotence. Par la suite, nous nallons prsenter que les dnitions des algo-
rithmes pour une seule itration, lapplication rptitive de ces algorithmes peut tre facilement drive
suivant les mme rgles que celles prsentes pour les oprations godsiques non-dpendantes du sens
de parcours, cf. la section 5.3, page 115.
154
f - fonction
de rfrence
m - marqueur
0
m
- nivellements (plats)
(a) Nivellements plats
f - fonction
de rfrence
m - marqueur
m
- nivellements (lambda)
(b) -nivellements
FIG. 7.7 : Nivellements
7.3.5.2 Nivellements en tant que combinaison des nivellements partiels
Limplmentation des nivellements que nous allons prsenter va utiliser les skeletons que nous
avons dcrits prcdemment et va sappuyer sur deux nivellements partiels que nous appelons les sur-
nivellements et les sous-nivellements et qui sont illustrs sur la g. 7.8. Ces deux oprations ont, en effet,
la structure de fonctionnement de la propagation identique, ce qui les diffrencie est lopration du kernel
dexcution.
Ces fonctions ont des proprits trs intressantes. tant donn la fonction de rfrence f et le mar-
queur m, les lambda-sous-nivellements
m
(f) de la fonction f contraintes par le marqueur m sont
identiques aux nivellements
m
(f) dans le domaine de limage o m > f, dans le reste du domaine
ils sont identiques la fonction f. Par dualit, les lambda-sur-nivellements
+
m
(f) de la fonction f
contraintes par le marqueur m sont identiques aux nivellements
m
(f) dans le domaine de limage o
m < f, dans le reste du domaine ils sont identiques la fonction f.
An dobtenir les lambda-nivelements
m
(f) partir de ces sur- et sous-nivellements, nous allons
combiner ces deux derniers selon la formule suivante :
m
(f) =
m
(f) m > f
f m = f
+
m
(f) m < f
(7.1)
Lquation 7.1 est la dnition mathmatique thorique. Dans la pratique nous allons proter des pro-
prits des nivellements pour diminuer le nombre doprations arithmtiques effectuer. Tout dabord,
nous allons proter de lidentit des nivellements avec la fonction de rfrence f pour m = f an dli-
miner une condition vrier. Les sur- et sous-nivellements sont borns sur les sous-domaines et les
expressions suivantes sont valides :
m
m
(f) f, m fm
m
(f) f, m f (7.2)
et nous allons les utiliser pour liminer la fonction f de la formule pour la combinaison des nivellements
ce qui va se traduire par le travail avec une image en moins. Ainsi, nous pouvons dcrire le mme travail
par la formule suivante :
m
(f) =
m
(f) m
m
(f)
+
m
(f) m <
m
(f)
(7.3)
Cest lquation 7.3 que nous allons utiliser en pratique pour effectuer la combinaison des deux nivelle-
ments partiels.
155
f - fonction
de rfrence
m - marqueur
m
- nivellements (lambda)
f - fonction
de rfrence
m - marqueur
-
m
sous-nivellements
(lambda)
True
False
m > f
f - fonction
de rfrence
m - marqueur
+
m
sur-nivellements
(lambda)
FIG. 7.8 : Calcul des nivellements en tant que combinaison des sur-nivellements et les sous-nivellements
7.3.5.3 Algorithmes pour une itration des nivellements partiels
Le skeleton de la propagation SIMD que nous avons dni dans la section 7.3.3 va nous servir de
charpente pour la construction des algorithmes qui vont implmenter les sur-nivellements et les sous-
nivellements. Tout dabord, clarions les images que nous attendons lentre de nos algorithmes et
quelle sera leur fonction lors de la propagation.
La fonction de rfrence | (cf. g. 7.8) va passer dans les fonctions de propagation en tant que
masque et les valeurs du marqueur m des nivellements (cf. g. 7.8) seront utilises en tant que valeurs
initiales partir desquelles nous commencerons la propagation et qui vont devenir, aprs avoir appliqu
les quatre phases de propagation SIMD, les valeurs rsultantes dune itration des nivellements partiels.
La gure 7.9 illustre cette situation.
Larray dentre ut des fonction dnissant les nivellements partiels va tre compos de la mme
manire que celui utilis par la fonction distance par des tuples (masque, valeur) et le type de cet array
sera, par consquent, Ar (I, I) (, ).
156
(a) Image du masque "*msk" pour la
propagation correspondant la fonction | de
rfrence des nivellements
(b) Image des valeurs propager "*val"
correspondant la fonction m du marquer des
nivellements
FIG. 7.9 : Les images dentre aux fonctions de sur- et sous-nivellements et lexemple de leur contenu.
Une itration de lambda-sous-nivellements est dnie par la fonction lolevelSQR4 :
lolevelSQR4 :: [ Char] I I Ar ( I , I ) (,) Ar ( I , I ) (,)
lolevelSQR4 uxa pvatz ImI ut = propAlgSQR4 uxa pvatz
( (vmI,vvuI) (amI,avuI) maxSIMD amI (minSIMD (vvuI+ImI) avuI) )
ut
o le terme dnit le kernel de la propagation directionnelle et le paramtre ImI dnit la pente des
lambda-sous-nivellements. En spciant sa valeur 0, nous obtenons les sous-nivellements plats. La
signication des autres paramtres de cette fonction est identique celle des paramtres pour la fonction
distance (cf. 7.3.4) : uxa dnit laxe de stockage des donnes dans la mmoire, pvatz est le nombre
des lments que nous pouvons traiter en mme temps par les instructions SIMD de notre architecture
multimdia et ut est larray dentre compos des tuples (masque, valeur).
Par analogie, nous dnissons une itration des lambda-sur-nivellements par la fonction hilevelSQR4 :
hilevelSQR4 :: [ Char] I I Ar ( I , I ) (,) Ar ( I , I ) (,)
hilevelSQR4 uxa pvatz ImI ut = propAlgSQR4 uxa pvatz
( (vmI,vvuI) (amI,avuI) minSIMD amI (maxSIMD (vvuIImI) avuI) )
ut
o le seul changement par rapport la fonction des lambda-sous-nivellements est dans la dnition du
terme dnissant le kernel de la propagation directionnelle.
7.3.5.4 Algorithme pour une itration des nivellements
Comme nous lavons dj expliqu dans la section 7.3.5.2, une itration des nivellements (naux)
sera obtenue par la combinaison des rsultats dune itration des sur- et sous-nivellements (partiels)
selon lquation 7.3.
La fonction levelSQR4 dnit cette composition :
levelSQR4 :: [ Char] I I Ar ( I , I ) (,) Ar ( I , I ) (,)
levelSQR4 uxa pvatz ImI ut =
(mkAr2DFromAr2DPVec uxa)
listArray (bounds $Io)
map2 ( (IomI,IovuI) (IimI,IivuI) cndmoveSIMD (testSIMD IomI ( ) IovuI ) IovuI IivuI )
(elems(mkAr2DPVec uxa pvatz)$Io)
(elems(mkAr2DPVec uxa pvatz)$Ii )
where
Io = (lolevelSQR4 uxa pvatz ImI) $ut
Ii = (hilevelSQR4 uxa pvatz ImI) $ut
157
Nous y valuons dabord les rsultats Io et Ii de nivellements partiels en utilisant la fonction lolevelSQR4
des sous-nivellements et la fonction hilevelSQR4 des sur-nivellements. Lexpression dnit sur place
la fonction de composition SIMD des nivellements en utilisant la fonction testSIMD (cf. sa dnition,
page 202) qui cre un vecteur paquet du masque que lon utilise aussitt dans la fonction de dpla-
cement conditionnel cndmoveSIMD (cf. sa dnition, page 203). Cette construction est une technique
courante pour exprimer lexpression conditionnelle if then else pour les donnes SIMD.
La fonction map2 applique la fonction sur les lments de deux streams. Les fonctions mkAr2DPVec
et mkAr2DFromAr2DPVec sont utilises pour vectoriser et d-vectoriser les arrays, respectivement, et
les fonction elems et listArray sont les fonctions standards du Haskell pour le passage dun array un
stream et vice versa, respectivement.
7.4 Approche utilisant les macro blocs avec la transposition directe
Le skeleton algorithmique de propagation propAlgSQR4 que nous avons utilis jusqu prsent
nemployait la transposition de donnes quaprs avoir accompli les phases entires de la propagation.
Pour pouvoir plus proter de la localit des donnes lors du parcours de limage, nous pouvons envisager
la construction des algorithmes qui travailleraient lchelle des macro blocs dont la taille serait gale
la taille du registre multimdia de notre architecture et o nous effectuerions deux phases de propagation
et une transposition par diagonale en mme temps sans avoir besoin dcrire les donnes dans la mmoire
principale.
Le principe de cette technique est illustr par la g. 7.10 qui prsente la chane de traitement avec
les donnes reprsentes en tant que ux et les oprations qui sont effectues sur ces donnes en tant
que kernels dexcution. Nous nallons pas donner de description formelle cette technique lchelle
de limage toute entire. Nous prsentons seulement le principe de fonctionnement de cette approche
lchelle de macro bloc car nous pensons que sa description formelle peut tre dduite partir du style
de travail que nous avons prsent pour le skeleton propAlgSQR4.
A
1
A
2
A
N-1
A
N
V
H
V
A
1
mfoldl
A
N
B
1
B
N
tr2DDiagNxPVecNbf
C
1
C
N
H
mfoldl
D
1
D
N
B
1
B
2
B
N-1
B
N
H
C
1
C
2
C
N-1
C
N
H
D
1
D
2
D
N-1
D
N
Macro bloc
dentre
Macro bloc
aprs la propagation
Macro bloc aprs
la transposition par diagonale
Macro bloc rsultant
aprs la propagation
B
1
B
2
B
N
-
1
B
N
V
2
V
2
H
2
H
2
FIG. 7.10 : La chane de traitement dun macro bloc o la premire propagation est suivie directement par la
transposition par diagonale et par la deuxime propagation
Tout dabord, nous appliquons la premire phase de propagation (verticale), exprime par la fonction
mfoldl. Cette fonction utilise llment V comme entre pour la propagation. Cet lment correspond
158
au rsultat de la propagation verticale prcdente et nous lutilisons en tant que valeur initiale pour la
propagation (au bord de limage, nous utiliserons le schma de propagation dcrit par la fonction mfoldl1
qui ne travaille pas avec un tel lment).
Aprs avoir termin la propagation, nous gardons la valeur du dernier lment B
^
du stream rsultant
dans une mmoire temporaire V
2
pour pouvoir la rutiliser lors de la prochaine propagation dans la mme
direction.
Sur le stream B
i
, nous appliquons la transposition par diagonale, exprime par le kernel du calcul
tr2DDiagNxPVecNbf (cf. lalgorithme 6.4) qui utilise, rappelons-le, les fonctions shufe pour excuter
la transposition en Nlog
2
N oprations. Le stream rsultat C
i
de cette transposition est mis en rela-
tion avec la valeur rsultante H de la propagation horizontale
1
prcdente pour ensuite appliquer une
deuxime phase de propagation verticale des valeurs laide de la fonction mfoldl (les mmes supposi-
tions se mettent en place pour le travail sur les bords de limage).
Les rsultats de cette propagation C
i
sont les rsultat semi-naux. Nous prenons la valeur du dernier
lment D
^
et nous la sauvegardons comme H
2
pour lvaluation suivante du macro bloc voisin. Les
valeurs de ce stream rsultant sont crites dans la mmoire. Ainsi, nous avons obtenu le rsultat de deux
phases de propagation au niveau du macro bloc.
E
1
E
2
E
3
E
1
E
2
E
3
E
1
E
2
E
3
E
1
E
2
E
3
Macro bloc dentre
lment excutif
Itration 1 Itration 0 Itration 2 Itration 3
Macro bloc rsultant
Valeur intermdiaire
stocke localement
Valeur intermdiaire transmise
par le rseaux dinterconnexions
Interconnexions
FIG. 7.11 : Propagation lchelle des macro blocs lors du calcul avec plusieurs units excutives. Une des
valeurs intermdiaires est stocke localement dans lunit, la deuxime est transmise par le rseau dintercon-
nexion lunit suivante.
Il faut noter que limplmentation physique de cette approche demande les connaissance de larchi-
tecture cible car les valeurs intermdiaires de la propagation doivent tre gres diffremment sur les
architectures un seul l dexcution o nous avons besoin dune mmoire temporaire pour les sau-
vegarder mais quelles peuvent tre passes lunit dexcution suivante (e.g. sur les architectures
plusieurs ls dexcution), comme lillustre la g. 7.11. Si nous navons pas darchitecture capable de
travailler dans une telle conguration, lutilisation de la mmoire temporaire pour stocker les rsultats
intermdiaires de la propagation doit tre envisage.
7.5 Notes sur limplmentation, rsultats exprimentaux
Les implmentations de la fonction distance et des nivellements que nous avons conues ont t ini-
tialement destines au processeur SuperH SH-5 qui bncie de 64 registres de 64 bits. Ces implmenta-
tions ont t incluses dans loutil MorphoMedia que nous avons dvelopp an dobtenir lindpendance
1
Aprs avoir effectu la transposition par diagonale, la propagation est effectue, lchelle du macro bloc, verticalement
mais elle correspond une propagation horizontale dans limage
159
sur une architecture donne. Cest pourquoi nous avons pu les compiler facilement pour larchitecture
Intel IA-32, qui fait le point de rfrence dans cette thse, en nous appuyant sur la technologie Intel
MMX (64 bits) et SSE2 (128 bits), le dernier implmentant les fonctions SIMD pour les maxima et les
minima utiliss dans la morphologie mathmatique.
Tout dabord, nous prsentons les rsultats de limplmentation de la fonction distance sur la grille
carre et ayant 4-voisins par pixel, q.v. tab. 7.1. Il sagit dun algorithme de base qui est bien connu. Nous
voulions obtenir les temps dexcution chiffrs pour cette fonction distance pour pouvoir les comparer
par la suite avec les temps obtenus pour les nivellements. En consultant la table 7.1 nous constatons
que pour une image de 99 ko, nous obtenons sur un processeur Intel Pentium 4 2.4 GHz un temps
dexcution de 0.34 ms. Ce temps est le plus favorable possible car lalgorithme prsent travaille avec
limage de sortie ayant les lments de 8 bits ; ce qui peut, pour certains types dimages, poser des
problmes dinsufsance du type de stockage, mais nous le prsentons ici pour une autre raison les
algorithmes des nivellements prsents par la suite travaillent avec les images dentre et de sortie de
8 bits et cette implmentation de la fonction distance peut nous servir en tant que rfrence pour la
comparaison.
Fonction distance, grille carre, 4-voisins
mthode temps taux
dimplmentation en ms dacclration
gnrique 2.42 1.0
par macro blocs utilisant la transposition par diagonale directe 0.34 7.1
Image 352 288 8 bits = 99 ko, limage dentre et limage de sortie sont de 8 bits. Lalgorithme gnrique
utilise les fonctions getpixel()/setpixel() et la propagation en sens vido/anti-vido ; lalgorithme par macro blocs
est optimis pour les types multimdia de 64 bits et utilise la transposition directe lchelle des macro blocs.
Excut 1000 fois en trois ralisations, le temps prsent est le moyen de la meilleure ralisation. Processor Intel
Pentium 4 2.4 GHz, mmoire cache L2 = 512 ko ; systme dexploitation Linux Mandrake 9.2 ; compilateur Intel
ICC 8.1 pour Linux.
TAB. 7.1 : Rsultats exprimentaux pour diverses implmentations de la fonction distance sur la grille carre
et 4-voisins par pixel
Les rsultats des diverses implmentations des nivellements plats et des lambda-nivellements avec la
valeur = 1 sont prsents dans la table 7.2. Les conditions des tests (dimensions dimage, processeur
etc.) pour les nivellements sont identiques celles pour la fonction distance. En consultant les temps de
limplmentation la plus rapide par macro blocs pour 1 itration 1.2 ms pour les nivellements plats
et 1.3 ms pour les lambda-nivellements et en les comparant avec la valeur obtenue pour la fonction
distance (0.34 ms), nous pouvons constater que lexcution de lalgorithme des nivellements est peu
prs 3.5 4 fois plus longue que celle de la fonction distance correspondante.
En ce qui concerne les diffrences entre les diverses implmentations des nivellements, nous avons
choisi comme rfrence limplmentation pointeur++ (son taux dacclration est gal 1.0 est prsent
en gras). Le masque, qui est une des images dentre de lalgorithme des nivellements, nest pas modi
par ce dernier. Ainsi, sa transposition peut tre effectue en avance et seulement une fois pour toutes
les itrations. Les temps que nous prsentons pour limplmentation par macro blocs, retent ce fait et
nous mentionnons entre parenthses les temps incluant cette transposition pralable. La g. 7.12(a) pr-
sente une comparaison graphique des temps dexcution pour diffrentes implmentations de la fonction
distance et des nivellements plats.
Sachant que le paralllisme SIMD que nous utilisons est de 8 lments de 8 bits (implmentation uti-
lisant les types multimdia de 64 bits) et en prenant en compte que nous effectuons deux transpositions
par diagonale dans notre implmentation par macro blocs qui ne sont pas prsentes dans limplmenta-
tion pointer++, le taux dacclration des nivellements est de 4.8 pour 1 itration et il augmente avec
160
SQR DISC2D_4
0,1 1 10 100
fonction distance
nivellements plats, 1
itration
nivellements plats, 5
itrations
nivellements plats,
10 itrations
temps / ms
par macro blocs,
transposition par
diagonale directe
pointer++
gnrique
(a) Comparaison des temps dexcutions de la fonction
distance et des nivellements plats
SQR DISC2D_4
1
2
3
4
5
6
7
8
0 1 2 3 4 5 6 7 8 9 10 11
nombre d'itrations
t
a
u
x

d
'
a
c
c
r
a
t
i
o
n

nivellements plats
lambda nivellements
(b) Taux dacclration pour les nivellements
FIG. 7.12 : Rsultats exprimentaux des algorithmes dpendant du sens prdni du parcours de limage
Nivellements, grille carre, 4-voisins
type
1 itration 5 itrations 10 itrations
implmentation temps taux temps taux temps taux
ms dacclration ms dacclration ms dacclration
gnrique 10.8 46.9 91.3
plats pointeur++ 5.7 1.0 27.4 1.0 58.4 1.0
( = 0) par MB 1.2 (1.8) 4.8 (3.2) 4.6 (5.2) 6.0 (5.3) 8.9 (9.5) 6.6 (6.1)
gnrique 11.8 51.9 102.3
lambda pointeur++ 6.3 1.0 29.3 1.0 55.2 1.0
( = 1) par MB 1.3 (1.9) 4.8 (3.3) 4.8 (5.4) 6.1 (5.4) 9.2 (9.9) 6.0 (5.6)
Lgende : MB = macro blocs, TD = transposition par diagonale ; Image 3522888 bits = 99 ko, limage dentre et limage de sortie sont de
8 bits. Lalgorithme gnrique utilise les fonctions getpixel()/setpixel() et la propagation en sens vido/anti-vido ; lalgorithme pointeur++ est
une analogie de lalgorithme gnrique mais il utilise explicitement les pointeurs ; lalgorithme par MB est optimis pour les types multimdia
de 64 bits et utilise la transposition directe lchelle des macro blocs ; entre parenthses nous prsentons les temps et les taux dacclration qui
incluent la transposition pralable de limage du masque. Excut 1000 fois en trois ralisations, le temps prsent est le moyen de la meilleure
ralisation. Processeur Intel Pentium 4 2.4 GHz, mmoire cache L2 = 512 ko ; systme dexploitation Linux Mandrake 9.2 ; compilateur Intel
ICC 8.1 pour Linux.
TAB. 7.2 : Rsultats exprimentaux pour diverses implmentations des nivellements sur la grille carre et
4-voisins par pixel
davantage ditrations nous obtenons le taux dacclration de 6.6 pour 10 itrations. La g. 7.12(b)
prsente graphiquement les taux dacclrations des nivellements plats et lambda pour limplmenta-
tion par macro blocs qui utilise la transposition directe ; lalgorithme pointeur++ fait la rfrence (taux
dacclration gal 1).
Remarquons lcart important entre limplmentation gnrique (qui parcourt limage en sens vido
et anti-vido, utilise les fonctions daccs aux pixels (setpixel(), getpixel()) et peut travailler avec nim-
porte quelle grille) et limplmentation pointeur++ (qui parcourt galement limage en sens vido et
anti-vido mais qui est spcialise pour la grille carre de 4-voisins).
Nous prsentons une des applications possibles des nivellements pour le ltrage du ux vido lors
dune vido confrence, q.v. la g. 7.13(a) prsentant loriginal et la g. 7.13(b) prsentant les rsultats.
161
Nous travaillons avec la luminance (cf. la g. 7.13(e)) et pour obtenir le marqueur pour les nivellements,
le ltre altern squentiel y est appliqu, cf. la g. 7.13(f). Lalgorithme des nivellements est ensuite
appliqu sur limage entire, q.v. 7.13(g). la n, nous appliquons une simple mthode du masquage
conditionnel (cf. limage du masque sur la g. 7.13(h)) qui, dans limage rsultant de ce ltrage, laisse
lintrieur de la zone dintrt intact et remplace la zone extrieure par les pixels ltrs.
(a) Original (b) Rsultat
(c) Dtail de loriginal (d) Dtail du rsultat
(e) Luminance de loriginal (f) Marqueur - rsultat du
ltre altern de taille 7
(g) Nivellements (h) Masque
FIG. 7.13 : Application des nivellements au ltrage des images conditionn par un masque, dimensions de
limages 382 288, nivellements effectus sur la luminance.
7.6 Rcapitulation
Les mthodes que nous avons prsentes dans ce chapitre sont les mthodes qui exploitent impli-
citement le paralllisme des donnes lors de la propagation rgulire des valeurs dans limage. Le but
principal qui nous a conduit prsenter ces mthodes tait de dmontrer que si nous voulons transfor-
mer les mthodes utilisant une telle propagation et travaillant avec les lments de base des mthodes
utilisant les donnes paquetes, la dmarche nest pas triviale.
Les problmes que nous rencontrons lors de lutilisation des types paquets pour les traitements
sont ds lincapacit dextraire de la mmoire les donnes paquetes dans le sens perpendiculaire
celui dadressage. Cest pourquoi nous avons dmontr sur lexemple de la propagation sur la grille
carre et le voisinage dni par le point central et 4 voisins la manire dont nous pouvons effectuer
la propagation dans les 4 directions en faisant appel une mthode de changement de stockage et
162
seulement deux types de propagation diffrents. Ainsi, nous avons pu rutiliser les ides exposes dans le
chapitre 6, qui tait consacr aux permutations SIMD des donnes, et dont nous avons repris lalgorithme
tr2DDiagNxPVecNbf de la transposition rapide dun macro bloc laide des instructions multimdia.
Pour pouvoir modliser les propagations formellement, nous avons introduit les skeletons algorith-
miques de base pour la propagation des valeurs, mfoldl et mfoldl1. Ils nous ont servi lors de la construc-
tion du modle formel de la propagation lintrieur dun macro bloc compos des vecteurs paquets et
dni par la fonction pGenMB, cf. page 152, et partir duquel nous avons pu construire un algorithme
gnral de la propagation SIMD en 4-voisinage sur la grille carre propAlgSQR4, cf. page 153.
Lemploi plus labor de la propagation lchelle des macro blocs qui utilise la transposition des
donnes directement aprs avoir propag les valeurs dans un macro bloc permet denchaner tout de suite
la deuxime propagation en conomisant ainsi le nombre des transferts de donnes entre lunit centrale
et la mmoire. Nous avons galement prsent comment cette approche pourrait tre adopte pour les
architectures parallles o lexcution se poursuivrait sur plusieurs units excutives en mme temps.
Nous avons prsent deux groupes dalgorithmes dont le fonctionnement est dpendant du sens du
parcours et qui utilisent la propagation rgulire des valeurs dans limage. Il sagit de la fonction distance
et des nivellements. Dans la section qui exposait les rsultats exprimentaux des implmentations que
nous avons effectues, nous avons pu constater un gain de performance qui nest pas ngligeable mais
prvisible vu le nombre dlments (8) que nous pouvions traiter par les instructions SIMD en mme
temps.
Le sujet que nous avons expos dans ce chapitre et les rsultats que nous avons obtenus peuvent
tre apprcis dans les applications qui utilisent une architecture multimdia, qui sont contraintes par le
temps dexcution, et dont nous visons prioritairement les applications pour le temps rel.
Les ides qui sont connexes ce chapitre et qui restent, pour linstant, inexplores sont principa-
lement celles qui touchent les architectures parallles : il serait envisager dexplorer les stratgies
de construction des algorithmes pour les architectures qui peuvent assurer lexcution concurrente des
tches, notamment les architectures parallles plusieurs ls dexcution. Dautres sujets explorer
sont relatifs la construction des architectures ddies qui implmenteraient la structure des algorithmes
prsents directement dans le matriel (e.g. FPGA). On pourrait alors concevoir les blocs oprationnels
exploitant mieux la localit de donnes, dnir un schma dinterconnexion xes qui implmenterait
le changement de stockage de donnes et envisager lutilisation du paralllisme SIMD plus important
(, 8).
Du point de vue des algorithmes, la faon de travailler prsente pour la fonction distance et pour
les nivellements peut tre employe dans tous les algorithmes morphologiques faisant appel la recons-
truction et tous les algorithmes drivs de cette dernire (e.g. lalgorithme de bouchage des trous,
lalgorithme dextraction des maxima ou des minima de limage etc.).
163
CHAPITRE 8
Algorithmes de la dilatation/rosion
pour les lments structurants de la forme dun segment
Ce chapitre est consacr aux approches des calculs des oprations morphologiques qui combinent
toutes les ides que nous avons prsentes jusqu prsent dans les chapitres prcdents. Dun ct,
lexcution de ces algorithmes ne dpend pas, lchelle des macro blocs, de lordre particulier de leur
traitement ; ainsi, nous pouvons nous appuyer sur les ides dcrite dans le chapitre 5, page 99, consacr
aux algorithmes morphologiques non-dpendants du sens de parcours. Dun autre ct, une partie dex-
cution de ces algorithmes, celle qui concerne le traitement lintrieur dun macro bloc, est dpendante
du sens de parcours. Ce sens de parcours est connu en avance et est dni par llment structurant,
exactement comme ctait le cas pour les algorithmes dcrits dans le chapitre 7, page 147, traitant ce su-
jet. De plus, lexcution de certains algorithmes que nous allons dcrire va sappuyer sur les techniques
de changement de laxe de stockage des donnes an de pouvoir accder aux donnes vectorielles dans
laxe perpendiculaire laxe de stockage de ces donnes dans la mmoire ; par consquent, nous allons
rutiliser galement les ides qui ont t dcrites dans le chapitre 6, page 127, consacr ces techniques
particulires.
Lors du travail avec les images 2D (ou plus), nous comprenons sous le terme des lments structu-
rants linaires les lments structurants constitus des vecteurs de dplacement parallles une droite.
Parmi eux, une place privilgie est dtenue par des segments. Un segment est un lment structurant qui
dsigne un groupe de pixels qui sont connects ; pour une grille et un voisinage donns, il doit exister un
chemin entre un pixel de ce groupe et tous les autres pixels de ce groupe ; cela doit tre valable pour tous
les pixels appartenant au groupe. Ce sont les segments qui seront notre centre dintrt dans ce chapitre et
auxquels sont destins les algorithmes dcrits par la suite. La gure 8.1 illustre, sur quelques exemples,
les lments structurants de la forme dun segment.
(a) Segment symtrique,
grille hexagonale
(b) Segment directionnel,
grille carre
(c) Segment symtrique
horizontal, grille carre
(d) Segment symtrique
vertical, grille carre
FIG. 8.1 : Exemples des lments structurants ayant la forme dun segment
165
Pour les besoins de cette thse o nous expliquons le principe de la construction des algorithmes
pour les dilatations et les rosions par un segment pour les architectures parallles avec les fonctionnalits
SIMD, nous allons nous restreindre aux segments dnis sur la grille carre, qui suivent les directions des
axes de limage et qui sont symtriques, cf. la g. 8.1(c) et la g. 8.1(d). La gestion des cas plus gnraux,
tels que les segments directionnels (cf. la g. 8.1(b)) ou les segments inclins est galement envisageable
mais nous ne nous consacrons pas ces algorithmes car nous pensons quils sont dductibles partir de
la description que nous nous apprtons donner par la suite.
Les lments structurants de la forme dun segment sont au centre de notre intrt pour deux raisons :
La premire est relative aux architectures matrielles qui sont destines lexcution de nos op-
rations morphologiques. En effet, les algorithmes pour le calcul rapide des dilatations / rosions
par un segment sont faciles adapter pour les architectures multimdia avec les capacits SIMD
et en les utilisant, nous pouvons obtenir un gain de performance important sur les architectures
existantes grand public.
La deuxime raison est relative la thorie de la morphologie mathmatique et au fait quen utili-
sant les proprits des oprateurs morphologiques, nous pouvons dcomposer lopration de dila-
tation / drosion employant un lment structurant complexe de grande taille en une squence des
dilatations / rosions employant des lments structurants unidimensionnels comptant un nombre
dlments beaucoup moins lev. Pour lexemple de llment structurant B qui est illustr sur
la g. 8.2(a), nous pouvons procder une dcomposition de lopration de dilatation en une s-
quence de dilatations par les lments structurants B
H
(q.v. la g. 8.2(b)) et B
V
(q.v. la g. 8.2(c)) ;
en ce qui concerne llment structurant original, nous parlons de sa dcomposition. Lopration
dilatation peut ainsi tre dcrite comme :
B
=
B
H

B
V
=
B
V

B
H
(8.1)
Cette technique est un outil de base pour limplmentation de toutes les oprations qui utilisent
abondamment les dilatations, les rosions, les ouvertures et les fermetures, notamment les impl-
mentations des ltres alterns squentiels et toutes les techniques des ouvertures pour les mesures
de la granulomtrie. Son apport exprim par la rduction de nombre des oprations qui doivent
tre effectues et leur impact sur la complexit est vident ; nous pouvons lillustrer galement sur
lexemple de la g. 8.2 qui prsente un lment structurant original de 25 vecteurs de dplacement
(cf. g. 8.2(a)) dcompos en deux lments structurants, chacun de 5 vecteurs de dplacement,
10 en total (cf. g. 8.2(b).
(a) lment structurant
B dcomposer
(b) lment structurant
horizontal B
H
(c) lment structurant
vertical B
V
FIG. 8.2 : Dcomposition dun lment structurant sur la grille carre
8.1 Approche itrative
Nous commencerons notre explication en mentionnant lapproche itrative limplmentation des
oprations de dilatation / rosion car cest cette approche qui fait rfrence aux autres algorithmes. Elle
166
Jaromr BRAMBOR 8.2. APPROCHE EMPLOYANT LES ALGORITHMES RUTILISATION DES VALEURS
suit directement la dnition mathmatique pour la construction des lments structurants de taille n, n >
1 partir des lments structurants de taille unit (1) en appliquant llment structurant sur lui-mme
en n 1 itrations (exprim par le symbole ) et en exploitant ainsi lhomothtie de ces lments
structurants :
B
n
=
n1
B
1
(8.2)
Il sagit de la plus simple approche limplmentation du point de vue du temps qui doit tre consa-
cr au dveloppement dun tel algorithme car il nous suft de rutiliser les algorithmes implmentant
la dilatation/rosion que nous avons mentionns dans le chapitre 5 consacr aux algorithmes morpho-
logiques non-dpendants du sens du parcours. Formellement, notre algorithme en Haskell va reter ce
style de travail. Lalgorithme 8.1 de la dilatation par un segment de la taille n sur la grille carre (dni
par la fonction dilSQRHomothetic) qui se base sur llment structurant unit dcrit par la liste des vec-
teurs de dplacement npI et qui prend en compte la valeur constante ItJvuI pour la gestion des bords
de limage peut tre construit par (n 1) applications successives de lalgorithme lalgorithme dilSQR
(dcrit dans la section 5.1.1.2, page 102). Pour plus dinformations sur lexcution itrative en Haskell
et pour lexplication des raisons de lutilisation des fonctions last, take et iterate dans lalgorithme
dilSQRHomothetic, cf. Annexe A, page 199.
Algorithme 8.1 : dilSQRHomothetic, Algorithme dilSQRHomothetic de la dilatation pour la grille
carre par un segment en utilisant lapproche itrative
1 dilSQRHomothetic :: (Ord) I Ngb Ar ( I , I ) Ar ( I , I )
2 dilSQRHomothetic n ItJvuI npI ut = last (take n) ( iterate (dilSQR ItJvuI npI)) $ut
8.2 Approche employant les algorithmes rutilisation des valeurs
La rutilisation des valeurs intermdiaires calcules lors de lvaluation des oprations morpholo-
giques pour les lments structurants ayant la forme dun segment est le sujet de nombreux articles et
travaux scientiques. Lexistence de ces publications prouve limportance de la place quelles occupent
dans la morphologie mathmatique et de leur utilit apporte aux implmentations sur une architecture
matrielle donne.
Parmi les mthodes prsentes, nous retrouvons lalgorithme
vH92
, prsent en 1992 par Marcel van
Herk, qui assure limplmentation des dilatations et des rosions par un segment de taille quelconque et
dont la complexit ne dpend pas de la taille de ce segment. La mme ide pour le calcul des oprations
morphologiques est voque dans un autre article
GW93
dont les auteurs sont Joseph Gil et Michael Wer-
man et qui, bien que publi plus tard (1993), a t dpos plus tt pour la publication que celui de van
Herk. Ce fait peut faire croire que les deux travaux ont t crs indpendamment et cest pourquoi on
dsigne cet algorithme comme "lalgorithme de van Herk-Gil-Werman
1
". Dans lutilisation courante, on
le dsigne souvent comme lalgorithme de (seulement) van Herk, effaant ainsi tort la mention et les
apports des deux autres auteurs. Pourtant, la description dans larticle original de Gil et Werman est plus
thorique et a vraiment la notion dune ide tandis que larticle original de van Herk dcrit lalgorithme
plus pratiquement et nous le jugeons plus comprhensible.
Le fonctionnement de cet algorithme a t dcrit
Soi03
et discut dans plusieurs travaux traitant des
amliorations
GAA97
et les das dutilisation mais galement dans les articles
GK02
qui ont rutilis son ide
pour les ouvertures et les fermetures ou les articles
NHS97, NH00, SBJ96
qui tudient son ide pour le travail
avec des segments inclins ayant une orientation arbitraire en exploitant lalgorithme
Bre65
de Bresenham
de la cration des lignes dans le domaine digital.
1
Cette appellation est trouver dans larticle
GK02
de Gil et Kimmel, le premier tant lauteur de lalgorithme.
167
Les travaux qui sont lis au nomde Marc Van Droogenbroeck proposent des mthodes amliors pour
le calcul rapide des rosions / dilatations et les ouvertures et les fermetures par des segments. Nous citons
larticle que cet auteur a publi en collaboration avec Hugues Talbot
DT96
et un autre article publi en
collaboration avec M. Buckley
DB05
. De plus, ces articles proposent les rsultats des tudes comparatives
avec dautres algorithmes existants du calcul des oprations morphologiques pour les segments. Les
implmentations de leurs algorithmes sont librement disponibles dans la bibliothque des algorithmes
"The libmorpho library"
DD06
qui mentionne dans sa documentation galement dautres rsultats des
tests comparatifs.
Nous avons choisi lalgorithme de van Herk-Gil-Werman pour dmontrer les principes de la construc-
tion de limplmentation de ce type dalgorithmes pour les architectures multimdia avec les capacits
SIMD.
8.2.1 Principe de lalgorithme de van Herk-Gil-Werman
Le fonctionnement de lalgorithme de van Herk-Gil-Werman (mentionn par labrviation HGW
dans la suite) tait dcrit originalement
vH92
pour les lments structurants qui ont la forme dun segment
symtrique et qui, par consquent, dsignent le nombre impair des pixels voisins. Lalgorithme HGW
est compos de 3 phases. Les deux premires prparent les valeurs intermdiaires des maxima (pour
la dilatation) / minima (pour lrosion) par la propagation des valeurs ; cette propagation est effectue
lchelle des blocs des pixels et non de limage entire. Dans la troisime phase, nous valuons les
rsultats naux partir des rsultats intermdiaires. La gure 8.3 illustre une vue globale sur ce fonc-
tionnement en dsignant par les ches les pixels de source et de destination pour lopration max / min
et en montrant ainsi la dpendance entre les rsultats intermdiaires lors de lvaluation.
valeur du bord
valeur du bord
partie de limage dentre
Rsultat
Buffer A
Buffer B
lment
structurant
FIG. 8.3 : Schma de fonctionnement de lalgorithme de van Herk-Gil-Werman
Expliquons le fonctionnement de cet algorithme plus en dtail. Tout dabord, nous procdons, dans
la direction parallle lorientation de llment structurant, au dcoupage de limage dentre en blocs
de pixels qui sont de la mme taille que celle de llment structurant et qui ont la dimension 1 dans
la direction perpendiculaire. Cest lchelle de ces macro blocs que le traitement est indpendant du
sens de parcours et que cest lintrieur de ces macro blocs que nous allons effectuer la propagation
des valeurs. La gure 8.3 illustre ce dcoupage sur une partie de limage, qui correspond une ligne de
cette image, pour llment structurant horizontal. Les blocs dcoups de 5 pixels sont dlimits par la
bordure paisse.
Lors de lexplication du fonctionnement, nous allons supposer que limage a des dimensions des mul-
tiples de la taille de llment structurant. On obtiendra ainsi le dcoupage parfait de limage aux macro
blocs. Les cas spciaux de limage qui ne pourraient pas tre dcoups parfaitement et qui contiendraient
168
chaque ligne un macro bloc de taille plus petite et connexe au bord de limage seraient grs par le ker-
nel du calcul diffrent, spcique la zone de limage connexe au bord. Ainsi, nous suivons lide de la
dcomposition du traitement en traitements de la zone de lintrieur et en traitement de la zone du bord,
comme prsents dans le chapitre 5, page 102 dans la section 5.1.2 qui tait ddi cette problmatique.
La premire phase, p
1
, de cet algorithme qui nous fournit la premire srie des rsultats interm-
diaires, utilise la propagation lintrieur des macro blocs dans une direction, choisie par convention
comme la direction suivant le sens des index montants. La gure 8.4(a) illustre cette situation. La propa-
gation des valeurs est effectue de la mme manire que prcdemment mentionne dans le chapitre 7,
page 7.2, dans la section 7.2 ddi aux skeletons applico-rdictifs mfoldl et mfoldl1. Donc, il est naturel
dutiliser ces skeletons pour exprimer cette phase de lalgorithme HGW dans le formalisme fonctionnel.
Les rsultats intermdiaires que nous obtenons aprs lapplication de cette phase sont groups, sur la
g. 8.4(a) en tant que Buffer A.
Buffer A
(a) Premire phase, p
1
Buffer B
(b) Deuxime phase, p
2
FIG. 8.4 : Phases p
1
et p
2
de propagation des valeurs de lalgorithme de van Herk-Gil-Werman
Avant de donner la description formelle pour la premire phase, nous prsentons informellement le
fonctionnement de la deuxime phase, p
2
, de lalgorithme HGW. Elle est, en effet, analogue la premire
et elle utilise la mme manire de propagation des valeurs lexception du sens de la propagation qui est
oppos. La gure 8.4(b) illustre cette situation.
Nous pouvons explorer les points communs est construire ainsi la description formelle dune phase
gnralise de la propagation des valeurs de lalgorithme HGW. La fonction phaseHGW est ddie ce
but et dnit cette phase gnralise :
phaseHGW :: (Ord) [ Char] ( ) Ar ( I , I ) Ar ( I , I )
phaseHGW Iov | mI = (array (bounds $mI))
( zip ix )
( mfoldl1 | )
(map ( mI! ) )
$ix
where ix = streamAr2D Iov mI
Le choix exact de la propagation est spci par le paramtre Iov. En regardant bien cette fonction, nous
nous apercevons que son corps est, en effet, identique celui de la fonction pGenMB (cf. sa dnition
dans le chapitre 7, page 152) qui dcrivait la propagation SIMDdans un macro bloc compos des vecteurs
paquets. Les deux fonctions diffrent dans leurs signatures de types et, par consquent, dans lusage
169
prvu. Tant que la fonction pGenMB a t conue directement pour le travail avec les vecteurs paquets,
la fonction dune phase gnralise phaseHGW est destine tout dabord au travail avec les lments de
base. Cest en effet cette similitude qui va lier les algorithmes de la propagation SIMD et les stratgies
de paralllisation de lalgorithme de van Herk-Gil-Werman.
Pour pouvoir driver les phases concrtes p
1
et p
2
de la propagation partir de la phase gnralise,
nous nous baserons sur le paramtre Jit qui exprimera textuellement la direction du segment, | /
SnJ si llment structurant suit la direction de la premire / deuxime coordonne, respectivement.
La premire phase de lalgorithme HGW est dnie par la fonction phase1 :
phase1 :: (Ord) [ Char] ( ) Ar ( I , I ) Ar ( I , I )
phase1 Jit | mI = phaseHGW ("FW"++Jit) | mI
et la deuxime phase de lalgorithme HGW est dnie par la fonction phase2 :
phase2 :: (Ord) [ Char] ( ) Ar ( I , I ) Ar ( I , I )
phase2 Jit | mI = phaseHGW ("BW"++Jit) | mI
Les deux fonctions utilisent linterne la fonction gnralise phaseHGW et la spcient pour le par-
cours en avant (par "FW") dans le cas de la phase p
1
et pour le parcours en arrire (par "BW") dans
le cas de la phase p
2
. Notons que les deux premires phases peuvent tre excutes en mme temps en
exploitant ainsi le paralllisme des tches.
La troisime phase utilise les rsultats intermdiaires obtenus par lapplication de la phase p
1
et p
2
et les combine dans le rsultat nal de lalgorithme. La g. 8.5 illustre son fonctionnement.
valeur du bord valeur du bord
Rsultat
Buffer A
Buffer B
Zone de la gestion du bord Zone de la gestion du bord
lment structurant
FIG. 8.5 : Schma de fonctionnement de lalgorithme de van Herk, phase p
3
Elle ne travaille pas lchelle des macro blocs mais celle dune ligne (colonne). tant donn k
le nombre des pixels dsigns par llment structurant, nous extrayons, pour une position donne x
dune dimension correspondant au pixel central lchelle dune ligne (colonne), les pixels avec lindex
x +
(k1)
2
partir du buffer ^ et les pixels avec lindex x
(k1)
2
partir du buffer B. Puisquil sagit
du calcul utilisant les vecteurs de dplacement pour valuer la valeur dun pixel, tous les phnomnes de
traitement non-dpendants du sens du parcours par les lments structurants, comme prsents dans le
chapitre 5, page 99, entrent en jeu, notamment ceux qui sont connexes la gestion des pixels aux bords
de limage. La gure 8.6 illustre ce travail sur lexemple de trois pixels, un plac dans la zone intrieure
de limage et dautres placs dans la zone de traitement des bords de limage.
Nous prsentons la dnition de la fonction phase3Gen qui effectue cette troisime phase et qui, pour
extraire une valeur partir des buffers temporaires Iu|
^
et Iu|
B
, utilise lapproche nave au traitement
des effets de bord, reprsente par la fonction sampGen :
170
valeur
du bord
Rsultat
Buffer A
Buffer B
Zone de la gestion du bord Zone de la gestion du bord
lment structurant
valeur
du bord
FIG. 8.6 : Exemple de la fusion des valeurs des buffers ^ et B lors de la phase p
3
pour un pixel dans la zone
intrieure de limage et pour les pixels dans les zones touchant les bords de limage
phase3Gen :: [ Char] BroderFnc I ( ) ( Ar ( I , I ) , Ar ( I , I ) ) Ar ( I , I )
phase3Gen Jit ItJ|nt I | (Iu|
^
, Iu|
B
) =
listArray (bounds $Iu|
^
)
(map ( i | ( sampGen ItJ|nt Iu|
^
(p
1
i ) )
( sampGen ItJ|nt Iu|
B
(p
2
i ) ) ) )
indices
$Iu|
^
where
p
1
( x
:
, x
z
) = if (Iov == "Fst" ) then ( x
:
+ div (I1) 2, x
z
) else ( x
:
, x
z
+ div (I1) 2)
p
2
( x
:
, x
z
) = if (Iov == "Fst" ) then ( x
:
(div (I1) 2), x
z
) else ( x
:
, x
z
(div (I1) 2))
Le paramtre Jit spcie la direction du segment (| ou SnJ) et la fonction ItJ| nt assure
lextraction des valeurs pour les index lextrieur du domaine des deux buffers. I est le nombre des
lments constituant le segment et | est la fonction effectuer (max ou min). Dans le cur de cette
fonction, nous crons le stream des index ix par la fonction indices du Haskell, nous procdons
lchantillonnage des deux buffers laide de la fonction sampGen pour les positions dcales p
1
et p
2
et nous appliquons ensuite la fonction | . La fonction listArray cre, dune manire standard, un array
partir dun stream des rsultats. Ainsi, nous obtenons une ligne (colonne) des valeurs rsultantes de
lopration morphologique.
Lalgorithme entier de van Herk-Gil-Werman que nous construisons partir de ces trois phases et qui
travaille avec les segments suivant laxe de la premire coordonne (Fst) est prsent par lalgorithme 8.2
en tant que fonction algoHGWFst. Notre intrt pour cette premire coordonne sera clairci par la suite
lors de la description de la version SIMD de cet algorithme. Notons que la spcication pour les segments
suivant la direction de la deuxime coordonne est analogue et peut tre facilement drive partir de la
dnition de la fonction algoHGWFst.
Lalgorithme HGW prend quatre arguments : I est la taille du segment symtrique, ItJ| nt est la
fonction qui assure lobtention de la valeur de lextrieur du domaine de limage lors dchantillonnage
des buffers dans la phase p
3
, | est la fonction qui assure lopration morphologique et ut est larray
dentre. Malgr la forme peu standard de cet algorithme, son fonctionnement nest pas plus compliqu
que ceux dj rencontrs. Nous commenons par appliquer (sur la ligne 18) sur larray ut le dcoupage,
ligne 17, en colonnes composes des lments de base. Nous passons, ligne 16, dun array un ux de
donnes (colonnes dans ce cas) et nous appliquons sur chaque colonne (ligne 6) un bloc de traitement
(entre les lignes 7 et 14).
Ce bloc fonctionnel est ddi la construction des buffer ^ et B. Il ne fait que dcouper chaque
colonne (ligne 14) en macro blocs de taille I du segment, exprime cette colonne en tant que ux des
macro blocs et applique sur chacun deux la phase1 et la phase2 de traitement par la propagation des
171
Algorithme 8.2 : algoHGWFst, Algorithme de van Herk-Gil-Werman de dilatation/rosion par un
segment suivant la direction de la premire coordonne
1 algoHGWFst :: I BroderFnc ( ) Ar ( I , I ) Ar ( I , I )
2 algoHGWFst I ItJ|nt | ut =
3 arrayFromMxNBlocs
4 ( listArray ( (1,1) , (1,q) ) )
5 (map (phase3Gen "Fst" ItJ|nt I | ) )
6 (map (
7 ( (mI^,mIB) (
8 arrayFromMxNBlocs ( listArray ( (1,1) , (mInum,1)) ) $mI^,
9 arrayFromMxNBlocs ( listArray ( (1,1) , (mInum,1)) ) $mIB
10 )
11 )
12 ( mI (map (phase1 "Fst" | ) mI),( map (phase2 "Fst" | ) mI) )
13 elems
14 (arrayToMxNBlocs mInum1) )
15 )
16 elems
17 (arrayToMxNBlocs 1 q)
18 $ut
19 where
20 (p,q) = dimsAr2D ut
21 mInum= div p I
valeurs. Les lignes restantes de ce bloc fonctionnel (ligne 7 11) construisent deux buffers partir des
rsultats du traitement lintrieur des macro blocs.
Lapplication de la phase3Gen se poursuit, ligne 5, lchelle du stream des colonnes et prend
comme argument le stream des tuples composs, pour chacune des colonnes des deux buffers correspon-
dants. Les lignes restantes (ligne 3 et 4) recomposent larray de sortie partir du stream rsultant des
colonnes.
8.2.2 Paralllisation pour les architectures SIMD
Une fois expliqu lalgorithme HGW pour les lments de base, nous nous demandons de quelle
manire nous pouvons explorer les capacits SIMD de notre architecture multimdia pour acclrer le
calcul de cet algorithme. Puisque cet algorithme utilise les principes de traitement qui sont compatibles
avec le traitement des donnes paquetes, nous pouvons facilement driver un algorithme SIMD par-
tir de la description de lalgorithme travaillant avec les lments de base, comme prsent par lalgo-
rithme 8.2. Nous allons travailler, comme lchelle des colonnes, tant lchelle des macro blocs, avec
les structures composes des vecteurs paquets PVec I plutt que dutiliser les structures composes
des lments de base du type .
Formellement, nous pouvons dcrire ce procd par la spcialisation de lalgorithme 8.2 pour les
donnes paquetes et lalgorithme qui dcrira ce procd devra assurer le paquetage de larray dentre,
appel de lalgorithme algoHGWFst et, la sortie, galement le dpaquetage des rsultats an dobtenir
larray compos des donnes du type de base.
Cependant, nous ne pouvons pas choisir nimporte quelle direction pour la propagation des valeurs
SIMD car nous sommes contraints par le sens de stockage des donnes vectorielles dans la mmoire.
Ainsi, il est simple de construire lalgorithme pour les segments qui sont perpendiculaires au sens de
stockage. En revanche, il est impossible dutiliser lalgorithme SIMD de van Herk-Gil-Werman pour un
segment parallle au sens du stockage et nous sommes obligs deffectuer une opration de changement
du sens de stockage des donnes vectorielles, comme dcrit dans le chapitre 6 ddi cette probl-
172
matique. Dans ce cas, nous allons faire appel la transposition des images entires. Remarquons que
nous pourrions construire galement des algorithmes qui exploiteraient lapproche des macro blocs et la
transposition directe, mais nous soulignons que leur construction, mme possible, nest pas triviale.
Cest cette place que nous allons expliquer pourquoi nous avons choisi laxe "Fst" pour la construc-
tion de lalgorithme 8.2, dni par la fonction algoHGWFst. Supposant que les donnes sont stockes
dans la direction de la deuxime coordonne, ce sont les segments suivant la direction "Fst" pour lesquels
nous pouvons construire lalgorithme SIMD dune manire simple, comme prsent par lalgorithme 8.3
(dni par la fonction algoHGWFstSIMD).
Algorithme 8.3 : algoHGWFstSIMD, Algorithme SIMD de van Herk-Gil-Werman pour les seg-
ments suivant la direction de la premire coordonne (Fst) et en supposant que laxe de stockage
des donnes dans la mmoire est "Snd"
1 algoHGWFstSIMD :: I I BroderFnc ( ) Ar ( I , I ) Ar ( I , I )
2 algoHGWFstSIMD n I ItJ|nt | ut =
3 mkAr2DFromAr2DPVecBySnd
4 (algoHGWFst I ItJ|nt | )
5 (mkAr2DPVecBySnd n)
6 $ut
La construction de lalgorithme 8.4 (dni par la fonction algoHGWSndSIMD) exploitant les capa-
cits SIMD pour les segments suivant la direction parallle laxe de stockage de donnes est enrichie
par la transposition par diagonale, excute par la fonction trRot2DMBSIMD, qui assure le change-
ment du sens de stockage des donnes. Cela deux reprises, avant et aprs lexcution de lalgorithme
algoHGWFstSIMD.
Algorithme 8.4 : algoHGWSndSIMD, Algorithme SIMD de van Herk-Gil-Werman pour les seg-
ments suivant la direction de la deuxime coordonne (Snd) et en supposant que laxe de stockage
des donnes dans la mmoire est "Snd"
1 algoHGWSndSIMD :: I I I BroderFnc ( ) Ar ( I , I ) Ar ( I , I )
2 algoHGWSndSIMD mIiza n I ItJ|nt | ut =
3 (trRot2DMBSIMD "TD" "Snd" mIiza )
4 (algoHGWFstSIMD n I ItJ|nt | )
5 (trRot2DMBSIMD "TD" "Snd" mIiza )
6 $ut
8.3 Rsultats exprimentaux
Nous avons implment la version SIMD de lalgorithme de van Herk-Gil-Werman laide des
templates du langage C++, fournis avec le compilateur Intel ICL que nous avons utilis pour cette im-
plmentation. Pour pouvoir illustrer ses performances sur une architecture grand public, nous avons
effectu dautres tests qui ont une valeur informative car leurs temps dexcution sont de loin moindres.
La table 8.1 mentionne les rsultats en chiffres. Limplmentation SIMD y est mentionne en tant que
C++ template SSE2.
Nous avons test limplmentation itrative, cf. la section 8.1, page 166, qui utilise linterne, comme
lalgorithme de base pour les itrations, une implmentation optimise manuellement au niveau dins-
tructions dassembleur pour larchitecture Intel IA-32 qui exploitait lexcution SIMD lchelle des
registres 32 bits.
173
Nous mentionnons galement deux autres implmentations qui ont t crites dans le langage C, sans
avoir explor les capacits SIMD. La premire (mentionne comme Cnon-SIMD* dans la tab. 8.1) a suivi
directement la dnition, utilisait abondamment les structures if-else dans les tests de dpassement des
bords, et correspond une implmentation intuitive quun programmeur effectue si la performance de
lalgorithme nest pas sa priorit. Nous avons restructur le code de cette implmentation dans une forme
plus propre qui ne fait plus appel aux instructions spciques larchitecture (mentionne comme C non-
SIMD**). Nous avons espr que le compilateur pourrait, dans un tel code, procder la vectorisation
de la mme manire que nous lavons expose dans lalgorithme 8.3, mais malgr le gain que nous
avons obtenus et qui est d la restructuration de cette implmentation, le temps dexctution est plutt
dcevant, surtout si on le compare avec les temps obtenu pour les implmentations C++ template SSE2
qui intgrent le travail SIMD dans la structure de lalgorithme.
Temps dexcution en ms des algorithmes de la dilatation par segments
algorithme mthode type
Taille du segment symtrique (1 3 pixels)
1 3 5 15 30 60
Itratif assembleur 32 bits HOR 1.486 3.893 5.791 13.00 21.96 36.85
Itratif assembleur 32 bits VER 3.256 8.596 10.31 31.18 52.35 91.84
HGW C non-SIMD* HOR 31
HGW C non-SIMD** HOR 6.1
HGW C++ template SSE2 HOR 0.626 0.625 0.622 0.602 0.602 0.592
HGW C++ template SSE2 VER 0.334 0.331 0.313 0.276 0.261 0.260
Lgende : HOR = segment horizontal, VER = segment vertical ; Limplmentation assembleur 32 bits est program-
me en assembleur et utilise directement les instructions 32 bits de larchitecture Intel IA-32 ; limplmentation C
non-SIMD* selon la dnition mathmatique, utilise abondamment les constructions if-else ; limplmentation C
non-SIMD** est la plus optimise possible en C et la main sans utiliser les types vectoriels. Limplmentation
C++ template SSE2 utilise les classes fournies avec le compilateur Intel ICL pour le calcul vectoriel. Limage
dentre/sortie : 768 576 8 bits = 432 ko ; processeur Intel Pentium 4 2.4 GHz, mmoire cache L2 = 512
ko ; systme dexploitation Microsoft Windows XP ; compilateur Intel ICL 7.1 pour Windows.
TAB. 8.1 : Rsultats exprimentaux de diverses implmentations de la dilatation par segments
Le graphe prsentant les temps dexcution dpendant de la taille du segment pour limplmentation
itrative, cf. la g. 8.7(a), a tout--fait la forme attendue sachant que la complexit de cet algorithme pour
une image donne est de O(K), o K est le nombre de voisins traits par pixel. Les temps dexcution
grandissent avec la taille de llment structurant linairement.
Nous prsentons cette courbe comme contre-exemple pour dmontrer quil est possible de calculer
les dilatations / rosions beaucoup plus rapidement et surtout, avec un algorithme ayant la complexit
O(1), o le temps du calcul ne dpend pas du nombre des voisins traits par pixel, q.v. la g. 8.7(b).
Il sagit de limplmentation SIMD de lalgorithme de van Herk-Gil-Werman, cf. les dnitions de la
fonction algoHGWFstSIMD(lalgorithme 8.4) et de la fonction algoHGWSndSIMD(lalgorithme 8.4).
Lcart entre les deux courbes dans la g. 8.7(b) qui est dune valeur constante nest pas surpre-
nant car nous savons comment nous avons construit ces deux implmentations. Cet cart correspond, en
effet, 2 excutions de la transposition par diagonale de limage entire. Un phnomne plus intres-
sant prsent par les mmes donnes est celui de la baisse du temps du calcul avec la taille du segment
grandissant qui est, au premier regard, paradoxal.
Au dbut, nous avons jug que cette baisse tait due aux optimisations que le compilateur peut
effectuer dans le code de boucles lors de lexcution de la phase p
1
et p
2
lchelle des macro blocs. Mais
lexplication est, en fait, plus simple. Il sagirait dun phnomne d la gestion des boucles car pour
les tailles grandissantes des segments, nous obtenons moins de macro blocs et par consquent, moins de
boucles. Ce phnomne est prsent galement dans les implmentations non-SIMD de lalgorithme de
van Herk et mme dans dautres, nous renvoyons le lecteur aux articles
DB05
et aux publications
DD06
qui
prsentent les graphiques avec des tendances similaires.
174
0
10
20
30
40
50
60
70
80
90
100
0 10 20 30 40 50 60
t
e
m
p
s

/

m
s
taille de llmnt structurant (1 = 3 pixels)
itratif, asm32, horizontal
itratif, asm32, vertical
(a) Algorithme itratif
0.25
0.3
0.35
0.4
0.45
0.5
0.55
0.6
0.65
0 10 20 30 40 50 60
t
e
m
p
s

/

m
s
taille de llmnt structurant (1 = 3 pixels)
VanHerk, SSE2, horizontal
vanHerk, SSE2, vertical
(b) Algorithme SIMD de van Herk-Gil-Werman pour Intel SSE2
FIG. 8.7 : Les temps du calcul des implmentations de la dilatation / rosion par un segment pour une image
768 576 8 bits = 432 ko
175
8.4 Rcapitulation
Ce chapitre a t consacr lexplication des principes de la construction des algorithmes SIMD
de la dilatation / rosion par les segments. Nous avons prsent le cas spcique de limplmentation
de lalgorithme de van Herk-Gil-Werman pour les lments structurants de la forme des segments ho-
rizontaux et verticaux. Cet algorithme nous a galement servi dans cette thse comme exemple dun
algorithme complexe qui rutilise toutes les techniques de travail avec les vecteurs paquets prsentes
dans les chapitre prcdents, notamment la gestion de la dpendance de lexcution sur le parcours lors
de la propagation des valeurs, lexploitation de la non-dpendance de lexcution sur le sens du par-
cours lchelle des macro blocs et, enn, lutilisation de la transposition par diagonale an dassurer le
changement de laxe de stockage des donnes.
Ces principes peuvent tre rutiliss dans dautres implmentations des algorithmes de ce type. Nous
pensons, en particulier, aux implmentations sur la grille hexagonale, limplmentation de lalgorithme
de van Herk-Gil-Werman avec la transposition directe par macro blocs et limplmentation SIMD des
dilatations / rosions pour les segments inclins qui nest pas triviale car elle devrait grer lappartenance
des donnes utilises dans lalgorithme HGW plusieurs macro blocs ddis la transposition. Lemploi
de ces techniques dans les algorithmes pour les ouvertures et fermetures rapides par les segments est
galement envisager.
176
CHAPITRE 9
Algorithmes et complexit
9.1 Dnition dun algorithme
Dans le contexte moderne, les algorithmes sont les mthodes pour la rsolution des problmes sur
les ordinateurs. Dans le contexte plus large que celui restreint linformatique, nous comprenons sous le
terme algorithme une prescription qui peut avoir diffrentes formes (textuelle, dune formule mathma-
tique, dun diagramme de squence, dun langage de programmation, etc.). Cette prescription dcrit une
mthode de rsolution dun problme qui, aprs tre effectue, nous fournit la solution du problme.
Lutilisation des algorithmes nest pas un phnomne de lpoque des ordinateurs et du calcul auto-
matique. Les algorithmes ont t connus et employs depuis bien longtemps et cette utilisation remonte,
daprs
Wik06a
Donald Knuth, travers lAntiquit jusquau Babyloniens (1800 avant J.C). En revanche,
lorigine du mot algorithme est plus rcent (9me sicle) ; il a ses racines dans la traduction latine da-
tant du Moyen ge du nom de Abou Jafar Muhammad Ibn Musa al-Khuwarizmi
Wik06a
o son nom
al-Khuwarizmi
1
tait traduit en Algoritmi.
Par curiosit, nous pouvons dcouvrir
Wik06b
galement que le titre Al-jabr wal-muqabalah dun des
ouvrages dal-Khuwarizmi (publi en 825) qui signie La transposition et la rduction est lorigine
dun autre mot que lon utilise frquemment de nos jours algbre. Plus prcisment, cest sa partie
Al-jabr qui aprs la traduction latine puis la traduction franaise devint algbre et dsigne aujourdhui
une discipline de la mathmatique moderne dont certaines techniques sont dj dcrites dans louvrage
concern dal-Khuwarizmi.
9.2 Complexit dun algorithme
9.2.1 Dnition de la complexit
Sous le terme de complexit dun algorithme donn nous comprenons le cot de lutilisation de cet
algorithme. Ce cot peut tre exprim dans diverses units, par exemple, comme le temps du calcul,
comme de nombre doprations arithmtiques, le nombre doprations avec la mmoire, etc.
9.2.2 Les mesures de la croissance
Mme si, dun point de vue pratique, le temps du calcul est une mesure extrmement intressante,
elle nest pas utilisable lors de ltude thorique de la complexit des algorithmes o nous avons besoin
de comparer le fonctionnement thorique de deux algorithmes diffrents et nous avons besoin de rester
1
Appel aussi al-Khwarizmi ou al-Khorezmi selon le nom de sa ville natale Khwarizm ou Khorezm; notre poque il
sagit de la ville Khiva en Ouzbkistan
177
abstraits dune architecture particulire. Cest pourquoi nous faisons appel aux mesures qui dnissent la
relation entre deux fonctions mathmatiques. Nous avons recours aux fonctions plutt quaux numros
prcis, car, dans la plupart des cas, cest lvolution du cot pour un ou plusieurs paramtres donns qui
nous intresse.
Les mesures de croissance largement utilises et dcrites par les symboles o (petit o), O (grand o),
, et sont dues Donald Knuth
Wik06e
. Ces mesures sont toujours relatives deux fonctions. Lors
de la description dun algorithme, nous allons substituer sa complexit par une de ces fonctions et nous
allons modliser cette complexit en choisissant convenablement une autre fonction qui va nous servir
comme talon tout en respectant la dnition de la mesure de croissance choisie.
Les dnitions des mesures de croissance que nous prsentons sont extraites du livre traitant des
algorithmes et de la complexit de Herbert S. Wilf
Wil94
. Pourtant, nous nallons avoir recours qu cer-
taines de ces fonctions pour exprimer la complexit des algorithmes dans cette thse, notamment O et
qui semblent les plus adapts nos besoins.
Dnition 9.1 (Dnition do (petit o)).
Nous disons que f(x) = o(g(x)) pour x si lim
x
f(x)/g(x) existe et est gale 0.
Dnition 9.2 (Dnition dO (grand o)).
Nous disons que f(x) = O(g(x)) pour x si C, x
0
tels que |f(x)| < Cg(x), x > x
0
.
Dnition 9.3 (Dnition de ).
Nous disons que f(x) = (g(x)) sil existe les constantes c
1
> 0, c
2
> 0, x
0
telles que c
1
g(x) <
f(x) < c
2
g(x), pour x > x
0
.
Dnition 9.4 (Dnition de ).
Nous disons que f(x) g(x) si lim
x
f(x)/g(x) = 1.
Dnition 9.5 (Dnition d).
Nous disons que f(x) = (g(x)) si > 0 est une squence x
1
, x
2
, x
3
, telle que j :
|f(x
j
)| > g(x
j
)
9.3 Modlisation des performances
La mesure de croissance utilise le plus souvent dans la littrature pour estimer le cot des algo-
rithmes est O. Limpact de cette mesure pour lvaluation de la complexit est intelligible. Elle nous
permet de rester abstraits des dtails de fonctionnement dun algorithme et de le modliser, tout en rem-
plissant la dnition, par une autre fonction qui est plus simple dcrire et comprendre. Elle est trs
utile dans le cas o nous comparons la complexit de deux algorithmes diffrents ; par exemple, il est
vident quun algorithme dont la complexit est de O(N
2
) sera beaucoup moins avantageux que celui
dont la complexit est de O(Nlog
2
N), pour N N, car nous remplaons, dans ce dernier, une fonction
polynomiale par une fonction contenant des logarithmes dont la croissance est moindre.
Pourtant, cette mesure nest pas la meilleure pour lestimation pratique du cot des algorithmes. En
effet, ce nest pas sa vocation principale car elle dnit la borne asymptotique maximale. En se basant
sur N, le nombre des lments traiter, cette mesure ne capte pas le vrai cot que nous devons payer
pour lvaluation de ces lments.
Dans la morphologie pratique, comme dans dautres domaines dailleurs, nous ne travaillons pas avec
des images excessivement grandes, dautant moins avec les images dont le nombre dlments approche
linni. Ce fait est accentu lors du traitement dimages en temps rel o nous essayons de rduire le
temps du traitement le plus possible et o nous travaillons avec les sections dune image ou avec des
images sous-chantillonnes. Dans ces cas, lestimation de la complexit via O() peut nous conduire au
choix dun algorithme inadapt la situation particulire que nous rencontrons.
Expliquons ce fait sur un exemple synthtique mais qui dmontre bien la situation. Ayons un pre-
mier algorithme dont la complexit est O(N
2
) et ayons un deuxime algorithme dont la complexit est
178
Jaromr BRAMBOR 9.4. ESTIMATION DE LA COMPLEXIT ET DES PERFORMANCES POUR LES GPP/GPPMM
O(Nlog
2
N) o N est le nombre des lments, N N. En principe, nous sommes tents dutiliser le
deuxime algorithme dont la complexit est exprime par une fonction moins croissante. Cependant,
nous ne pouvons pas comparer le cot exact par une simple comparaison de O() des deux algorithmes.
La complexit exprime en O() ne nous indique pas le cot exact pour un cas prcis et nous pouvons
effectivement trouver des cas spciaux pour lesquels le choix du premier algorithme serait une solution
plus adapte.
Imaginons que le premier algorithme utilise pour valuer les lments les oprations de base, en
revanche, le deuxime algorithme va utiliser des oprations plus complexes ; ce qui va se traduire par un
cot plus important pour le traitement dun lment du deuxime algorithme. Supposons que le rapport
entre les cots des deux algorithmes, cette fois-ci ntant pas exprim par le O(), est li par une constante
c 1 et que nous cherchons les valeurs prcises de N pour lesquelles le choix du deuxime algorithme
est justi. Nous essayons, en effet, de trouver la solution de lingalit :
N
2
cNlog
2
N
ce qui peut tre rcrit comme :
N clog
2
N
ou encore :
2
N
N
c
Ici, nous comparons une fonction exponentielle avec une fonction polynomiale. Si nous essayons de
concrtiser les valeurs, nous nous apercevons que pour c = 1 et c = 2, lingalit est valable N Ntant
que pour c 3, nous obtenons un intervalle (pour c = 3 il sagit des valeurs N = {2, 3, 4, 5, 6, 7, 8, 9})
dans lequel lingalit nest pas valable. Pour les valeurs N concrtes incluses dans cet intervalle, lem-
ploi du premier algorithme serait plus avantageux. Cet intervalle slargit avec la valeur c grandissante.
9.4 Estimation de la complexit et des performances pour les GPP/GPPMM
9.4.1 Ide gnrale
Lexemple dcrit prcdemment devait nous dmontrer lutilit pratique de la spcication prcise
lors de lestimation de la complexit dun algorithme. cette occasion, lutilisation de O ou de la mesure
plus restrictive o nest pas la meilleure solution.
Pour pouvoir exprimer le cot de nos algorithmes avec lintention de pouvoir estimer le temps du
calcul, nous voudrions identier les divers paramtres qui inuent le plus le cot dun tel algorithme.
Vu que nos algorithmes, mme gnraliss, seront fortement orients sur les architectures GPP et sont
surtout GPPMM qui ont un fonctionnement particulier, lexpression qui estimera la complexit pratique
dun algorithme peut tre perue comme la construction dun modle de performance de cet algorithme
pour la classe des architectures GPPMM.
En pratique, nous allons distinguer explicitement les oprations qui ont un cot diffrent et nous
allons les prsenter comme telles dans notre modle de performance. Les diffrences entre le modle et
la ralit sont toujours prsentes et cest pourquoi nous allons lier ce modle thorique avec le vrai cot
dun algorithme par la mesure , cf. sa dnition, page 178. Cette mesure est capable dassimiler, via les
constantes c
1
et c
2
de sa dnition, les diffrences entre notre modle de performance et la performance
exacte dun algorithme.
Nous avons une importante remarque faire cette place concernant lutilisation pratique de
comme nous venons de le prsenter. Si f(x) = x
2
est la complexit exacte dun algorithme, nous
pouvons crire f(x) = (x
2
). Mais mme si le terme peut dsigner le cot prcis par pixel, nous
pouvons exprimer cette complexit galement comme f(x) = (x
2
) sans sattaquer la validit de
lestimation. Le fait dutiliser les termes constantes la mme place o nous avons utilis est critiqu
(Wilf
Wil94
, page 6) comme un mauvais style car najoute aucune information vis--vis la dnition de
179
. Pourtant, il nous semble utile de ly mentionner car si ce terme est bien dcrit et rete correctement
la ralit, il peut nous dmontrer plus en dtail la structure de la fonction du cot dun algorithme.
Notons que la seule manire de vrier que notre estimation, que nous appelons estimation pratique
de performance, est correcte et cohrente avec la ralit, cest la mesure physique du temps du calcul
dun algorithme sur une architecture donne et pour les paramtres donns (les dimensions dimage,
dlment structurant, etc.).
9.4.2 Estimation pratique pour les GPPMM
Expliquons sur un exemple trivial comment nous envisageons de procder cette estimation pratique.
Nous prenons lexemple de lopration addition de deux images (arrays) de dimensions M N et dont
le rsultat serait galement une image. Nous voulons excuter cette opration sur une architecture GPP
avec un seul processeur. La complexit C
1
de lalgorithme trivial travaillant lment par lment exprim
en O est O(MN) ce qui peut galement tre exprim, en effet, comme :
C
1
= O(N
2
). (9.1)
Si nous voulons dcrire un modle de performance prcis, il faut dabord distinguer les oprations
avec la mmoire des oprations arithmtiques qui peuvent participer au cot nal par diffrentes pro-
portions. Notons comme le cot de toute les oprations avec la mmoire (lecture et criture) pour un
lment dimage. Notons comme le cot de toutes les oprations arithmtiques qui sont ncessaires
pour valuer un lment. Ainsi, le cot de cet algorithme peut tre estim comme
C
1
= (( +)MN). (9.2)
ce qui donne une ide plus prcise de son fonctionnement.
Regardons comment vont changer ces estimations si nous utilisons la place dune architecture GPP
avec un seul processeur (un seul l dexcution physique) une architecture GPPMM plusieurs pro-
cesseurs et/ou plusieurs curs et/ou plusieurs ls dexcution indpendantes et/ou paralllisme
superscalaire avec les capacits SWAR. Notons par P le nombre de processeurs qui peuvent assurer
lexcution concurrente et que S soit le nombre dlments qui peuvent tre traits par les instructions
SIMD en mme temps. Puisque les cots daccs la mmoire et les cots des oprations arithmtiques
ne sont pas, dans le cas gnral, les mmes que ceux prsents dans lquation 9.2, nous allons dnoter
par le cot de toutes les oprations arithmtiques ncessaires pour lvaluation dun lment multim-
dia large et par le cot daccs la mmoire pour un tel lment. Pour cette conguration matrielle, il
est possible de concevoir un algorithme dont la complexit C
2
sera :
C
2
= (( +)
MN
SP
). (9.3)
Pour pouvoir obtenir des estimations trs concrtes, il faut substituer aux termes , , et des
valeurs concrtes qui peuvent tre exprimes comme multiples de cycles dhorloge de notre architec-
ture. Pour faire cela, il faut trs bien connatre larchitecture de notre matriel informatique et surtout les
phnomnes entrant en jeu. Il sagit souvent des effet indsirables du prchargement de donnes dans
la mmoire cache en temps dexcution ce qui se manifeste, pour les grandes images nentrant pas en-
tirement en mmoire cache, par un ralentissement assez important de lexcution. Ce phnomne est
accentu dans le cas o la zone de la mmoire de sortie est distincte des deux zones de mmoires dentre
car dans ce cas, nous travaillons effectivement avec 3 images et le volume des donnes traites peut trs
rapidement dpasser la taille de la mmoire cache.
Ce point est dautant plus marquant sur les fonctions triviales telles que laddition que nous abor-
dons ici. Ce type doprations nexcute pas assez dinstructions arithmtiques pour pouvoir cacher la
prparation des donnes dans lexcution conuente des instructions en pipeline (cf. 3.2.3, page 38).
180
Jaromr BRAMBOR 9.5. EXEMPLE DESTIMATION PRATIQUE DE LA COMPLEXIT DES ALGORITHMES DE VOISINAGE
Pour illustrer cet exemple, nous prsentons dans la table 9.1 les temps du calcul de lopration addi-
tion avec saturation que nous avons obtenus comme des rsultats exprimentaux.
dimensions volume de donnes mthode temps taux
dimage manipul dimplmentation en ms dacclration
128
2
8bits 3*16 ko = 48 ko
gnrique 0.175 0.26
via pointer++ 0.045 1.0
multimdia 64 bit 0.005 9
256
2
8bits 3*64 ko = 192 ko
gnrique 0.69 0.28
multimdia 64 bit 0.03 6.3
512
2
8bits 3*256 ko = 768 ko
gnrique 3.00 0.2
multimdia 64 bits 0.40 1.5
Opration travaillant avec 3 images, chacune dans une zone de mmoire distincte. Limplmentation gnrique
utilise les fonctions getPixel()/setPixel() ; limplmentation via pointer++ travaille lment par lment en utili-
sant les pointeurs ; limplmentation multimdia 64 bits utilise les instructions spciales SIMD de 64 bits pour
valuation. Machine : Intel Pentium 4 @ 2.4 GHz, single thread, 8 ko L1, 512 ko L2 cahce, Linux Mandrake 9.2.
Compilateur Intel ICC 8.1, optimisations manuelles dans le cas multimdia 64 bits.
TAB. 9.1 : Temps du calcul de lopration addition avec saturation sur les images dont les lments sont du
type unsigned integer 8bit
Il est vident que pour le volume de donnes traites de 48 ko et 192 ko qui entrent dans la mmoire
cache L2 de notre machine (512 ko), les taux dacclration 9 et 6.3 sont cohrents avec la valeur attendue
pour le travail SIMD de 64 bits qui devrait nous fournir, en thorie, le taux dacclration gale 8. En
revanche, pour les images 512
2
dont la taille correspond aux volume manipul de 768 ko, nous dpassons
les capacits de notre architecture ; cela se rete sur le temps du calcul qui dpasse les temps que lon
pouvait esprer en faisant une simple extrapolation des rsultats prcdents. Le taux dacclration tombe
dans ce cas une valeur trs dcevante 1.5.
Cet exemple trs pratique nous dmontre que notre estimation devrait inclure galement dans le cot
pour les oprations avec la mmoire et un terme supplmentaire dont le comportement serait non-
linaire et dpendant de la taille de limage et de la taille de la mmoire cache. Nous pouvons lexprimer
par la dcomposition des coefcients du cot et comme :
=
1
+
2
(MN)
=
1
+
2
(MN)
o les premiers termes
1
et
1
expriment les cots que lon paye pour un accs aux donnes prsentes
dans la mmoire cache ; et o les deuximes termes
2
et
2
, qui sont les fonctions de la taille de limage
MN expriment les cots relatifs au comportement particulier lors du chargement de donnes dans la
mmoire cache en cas de leur absence.
9.5 Exemple destimation pratique de la complexit des algorithmes de voi-
sinage
En ce qui concerne la complexit de lapproche nave, il ne suft pas davoir que le skeleton algo-
rithmique ngbAlgo pour son valuation. Ce skeleton est trs gnrique pour pouvoir effectuer ltude de
la complexit en ne se basant que sur lui. Il faut spcier galement les scnarios de son utilisation qui
sont en directe correspondance avec les algorithmes concrets dilSQR et dilHEXR que nous venons de
prsenter.
Lapproche nave telle quelle est dnie est gnrique. Elle utilise la fonction dextraction du voisi-
nage qui teste pour chaque accs au voisin si celui est inclus dans le domaine de limage. tant donn
une image de M N pixels, N, M N, un lment structurant compos de K vecteurs, K < MN.
181
partir de ces indices, nous pouvons estimer la complexit de lapproche nave par O comme :
C
N
= O(KMN) = O(KN
2
) (9.4)
Pour exprimer la complexit et sa structure plus en dtail, nous devons spcier dautres paramtres
cruciaux. Que (K) dsigne le cot du calcul des oprations arithmtiques ou logiques dans le kernel, ce
cot et une fonction du nombre des lments de llment structurant. Que L dsigne le nombre daccs
qui devrait tre effectus au-del du domaine de limage lors de lextraction des voisins. Que dsigne
le cot que nous payons pour tester si lindex dun lment est dans le domaine de limage ou pas et
que dsigne le cot daccs un lment dans a mmoire et que dsigne le cot de lobtention dun
lment au-del des bords de limage.
Lors du calcul dun algorithme de la morphologie mathmatique qui utilise le skeleton algorithmique
ngbAlgo, la complexit pratique peut tre exprim comme :
C
N
= ((K)MN +KMN +(KMN L) +L) (9.5)
o le premier terme (K)MN dsigne le cot des oprations arithmtiques, le deuxime KMN le
cot des testes si llment extraire est lintrieur du domaine, troisime (KMN L) reprsente
le cot daccs la mmoire pour les lments qui sont lintrieur du domaine. Le quatrime L
reprsente un cot gnralis pour lobtention des lments qui sont lextrieur du domaine, ce terme
peut exprimer aussi bien le cot dun bord dune valeur constante mais galement le cot dextraction
dun pixel du domaine de limage si nous travaillons avec les bords qui retent le contenu de limage.
Lquation 9.5 peut tre rcrite comme :
C
N
= (( +)KMN +(K)MN + ( )L) (9.6)
Lquation 9.6 nous dmontre la structure des cots de cette approche nave. Les ides pour une amlio-
ration des performances surgissent directement de cette quation et nous verrons par la suite comment
nous pouvons rduire des cots en changeant la structure de notre algorithme.
En ce qui concerne les stratgies de paralllisation de cette approche nave, nous exploiterons les
paradigmes de la paralllisation de donnes et la paralllisation des tches. La forme exacte de parall-
lisation dpend des possibilits de notre matriel parmi lesquelles la rplication fonctionnelle exprim
par le skeleton farm est la plus simple est conduirait un changement dans lalgorithme 5.1 dont nous
prsentons ici les lignes changes et o nous utilisons la place de la fonction map la fonction farm :
4 (farm op)
5 (farm (axt ut ) )
Ce changement est mineur en ce qui concerne la forme de cet algorithme mais il introduit des cons-
quences majeures sur la conception de larchitecture et sur les performances. Vu que lextraction du
voisinage dun pixel peut prendre un temps diffrent et le plus souvent plus long que le calcul de lop-
ration du kernel, les stratgies de paralllisation peuvent varier fortement. Pour le bon quilibre de la
charge des blocs dans le pipeline dexcution, nous pouvons choisir, dans le cas gnral, la multiplication
des moyens matriels diffrente pour le kernel dextraction des voisins et pour le kernel de lopration
morphologique.
Notons que dexprimer la complexit dune telle stratgie de paralllisation partir de lquation 9.4
laide dO posera des problmes car cette formule ne dcrit pas explicitement la complexit des diff-
rentes parties du pipeline dexcution mais celle du pipeline tout entier. Cest pourquoi nous nous basons
sur lquation 9.6 de la complexit pratique o nous distinguons les oprations avec la mmoire des
oprations arithmtiques. Si E est le nombre des units qui sont ddies lexcution en parallle de la
fonction dextraction des voisins et P est le nombre de processeurs qui sont ddis au calcul de lop-
ration sur le voisinage en parallle, la complexit qui estime le temps du calcul pour la conguration
182
Jaromr BRAMBOR 9.6. ESTIMATION DE LA COMPLEXIT ET DES PERFORMANCES POUR LES GPU
parallle pourra tre exprime comme :
C
N
= (
( +)KMN + ( )L
E
+
(K)MN
P
) (9.7)
Il est vident que nous obtenons les meilleures performances vis--vis du temps de calcul dans le cas o
le traitement sur toutes les units paralllises de notre chane est quilibr.
9.6 Estimation de la complexit et des performances pour les GPU
Mme sil nest pas trs difcile de dcrire la complexit des algorithmes pour les GPU laide de
O() en se basant sur les lments traits, la prvision des performances, comme nous le faisons pour les
GPP laide de () nest pas simple effectuer.
Cest la combinaison des processeurs GPP - GPU qui rend cette estimation difcile. Dans cette
combinaison, il sagit dune machine distribue, avec tous les phnomnes qui sont propres au calcul
distribu, dont les plus importants sont les dlais ds au transfert de donnes dentre et de sortie et les
dlais ds au temps de synchronisation et au passage des commandes graphiques qui peuvent avoir une
structure complexe et reprsenter un volume de donnes important.
Il faut galement percevoir le GPU lui-mme comme une structure de multiples processeurs, cf.
g. 3.18, page 52. Puisquil sagit dune structure architecturale qui est chane, la performance nale est
fortement dpendante du type des algorithmes que nous effectuons et de la manire dont nous utilisons
les units excutives de cette chane. Chacune de ces units est constitue dun matriel informatique
spcialis et est caractrise par un niveau de paralllisation diffrent. Ce qui se traduit par des capacits
de calcul diffrentes dune unit lautre. Si une des units est sature par le traitement, tout le pipeline
est satur et on parle, dans le domaine de la programmation des GPU, du traitement limit par cette
unit. Les capacits des ces units sont optimises par le fabricant pour les applications de la synthse
graphique, elles peuvent savrer non-optimales ou compltement inadaptes au traitement danalyse
dimages que nous visons dans cette thse. Loptimisation des programmes pour obtenir un bon quilibre
du calcul entre ces units et pour augmenter ainsi la performance est mme le sujet de nombreux articles
que lon peut trouver dans la littrature
CW02, Spi03
.
9.6.1 Transfert de donnes
Le premier facteur trs limitant pour notre traitement est reprsent par les temps que nous perdons
lors du transfert de donnes et cela dans les deux sens (GPPGPU). Notons que les articles traitant du
transfert de donnes du point de vue de la programmation, un sujet particulier mais important, ont t
dj prsents et nous les recommandons au lecteur
Ake03
.
Le bus AGP que nous avions disposition est asymtrique. Le dbit dans le sens GPPGPU est
suprieur (thoriquement jusqu 2.1 Go/s pour AGP 8x) celui dans le sens oppos (thoriquement 266
Mo/s, ce qui est quivalent "1x").
Nous prsentons les temps obtenus exprimentalement pour le transfert de donnes GPUGPP sur
la g. 9.1. Ces temps correspondent AGP 1x et nous montrent les temps excessivement longs pour
un travail en temps rel : par exemple, le transfert dune image 256
2
4 bits prend 1.5 ms, ce qui est
suprieur dans certains cas la dure du traitement de ces donnes par le processeur graphique, comme
nous lavons pu voir dans les rsultats exprimentaux du chapitre 5, page 123, notamment sur le temps
dexcution de 0.65 ms de la dilatation par un disque en 4-voisinage de taille 1 pour une image de 1 Mo.
Ces donnes reprsentent un aspect linaire de croissance pour un volume de donnes transfres
grandissant, cf. g. 9.1(a), avec une dviation pour les images relativement petites (128
2
4) qui est
perceptible chelle logarithmique, cf. g. 9.1(a).
Lutilit du bus AGP pour le calcul GPGPU est discutable. Ce bus devint obsolte avec larrive du
nouveau bus PCI Express. Il sagit dun bus sriel (AGP tait un bus parallle), il est symtrique et plus
183
100
1000
10000
100000
0.01 0.1 1 10
t
e
m
p
s

(
s
)
Donnes transfres (Mo)
128x128x4x8bit
256x256x4x8bit
320x240x4x8bit
352x288x4x8bit
512x512x4x8bit
480x576x4x8bit
640x480x4x8bit
640x576x4x8bit
768x576x4x8bit
800x600x4x8bit
1024x768x4x8bit
1024x1024x4x8bit
1280x1024x4x8bit
(a) chelle logarithmique
0
2
4
6
8
10
12
14
16
18
20
22
24
26
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5
t
e
m
p
s

(
m
s
)
Donnes transfres / Mo (1 Mo = 1048576 bytes)
128x128x4x8bit
256x256x4x8bit
320x240x4x8bit
352x288x4x8bit
512x512x4x8bit
480x576x4x8bit
640x480x4x8bit
640x576x4x8bit
768x576x4x8bit
800x600x4x8bit
1024x768x4x8bit
1024x1024x4x8bit
1280x1024x4x8bit
(b) chelle linaire
FIG. 9.1 : Temps du transfert, depuis GPU vers GPP, AGP (1x, dbit thorique maximal 266 Mo/s). GPU =
NVidia GeForce 6800 LE, GPP = Intel Pentium 4 @ 2.4 GHz 512 Mo RAM
184
Jaromr BRAMBOR 9.6. ESTIMATION DE LA COMPLEXIT ET DES PERFORMANCES POUR LES GPU
0
200
400
600
800
1000
1200
1400
1600
1800
2000
2200
2400
2600
2800
3000
3200
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5
t
e
m
p
s

(
s
)
128x128x4x8bit
256x256x4x8bit
320x240x4x8bit
352x288x4x8bit
512x512x4x8bit
480x576x4x8bit
640x480x4x8bit
640x576x4x8bit
768x576x4x8bit
800x600x4x8bit
1024x768x4x8bit
1024x1024x4x8bit
1280x1024x4x8bit
(a) NVidia GeForce 6800 Ultra, taux effectif = 8x
0
200
400
600
800
1000
1200
1400
1600
1800
2000
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5
t
e
m
p
s

(
s
)
128x128x4x8bit
256x256x4x8bit
320x240x4x8bit
352x288x4x8bit
512x512x4x8bit
480x576x4x8bit
640x480x4x8bit
640x576x4x8bit
768x576x4x8bit
800x600x4x8bit
1024x768x4x8bit
1024x1024x4x8bit
1280x1024x4x8bit
(b) NVidia Quadro FX 4500, taux effectif = 13x
FIG. 9.2 : Temps du transfert estim depuis GPP vers GPU, pour PCI Express (16x) et les textures xed-point
8 bit BGRA (bas sur les donnes ofcielles de NVidia
NVi05
). GPP = AMD Athlon 64 bit 3500+, 1 Go RAM
185
Remplissage volume Windows XP / fps Linux Mandrake / fps
de rectangle trait Fentre Plein cran Fentre Plein cran
couleur constante
4 Mo 1670 2700 1422 3300
3 Mo 3836 1850 3915
couleur variante
4 Mo 1500 1031 1663
3 Mo 2326 1338 2190
4 Mo= 1024
2
48 bits, 3 Mo= 102476848 bits ; GPP = Intel Pentium 4 2.4 GHz single
thread ; GPU = NVidia GeForce 6800 LE sur AGP 4x. Rsolution dcran lors du travail avec fentre
= 12801024
TAB. 9.2 : Test comparatif de performances dafchage dun rectangle couvrant entirement la scne
rapide, son dbit thorique est de 4 Go/s dans sa version "16x", couramment prsente dans lanne 2006,
est deux fois suprieur celui de AGP 8x dans le sens GPPGPU et 16 fois suprieur dans le sens
GPUGPP.
Le bus PCI Express devait amliorer les temps du transfert, principalement dans le sens GPUGPP.
Mme si une amlioration est perceptible, limpact des transferts reste toujours important vis--vis de la
dure du traitement GPGPU que nous effectuons.
De plus, on a beau avoir un dbit thorique chiffr, les temps de transfert rels peuvent en diffrer
fortement. Le temps de transfert varie, en effet, selon la conguration de notre architecture GPP-GPU.
En se basant sur les donnes ofcielles de NVidia, nous avons modi lchelle de la courbe que lon
vient de prsenter sur la g. 9.1(b) pour pouvoir dmontrer les temps estims partir de larticle
NVi05
qui sont les plus favorables notre traitement (texture xed point de 8 bit en format BGRA) pour deux
processeurs graphiques diffrents. Sur la g. 9.2(a), nous prsentons les temps estims de transferts
GPPGPU pour le processeur graphique NVidia GeForce 6800 Ultra connect via PCI Express 16x et
do nous pouvons dduire le taux effectif de "8x". Sur la g. 9.2(b) nous prsentons les temps estims
de transferts GPPGPU pour le processeur graphique NVidia Quadro FX 4500 connect galement via
PCI Express 16x et do nous pouvons dduire le taux effectif de "13x".
9.6.2 Inuence du systme dexploitation et de lAPI
Linuence non ngligeable sur les performances nales est apporte galement par le systme dex-
ploitation laide duquel nous excutons nos programmes (dans notre cas Linux Mandrake 9.2 et Mi-
crosoft Windows XP) et, bien sr, du pilote qui excute nos commandes OpenGL ou DirectX.
En utilisant lAPI Mesa sous Linux et lAPI DirectX 9 sous Microsoft Windows XP, nous avons
effectu un test comparatif dont les rsultats sont prsents dans la tab. 9.2. Nous avons implment
deux algorithmes dafchage dun rectangle couvrant entirement la scne.
Lalgorithme plus simple, dnot couleur constante, nutilise pas linformation de couleur incorpo-
re dans les vertex, celle-ci est fournie par le programme traitant des fragments. Les rsultats de cet
algorithme nous servent comme indicateur de performance maximale atteignable de notre architecture
GPP-GPU. Dans ce cas prcis, nous effectuons le moins de travail dans le pipeline graphique. La valeur
que nous allons observer sera le nombre de trames que nous pouvons traiter par seconde (fps).
Le deuxime algorithme, dnot couleur variante, utilise linformation de couleur dans chacun des
vertex du rectangle et cette information est pour chacun des vertex diffrente. Cette conguration occupe
principalement le rastriseur et devrait nous dmontrer le changement du nombre des trames traitables
par seconde lors dinterpolation de 4 valeurs de couleur.
Puisque dans la plupart de cas, lors de notre travail avec les GPU, nous passons comme commandes
graphiques les structures ayant un nombre trs petit de triangles, les mesures exprimentales devaient
nous tester galement la validit de lhypothse que nous nous avons construite pendant ltude de la
bibliographie .
Il sagit de dmontrer exprimentalement que lAPI bas sur OpenGL gre plus efcacement len-
186
voi de commandes qui comptent peu de triangles, cet fait tant mentionn dans la prsentation de
Wloka
Wlo03
. Le test que nous effectuons ici semble convenable pour cette dmonstration. Nous y en-
voyons 1 rectangle (qui est constitu de 2 triangles), il sufrait de comparer les fps obtenus pour les deux
systmes dexploitation.
Nous remarquons que ce type de travail nest pas propre lutilisation habituelle des GPU car ces
derniers ne sont pas conus pour un travail une frquence leve dafchage dans le framebuffer mais
ils sont conus pour les algorithmes qui se prsentent par des taux des fps moindres 100, le nombre
propre la frquence de rafrachissement des trames pour la visualisation.
Les rsultats nous rvlent trois ides principales :
Il est recommander de travailler avec une application qui fonctionne en rgime plein cran (cf.
les colonnes Plein cran dans la tab. 9.2). Dans le cas oppos o nous travaillerons dans une
fentre de systme dexploitation (ou de systme de fentres dans le cas de Linux), les taux de fps
chuteraient dune manire signicative (cf. les colonnes Fentre dans la tab. 9.2).
On peut percevoir une certaine supriorit des rsultats pour Linux et le pilote du processeur pour
OpenGL en terme de fps qui sont plus grandes que celles pour Windows et DirectX. Mais nous
trouvons galement le cas contraire, notamment les valeurs de fps pour les images de 3 Mo lors
dun remplissage par la couleur variante en plein cran. Il faut souligner que les rsultats des
deux API ne sont pas excessivement diffrents et nous ne pouvons pas faire une recommandation
dutilisation dun API plutt que de lautre. De plus, ces rsultats tant fortement dpendants de la
version du pilote, ils peuvent varier fortement dune version lautre.
Le fait davoir ajout au traitement de base linterpolation des couleurs se manifeste par une dimi-
nution des fps allant dans certains cas jusqu 2 fois (Linux, Plein cran, 4 Mo). Sachant que ce
test devait dmontrer les capacits dinterpolation des valeurs (nous visons prioritairement linter-
polation des coordonnes des index de textures lors du travail avec 4 textures, sans avoir effectu
lchantillonnage), les rsultats sont plutt dcevants car lors du travail avec les algorithmes de
traitement dimages, nous allons encore ajouter aux temps qui correspondent ces fps la dure des
oprations de traitement des fragments (chantillonnage, oprations arithmtiques, etc.).
9.7 Rcapitulation
Ce petit chapitre devait nous servir introduire des techniques pour la description de la complexit
des algorithmes. Nous y avons prsent, sur un exemple pratique pour les GPP/GPPMM les phnomnes
que nous devons assumer si nous voulons passer de lexpression thorique de la complexit laide
de O() une estimation pratique du cot dun algorithme, qui est, dans notre cas, prioritairement li
lexpression du temps du calcul.
Cette estimation pratique nest pas simple et est fortement lie une architecture donne mais gale-
ment, comme nous lavons prsent dans 9.4.2, page 180, dautres facteurs qui ne sont pas a priori aussi
vident assumer, comme les dimensions relatives dune image et de la mmoire cache de larchitecture.
Lestimation pratique des performances des algorithmes pour les GPU est encore plus dlicate. Pour
pouvoir obtenir des estimations ables, on devrait prendre en compte beaucoup de paramtres. De ces
derniers, nous avons prsent en particulier le temps de transfert de donnes et la possible inuence du
systme dexploitation et de linterface de programmation (lAPI) que nous utilisons pour excuter nos
commandes graphiques. Remarquons que pour un programme donn et pour un processeur graphique
donn, les outils de dveloppement de NVidia permettent de calculer avec prcision le nombre de cycles
que les programmes pour les vertex et pour les fragments sont censs consommer. Mais il ne sagit que de
deux des units du pipeline graphique et il nexiste pas une mthode pour pr-valuer les performances
du pipeline graphique dans son entier.
Mme dans la littrature portant sur le GPGPU, nul ne prsente les estimations de la performance
pour les algorithmes pour les GPU. Cest d au caractre des donnes, dpendantes de linteraction avec
lutilisateur, qui sont traites dans la synthse dimages. Par consquent, il nest pas possible de prvoir
187
le nombre de triangles qui serait ncessaires au traitement. Il est beaucoup plus able et intressant dun
point de vue pratique deffectuer un test concret, sur un matriel donn.
Ce nest pas la situation de lanalyse dimage o, pour la plupart des traitements, le nombre de don-
nes traiter est prvisible avant lexcution. Cest justement dans le cadre de GPGPU o une estimation
plus prcise des performances dun algorithme serait la bienvenue et possible raliser. Nous laissons
cette ide comme un problme ouvert qui pourrait conduire une possible construction dun modle de
performance crdible ; dun modle partir duquel nous pourrions estimer le cot total dun algorithme
GPGPU, sans avoir besoin de faire appel aux tests exprimentaux.
188
Conclusion et perspectives
Conclusion et perspectives
Conclusion gnrale
Ides principales exposes dans la thse
Cette thse tait consacre aux algorithmes de la morphologie mathmatique qui peroivent les don-
nes en tant que ux de donnes et destins aux architectures pouvant exploiter ce paradigme du calcul.
Le but de cette thse tait constitu de plusieurs points relatifs trois ides principales : premirement, la
prsentation des architectures du calcul susceptibles dtre utilises pour le calcul morphologique bas
prix ; deuximement, lutilisation de lapproche formelle pour la description des algorithmes et troisi-
mement, le descriptif des algorithmes eux-mmes et de leurs rsultats exprimentaux.
De ce point de vue, les sujets que nous avons choisis de traiter dans cette thse sont les suivants :
Prsenter les possibilits des architectures grand public pour le traitement morphologique en ux
de donnes en exploitant leurs capacits de lexcution parallle SIMD sur les donnes paquetes
lchelle des registres (on parle galement des capacits SWAR) ; prsenter les possibilits of-
fertes par le jeu dinstructions multimdia de ces architectures et prsenter les capacits du calcul
parallle lchelle des tches et des ls dexcution qui sont en train de devenir lide porteuse
de construction des architectures grand public et pour lesquelles nous pouvons esprer de grands
changements dans les prochaines annes.
Proposer une manire formelle pour la description gnralise des algorithmes lis une architec-
ture.
Dmontrer formellement, en dnissant les skeletons algorithmiques, les principes de la construc-
tion des algorithmes pour la morphologie mathmatique et exploiter le paradigme de traitement en
ux en lappliquant sur les oprations morphologiques couramment utilises (dilatation / rosion,
oprations godsiques, fonction distance, nivellements).
Construire les algorithmes morphologiques spciques pour les architectures multimdia avec les
capacits SIMD.
Explorer lide originale dexcution par macro blocs pour la construction des algorithmes mor-
phologiques, y compris lide de travail SIMD, lide des superpixels et des propagations SIMD
dans limage en employant la transposition directe sur un macro bloc pour assurer lexcution dans
les directions perpendiculaires laxe de stockage des donnes dans la mmoire.
Dmontrer les possibilits du calcul morphologique en ux de donnes sur les processeurs gra-
phiques et proposer une description formelle de tels algorithmes pour ces processeurs.
Effectuer des expriences sur diverses implmentations dalgorithmes de la morphologie math-
matique an dvaluer les temps dexcution et leur comportement sur des images de tailles va-
ries.
Premire partie de la thse
Le travail que nous avons expos a t divis en deux parties. Dans la premire, nous avons prsent
les architectures cibles (chapitre 3) de cette thse et les possibilits matrielles dexcution quelles
191
offrent. Parmi les architectures qui peuvent tre utilises pour le calcul avec les ux de donns, nous nous
sommes intresss en particulier aux processeurs du calcul gnral grand public (GPP) avec les capacits
multimdia, surtout pour leur position actuelle sur le march qui les rend trs intressants du point de vue
applicatif. Malgr le fait que nous avons vis ce type darchitectures pour nos algorithmes et que nous
avons test ces algorithmes sur un processeur appartenant ce type darchitectures, le fonctionnement
de ces algorithmes nest pas li une architecture du calcul parallle ou squentiel quelconque et leurs
principes peuvent tre rutiliss, notamment sur les architectures qui ont t nativement conues pour le
traitement des ux de donnes
Un autre groupe darchitectures que nous avons pu explorer et dont nous prsentons la description
dans cette partie est constitu des processeurs graphiques (GPU). Ces processeurs ntait pas destins,
dans leur fonction originale, au calcul de lanalyse dimage mais leur synthse. Vu les possibilits de
programmation quils offrent nos jours et qui les rapprochent de plus en plus des applications gnrales
qui ont besoin de la paralllisation massive (ce qui est le cas pour les algorithmes de la morphologie ma-
thmatique), nous avons explor galement la piste de leur possible utilisation pour les implmentations
des oprations de base de la morphologie.
Cest galement dans la premire partie (chapitre 4) de cette thse que nous avons introduit le forma-
lisme fonctionnel, reprsent par le Lambda calcul, en tant que moyen de spcication que nous avons
adopt pour la description des algorithmes. Nous avons choisi comme outil de travail le langage fonc-
tionnel Haskell implmentant la thorie du lambda calcul. Il sest avr particulirement utile pour la
description des procds traitant les ux de donnes. Nous avons pu facilement exprimer le traitement
des ux comme traitement des listes du Haskell et exprimer galement les kernels dexcution, propres
au paradigme stream, en tant que fonctions appliques aux lments de ces listes.
Pour pouvoir exprimer le travail de la morphologie traitant le voisinage en termes de Lambda calcul,
nous avons dni, pour formaliser le traitement sur les architectures GPP, un certain nombre de fonctions
primitives, incluant les fonctions de passage dun array un stream de donnes, les fonctions dchan-
tillonnage des pixels pour pouvoir extraire les pixels dsigns par llment structurant et les fonctions
qui expriment le kernel dexcution de lopration morphologique lchelle dun pixel. Nous avons
utilis la description des algorithmes gnraux en tant que skeletons algorithmiques, dnis pour le type
polymorphe . Ce fait sest rvl utile quand nous sommes pass, partir du traitement sur le voisinage
des donnes scalaires, au traitement du voisinage des donnes paquetes contenant plusieurs lments
de base et exprims en Haskell par un autre type, plus spcique, qui dcrivait les vecteurs paquets
PVec I .
Pour pouvoir effectuer le mme travail sur les processeurs graphiques, nous avons construit un mo-
dle formel du fonctionnement du pipeline graphique. La construction dun algorithme qui est excut
sur les GPU va se poursuivre comme la spcication des fonctions correspondant aux programmes ma-
niant les divers blocs du pipeline graphique.
Lapport de ce formalisme a t particulirement apprci lors des vrications de fonctionnement
des descriptions prsentes dans cette thse car tous les algorithmes que nous dcrivons dans le Lambda
calcul sont galement les fonctions du Haskell. Ainsi, nous avons pu faire appel au compilateur du
Haskell et vrier leur bonne syntaxe. De plus, il a t possible de tester, pour les algorithmes concrets,
leur fonctionnement sur les donnes synthtiques en excutant le programme du Haskell.
Deuxime partie de la thse
La deuxime partie de cette thse a t consacre la description des diffrentes faons de construire
des algorithmes morphologiques pour les architectures orientes ux. Nous avons explor, dans le cha-
pitre 5, les principes qui entrent en jeu lors de la construction des algorithmes travaillant sur le voisinage,
qui ne dpendent pas du sens du parcours et dont lexcution peut tre facilement paralllise. Dans le
mme chapitre, nous avons prsent les algorithmes pour les processeurs graphiques. Les tests compara-
tifs pour les oprations de base de la morphologie mathmatique qui mettaient en relation des implmen-
192
Jaromr BRAMBOR
tations sur les GPU et diverses implmentations sur les GPP, y compris les algorithmes exploitant les
capacits SIMD, ont rvl que pour les images de grande taille qui dpassent la capacit de la mmoire
cache de notre architecture GPP, les processeurs graphiques montrent les meilleures performances.
Dans le chapitre suivant, le chapitre 6, nous avons prsent les algorithmes rapides pour les GPP
qui exploitent les capacits SIMD de larchitecture multimdia et qui sont destins au changement de
laxe de stockage des donnes paquetes. Nous avons prsent les algorithmes qui utilisent les fonc-
tions shufe, prsentes dans tous les jeux dinstructions multimdia, qui effectuent lopration choisie
de changement de stockage dans Nlog
2
N applications des fonctions shufe. Quatre algorithmes qui ef-
fectuent le changement souhait et dont le principe de fonctionnement est trs proche ont t prsents :
la transposition par diagonale / anti-diagonale, la rotation de +
2
et de
2
. Nous avons soulign que
dans les applications pratiques il sagira le plus souvent de la transposition par diagonale qui assurera le
changement de stockage des donnes paquetes.
Le chapitre 7 a t consacr aux algorithmes qui dpendent du sens de parcours prdni de limage.
Nous avons prsent la particularit de ces parcours lors du travail avec les donnes paquetes qui exigent
une approche diffrente pour la construction de tels algorithmes que celle utilise habituellement pour les
lments de base de limage. Nous avons notamment explor lide de quatre parcours directionnels lors
du travail avec llment structurant de la forme du disque unit sur la grille carre en 4-voisinage. Pour
ladapter au travail avec les vecteurs paquets, nous faisons appel la transposition par diagonale que
nous utilisons comme moyen de changement de laxe de stockage de donnes an daccder aux donnes
dans le sens perpendiculaire celui de leur stockage dans la mmoire. Nous avons galement explor
lide deffectuer ce changement de stockage lchelle des macro blocs, vitant ainsi les oprations
de transfert de donnes entre le processeur et la mmoire lors du stockage des rsultats intermdiaires.
Les exemples des oprations qui utilisent la structure des algorithmes ont t dcrits dans ce chapitre.
Nous avons prsent la fonction distance en tant qualgorithme non-godsique et dont le rsultat est
connu aprs une application de lalgorithme de propagation. Nous avons prsent galement les nivelle-
ments, qui sont les ltres morphologiques et qui ont le caractre godsique, que lon emploie dans les
applications de ltrage des images prservant les contours des objets.
Dans le chapitre 8 qui tait consacr aux algorithmes de la dilatation / lrosion par les lments
structurants de la forme des segments, nous avons explor les stratgies de la paralllisation lchelle
des donnes paquetes. Pour la construction dun algorithme SIMD qui employait lide de lalgorithme
de van Herk-Gil-Werman, nous avons rutilis toutes les ides prsentes dans les chapitres prcdents
ddis aux algorithmes : la propagation de la valeur lintrieur des macro blocs, lapplication de lal-
gorithme sur les macro blocs qui ne dpend pas dun sens de parcours particulier et la transposition de
limage que nous avons utilise pour changer laxe de stockage des donnes lors de lapplication de
llment structurant qui ncessite laccs aux donnes dans le sens perpendiculaire celui de laxe de
stockage de donnes dans la mmoire.
Le chapitre 9 a t ddi lexplication de la problmatique de lexpression de la complexit dun
algorithme pour des ns pratiques. Nous y avons dmontr que lexpression de la complexit relative
au temps du calcul par le O, utilis le plus souvent dans la littrature, nest pas approprie dans les
conditions pratiques o nous estimons principalement le temps du calcul et o les cots des accs la
mmoire et les cots des oprations arithmtiques varient. Nous avons propos dexprimer la complexit
dune manire plus explicite qui mentionne ces diffrents cots expressment et qui est exprime par
la fonction . Dans ce mme chapitre, nous montrons galement que la problmatique de lestimation
du temps du calcul pour les GPU nest pas aussi directe car il sagit dune architecture distribue. Nous
discutons les temps des transferts des donnes entre les GPP et les GPU et linuence de lAPI.
Contribution de cette thse
Lapport principal de cette thse est la prsentation dun sujet important du point de vue pratique et
lexploration des capacits SIMDdune architecture multimdia pour assurer lexcution des algorithmes
193
morphologiques travaillant sur le voisinage peut raccourcir le temps du calcul. Nous avons explor ga-
lement lutilisation dun autre type darchitectures intressant de ce point de vue les processeurs gra-
phiques et nous avons dmontr sur les rsultats exprimentaux quils sont, prsent, assez perfor-
mants pour concurrencer les GPP an dassurer lexcution des oprations morphologiques. Lapport
secondaire de cette thse est celui du formalisme fonctionnel que nous avons adopt pour la description
de nos algorithmes travaillant sur les ux de donnes.
Perspectives et axes de recherche possibles
Les travaux effectus pendant la prparation de cette thse ont voqu certaines ides ou mme des
problmatiques qui nont pas pu tre explores en entier ou qui nont pas trouv de vraie place dans
ce manuscrit. Nous les mentionnons dans la section des perspectives comme les sujets dune possible
prochaine exploration car nous trouvons quils sont intressants. La valorisation des algorithmes dans les
architectures ddies est galement envisager.
La premire ide, qui est tout--fait intressante et qui se joint aux ides mentionnes implicitement
dans cette thse, est lutilisation des processeurs plusieurs curs pour parallliser le calcul morpholo-
giques et les architectures plusieurs ls dexcution, logiques ou physiques. tant donn que nos efforts
dexprimentation se sont concentrs sur les tests comparatifs effectus sur les processeurs avec un seul
l dexcution, il serait envisageable, et mme trs important pour les applications pratiques, deffectuer
une tude comparative qui montrerait les gains de performance lors dexcution des algorithmes dcrits
dans cette thse sur les architectures parallles qui peuvent exploiter le paradigme stream de traitement
des donnes ; cela lchelle des tches par le paradigme Divise et conquiers mais galement lchelle
des lments des streams par la rplication fonctionnelle (o nous remplaons la fonction map du Haskell
par la fonction farm).
Une autre ide est relative aux implmentations des algorithmes sur les architectures spcialises,
telles que les architectures nativement construites pour lexcution en stream (e.g. le processeur Imagine)
ou les architectures ddies la morphologie mathmatique (e.g. les architectures prototypes laide
des FPGA). Cette ide est considrer autant de plus vu le droulement des vnements les plus rcents
o lAMD vient dannoncer
Pri06
lintroduction de la technologie ouvrant pour les FPGA un accs direct
dans larchitecture des processeurs GPPMM. Cette technologie, nomme Torrenza et destine pour la
gamme des processeurs AMD Opteron, devrait proter de la liaison rapide la mmoire centrale et au
processeur lui-mme laissant ainsi un grand terrain libre pour les applications ddies, y compris celles
de la morphologie mathmatique auxquelles nous nous intressons le plus.
La construction des procds du calcul en ux de donnes qui utilisent la propagation base de
rgles et dpendant du contenu de limage est galement une ide explorer. Cette problmatique est
souvent traite par les les dattente ou les les dattente hirarchiques et est galement intressante ;
surtout si nous voulons explorer lexcution en stream et proter de la paralllisation par la rplication
fonctionnelle. Notons que certains principes dactivation des pixels en parallle qui sont utiliss lors du
traitement des les dattente sont dcrits dans la thse de Dominique Noguet
Nog98
.
Pouvoir excuter les algorithmes base de les dattente sur les processeurs graphiques est galement
un sujet important tudier. Ce type de traitement est, ltat actuel des technologies des GPU, difcile
effectuer car malgr le fait que les GPU peuvent sortir en mme temps plusieurs valeurs correspondant
lactivation / non-activation des voisins dun pixel, le placement des pixels traiter au bon endroit de
la le dattente nest pas trivial et demanderait plusieurs itrations de traitement du pipeline graphique.
Ce qui se serait traduit par laugmentation du temps du calcul ncessaire et ce qui, par consquent,
dfavoriserait fortement les GPU dans un tel scnario dutilisation. Les changements de la structure
des processeurs graphiques nous semblent cruciaux pour pouvoir effectuer ce type de traitement an
dobtenir des performances intressantes.
Dans la partie introductive (cf. la section 3.4.6, page 55), nous avons mentionn Brook loutil de
traitement des donnes en stream utilisant les GPU comme support du calcul. Daprs nos expriences, il
194
Jaromr BRAMBOR
semble inadapt, dans sa forme actuelle, au traitement des donnes par les mthodes de la morphologie
mathmatique. On pourrait envisager damliorer cet outil pour quil soit possible dutiliser le type de
nombres entiers de 8 bits, couramment utilis dans le traitement dimages, et y incorporer les mthodes
de traitement sur les GPU que nous avons prsentes dans cette thse.
Lapproche formelle par les expressions du Lambda calcul que nous avons choisie pour la description
de nos algorithmes pourrait tre transpose lide de la spcication formelle constructive an de
lutiliser non seulement pour la description mais galement pour lautocration dun vritable programme
en terme dinstructions pour une architecture quelconque. La thorie des types
Rys05
exploite cette ide
et elle constitue un systme qui est la fois le systme de la logique mathmatique et du langage de
programmation o laction de prouver la validit dun thorme est quivalente la construction dun
programme partir de sa spcication formelle. Les reprsentants des outils pour prouver ces thormes
sont les prouveurs des thormes tels quAlf, Coq et autres, cf. larticle
Nog02
qui compare leurs capacits.
La dernire ide que nous voquons comme un axe possible de recherche applique et qui sera,
nous le croyons, srement explor dans lavenir proche consiste en ltude de lutilisation possible des
consoles de jeux pour le calcul morphologique et, plus gnralement, de lanalyse des images. En effet,
les consoles de jeux combinent dans une seule architecture ddie au calcul particulier des jeux vido
une puissante unit (paralllise) de calcul gnral et une unit puissante de calcul ddie la synthse
des images. Cette combinaison offre de belles possibilits dappliquer toutes les ides dcrites dans cette
thse, non seulement celles consacres aux processeurs gnraux, mais galement celles relatives aux
processeurs graphiques.
195
Annexe
Annexe A
Fonctions pour assurer lexcution en cycles
Il est propre la programmation imprative dutiliser les cycles et de les grer par les variables
sauvegardant ltat pour exprimer litration actuelle. En revanche, lapproche fonctionnelle la pro-
grammation ne travaille pas avec linformation sur ltat du programme et les cycles ne sont pas dnis
a priori. Lexcution itrative se poursuit par les appels rcursifs de la fonction qui value elle-mme si
la rcursion doit prendre n ou si elle doit se poursuivre.
Haskell fournit les fonctions de base pour assurer lexcution itrative mais le choix nal de la ma-
nire exacte de cette excution est dnir par lutilisateur.
La fonction iterate, standard du Haskell assure lapplication itrative de la fonction | sur x. Elle cre
une liste innie qui contient comme premier lment la variable dentre x, comme deuxime le rsultat
de la premire itration, puis de la deuxime etc. :
iterate :: ( ) [ ]
iterate | x = x : iterate | (| x)
Par exemple, la fonction
iterate ( +1) 1
a pour rsultat la liste innie [1, 2, 3, 4, 5, .....]. Pour obtenir un nombre dni ditrations partir de
cette liste, nous utilisons la fonction take, standard du Haskell, qui retourne la liste nie compose de n
premiers lments de la liste (x : x) :
take :: Int [ ] [ ]
take 0 _ = [ ]
take _ [ ] = [ ]
take n (x :x)
| n , 0 = x : take (n1) x
take _ _ = error "take"
Pour obtenir le rsultat de lexcution itrative, il suft de prendre le dernier lment de la liste cre
pralablement par les fonctions iterate et take. La fonction last, standard du Haskell, assure cette possi-
bilit :
last :: [ ]
last [ x ] = x
last (_:x) = last x
Ainsi, lexcution de n itrations de la fonction | sur les donnes x est assure par lexpression
suivante :
last (take (n+1) ) ( iterate | ) $x
199
Annexe B
Dnitions des fonctions utilitaires en Haskell
Fonctions c3e et c4e de cration des vecteurs de couleur
La fonction c3e cre partir dun triplet dlments de couleur CElmnt un vecteur de couleur compos
C en utilisant la fonction pvec, cf. 4.3.1.3 page 64 :
c3e :: (CElmnt , CElmnt , CElmnt) C
c3e ( t
:
, t
z
, t
) = pvec (1,3) [ (1, t

:
) , (2, t
z
) , (3, t
) ]
Suivant la mme logique, la fonction c4e cre partir dun quadruplet dlments de couleur CElmnt un
vecteur de couleur compos C :
c4e :: (CElmnt , CElmnt , CElmnt , CElmnt) C
c4e ( t
:
, t
z
, t
, t
) = array (1,4) [ (1, t

:
) , (2, t
z
) , (3, t
) , (4, t
) ]
Fonctions p2D et p3D de cration des points
La fonction p2D cre un point de 2D partir dun tuple de coordonnes :
p2D :: ( Pos , Pos ) P
p2D ( x
:
, x
z
) = pvec (1,2) [ (1, x
:
) , (2, x
z
) ]
La fonction p3D cre un point de 3D partir dun triplet de coordonnes :
p3D :: ( Pos , Pos , Pos ) P
p3D ( x
:
, x
z
, x
) = pvec (1,3) [ (1, x

:
) , (2, x
z
) , (3, x
) ]
Fonctions mkTX, getArFromTX et getTXBFromTX de manipulation des textures
La fonction mkTX cre une texture partir de ses composantes. La fonction (, ) prend deux paramtres
et cre un tuple.
mkTX :: Ar ( I , I ) C [ TXB] TX
mkTX ut xI = ( , ) ut xI
La fonction getArFromTX retourne larray de couleur partir de la texture TX :
getArFromTX :: TX Ar ( I , I ) C
getArFromTX (x , _) = x
La fonction getTXBFromTX retourne la valeur de bord TXB dune texture TX :
getTXBFromTX :: TX TXB
getTXBFromTX (_, x) = x ! ! 0
201
Fonction mkV de cration dun vertex
La fonction mkV cre un vertex partir de ses composantes. La fonction (, , ) prend trois paramtres et
cre un triplet.
mkV :: P [ ( CI , C ) ] [ ( TXI , TXP) ] V
mkV p t xp = ( ,, ) p t xp
Fonction mkF de cration dun fragment
La fonction mkF cre un fragment partir de ses composantes. La fonction (, , , ) prend quatre paramtres
et cre un quadruplet.
mkF :: P Dpth [ ( CI , C ) ] [ ( TXI , TXP) ] F
mkF p J t xp = ( ,,, ) p J t xp
Fonction mkEnv de cration de lenvironnement du pipeline graphique
La fonction mkEnv cre, partir dun framebuffer FB et dune liste des textures TX , lenvironnement
du travail Env du GPU :
mkEnv :: FB [ TX] Env
mkEnv |I x = ( , ) |I x
Fonctions getTXs, getFB de manipulation de lenvironnement
La fonction getTXs retourne la liste des textures [TX] partir de lenvironnement Env du pipeline gra-
phique :
getTXs :: Env [ TX]
getTXs (_, x) = x
La fonction getFB retourne le framebuffer FB partir de lenvironnement Env :
getFB :: Env FB
getFB ( |I , _) = |I
Dimension des arrays, fonctions dimsAr1D et dimsAr2D
La fonction dimsAr1D retourne la taille dun vecteur PVec ou dun array 1D :
dimsAr1D :: Ar I I
dimsAr1D ut = qp+1
where (p,q) = bounds $ut ;
La fonction dimsAr2D retourne un tuple correspondant aux dimensions dun array 2D dans la premire
et deuxime coordonne, respectivement :
dimsAr2D :: Ar ( I , I ) ( I , I )
dimsAr2D ut = (tp+1, q+1)
where ( (p,q) , (t , ) ) = bounds $ut ;
Tests SIMD et dplacement conditionnel SIMD
Pour pouvoir assurer lvaluation des expressions conditionnelles en SIMD, nous dnissons la fonc-
tion de test testSIMD qui applique la fonction tnJ du test logique entre chaque lment des deux vec-
teurs paquets pv
1
et pv
2
. Le rsultat de cette fonction est un masque reprsent par un vecteur paquet
dont les lments sont les valeurs boolennes et qui contiennent soit la valeur True, soit la valeur False
dans le cas o le test a russi ou chou, respectivement.
202
Jaromr BRAMBOR
testSIMD :: PVec I ( Bool) PVec I PVec I Bool
testSIMD pv
1
tnJ pv
2
1
) (map2 tnJ (elems$pv
1
) (elems$pv
2
) )
La fonction de dplacement conditionnel cndmoveSIMD va utiliser un masque mI pour constituer un
vecteur paquet partir de deux vecteurs paquets dentre pv
1
et pv
2
. Selon les valeurs du masque True
ou False, les lments du pv
1
ou pv
2
, respectivement, sont copis dans le vecteur rsultant.
cndmoveSIMD :: PVec I Bool PVec I PVec I PVec I
cndmoveSIMD mI pv
1
pv
2
1
) (map2 ( mI x if mI then x else )
(elems$pv
1
)
(elems$pv
2
)
)
Fonction mapping travaillant avec plusieurs valeurs dentre
La fonction map2 effectue le mapping dune fonction prenant deux arguments. Son fonctionnement
est identique celui de la fonction zipWith du Haskell :
map2 = zipWith
203
Liste des termes et des abrviations
1D 1 Dimension
2D 2 Dimensions
3D 3 Dimensions
AGP Advanced Graphics Port
ALU Aritmetical and Logical Unit, unit arithmtique et logique
API Application Programming Interface, interface de programmation dapplications
ARB OpenGL Architectural Review Board
ASIC Application Specic Integrated Circuit, circuit intgr spcique lapplication
blending Le processus de combinaison de deux ou plusieurs choses an de les mixer entirement
CCD Charge Coupled Device
CISC Complex Instruction Set Computer/Computing, ordinateur/calcul jeu dinstructions rduit
CMOS Complementary Metal Oxide Semi-conductor
CMP Chip-level Multiprocessing, multiprocessing au niveau de la puce
CMT Chip-level Multithreading, multithreading au niveau de la puce
CPU Central Processing Unit, unit centrale de calcul
DMIPS Dhrystone MIPS, indicateur de performance driv des rsultats du test Dhrystone
Wik06d
FLOPS Floating-Point Operations Per Second, q.v.
Wik06f
FPGA Field Programmable Gate Array, circuit intgr programmable
fps Frames per second, trames par seconde
fragment structure de donnes dun GPU, contient des coordonns 2D de la position sur lcran, la coordonne z et linfor-
mation sur la(les) couleur(s)
GFLOPS Giga Floating-Point Operations Per Second, = 1024 MFLOPS = 1048576 FLOPS
GPGPU General Processing on Graphics Processing Units
GPP General Purpose Processor, processeur usage gnral
GPPMM General Purpose Processor with MultiMedia extensions, processeur usage gnral avec les fonctionnalits mul-
timdia
GPU Graphique Processing Unit, unit du calcul graphique, processeur graphique
HAL Hardware Abstraction Layer, couche dabstraction du matriel
HDTV High Denition TeleVision, tlvision haute dnition
HGW Lalgorithme de van Herk-Gil-Werman
PC Personal Computer, ordinateur personnel
ko Kilo-Octet, 1 ko = 1024 octets = 1024*8 bits
LPE Ligne de Partage des Eaux
nD n-Dimensions
RISC Reduces Instruction Set Computer/Computing, ordinateur/calcul jeu dinstructions rduit
SIMD Single Instruction (stream), Multiple Data (stream)
SISD Single Instruction (stream), Single Data (stream)
SKIZ SKeleton by Inuence Zones, Squelette par zones dinuence, e.g.
Beu90
SPMD Single Programme, Multiple Data (stream)
205
SMT Simultaneous MultiThreading, multithreading simultan
SWAR Single instruction multiple data Within A Register
texel TEXture ELement, structure de donnes dun GPU, contient des information dun lment de texture
MFLOPS Mega Floating-Point Operations Per Second, = 1024 FLOPS
MIMD Multiple Instruction (stream), Multiple Data (stream)
MIPS Million (integer) Instructions Per Second, q.v.
Wik06h
MISD Multiple Instruction (stream), Single Data (stream)
Mo Mga-Octet, 1 Mo = 1024 ko = 1048576 octets = 1048576*8 bits
MT MultiThreading
vertex structure de donnes dun GPU, contient des coordonnes dun sommet dune forme gomtrique et ventuelle-
ment dautres informations (couleurs, position dans la texture, etc.)
VLIW Very Long Instruction Word, architecture mot dinstruction largi
VMT Virtual MultiThreading, multithreading virtuel
voxel lment dun volume discrtis
206
Liste des gures
1.1 volution du nombre des transistors par produit Intel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2 volution de nombre de transistors des processeurs graphiques NVidia . . . . . . . . . . . . . . . . . . . . . 22
1.3 volution des performances des processeurs graphiques NVidia . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Les types darchitectures selon la taxonomie de Flynn. Lgende : UC - unit centrale, P - processeur, M -
mmoire, MI - mmoire dinstructions, MD - mmoire de donnes . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Excution dans le pipeline du processeur SH-5 se poursuit de gauche droite. Lgende : F1, F2 (fetch) - phases
de la mise en pipeline dune instruction ; D - dcodage de linstruction ; E1, E2, E3 (execute) - jusqu 3 phases
dexcution, fonction exacte (mmoire, calcul en entiers, en virgule ottante) dpend de linstruction, WB
(writeback) - criture des rsultats dans le registre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 La taxonomie de Duncan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4 Exemples des congurations et de la topologie dinterconnexions des architectures systoliques. Le rseau din-
terconnexions est dcrit par les ches paisses, les entres et les sorties vers la mmoire sont dcrites par les
ches nes. Lgende : E - lment du calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Exemple de fonctionnement dune architecture vague. Lors des trois itrations dcrites, diffrents lments
(E) sont activs et effectuent le calcul. Lactivation est illustre par une bordure paisse. . . . . . . . . . . . . 35
3.6 Exemple dun graphe dexcution dun algorithme de ltrage morphologique qui utilise les nivellements. Les
donnes transmises par le rseau dinterconnexions sont les images entires. . . . . . . . . . . . . . . . . . . 36
3.7 tat du pipeline du processeur SH-5 lors de lexcution dans le cas de donnes non prsentes dans la mmoire
cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.8 Listing dun programme pour le processeur ST200. Lexcution se poursuit par des blocs encadrs, ici par 4
instructions la fois, chacun des blocs est excut durant 1 cycle dhorloge. . . . . . . . . . . . . . . . . . . 40
3.9 Calcul sur un stream de donnes, D - donne, E
i
- unit excutive i . . . . . . . . . . . . . . . . . . . . . . . 44
3.10 Exemple dun kernel dapplication. La fonction f est applique tous les lments du stream. D - donne, K
M
- kernel dapplication, f - fonction appliquer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.11 Le kernel de rduction cre un stream plus troit partir dun stream plus large. D - donne, K
R
- kernel de
rduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.12 Exemple de fonctionnement dun kernel de ltrage. la sortie, les valeurs ngatives sont limines du stream.
D - donne, K
F
- kernel de ltrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.13 Schma de larchitecture von Neumann avec une mmoire cache incorpore dans lunit centrale, CPU - bloc
dunit centrale, MEM - bloc de la mmoire, BUS - bus assurant la liaison de lunit centrale la mmoire . . 46
3.14 Excution de plusieurs processus sur les architectures diffrentes (selon Stallings
Sta06
) . . . . . . . . . . . . . 48
3.15 Architecture hyper-threading, CPU - bloc dunit centrale, MEM - bloc de la mmoire, BUS - bus liant lunit
centrale avec la mmoire, LP
- processeur logique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.16 Architecture hyper-threading avec deux curs, CPU
- bloc dunit centrale, MEM - bloc de la mmoire, BUS

- bus liant lunit centrale avec la mmoire, LP
- processeur logique . . . . . . . . . . . . . . . . . . . . . . 49
3.17 Calcul sur un stream en utilisant les ls dexcution et lapproche Divide ans Conquer, T
- thread, DIV - phase

de division du stream, CQR - phase conquer, collecte des rsultats, D - donne, f - fonction du kernel . . . . . 50
3.18 Schma des blocs du pipeline graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1 Structure du type de donnes paquetes iu8vec8 (notation MorphoMedia
Bra05
) qui est compose de 8 lments
du type iu8 (integer unsigned 8 bit) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2 Skeleton algorithmique pipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3 Dcoupage dun array lors de sa transformation un array paquet, nombre dlments dans un lment paquet
n = 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.4 Exemple de vectorisation dun array 2D pour diffrentes versions de dcoupage et la taille du vecteur paquet
n = 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.5 Passage dun array un ux de donnes est effectu dans la logique des kernels dexcution . . . . . . . . . 71
207
4.6 Choix du parcours de limage pour un array de 1D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.7 Choix du parcours de limage pour un array de 2D 3 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.8 Dcomposition dun array aux superpixels rectangulaires de mmes dimensions . . . . . . . . . . . . . . . . 74
4.9 Exemple de travail avec les streams des superpixels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.10 Grilles utilises dans la morphologie mathmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.11 Voisinage dnit sur une grille hexagonale avec 6-connexit (dcale par lignes) et sa transposition une grille
carr avec 6-connexit (dcale par lignes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.12 Voisinage dni sur une grille hexagonale avec 6-connexit (dcale par colonnes), deuxime type et sa trans-
position une grille carr avec 6-connexit (dcale par colonnes) . . . . . . . . . . . . . . . . . . . . . . . 87
4.13 Lutilisation des lments structurants dans les oprations morphologiques et les listes des vecteurs de dplace-
ment lors du travail avec les kernels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.14 Illustration du fonctionnement de la fonction extract pour les vecteurs paquets de 8 lments et la valeur do| |
gale 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.15 Extraction des voisins partir dun type vector paquet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5.1 Graphe de ux exprimant le fonctionnement du skeleton algorithmique ngbAlgo . . . . . . . . . . . . . . . . 100
5.2 Identication de lintrieur du domaine de limage par lrosion morphologique, les rsultats pour llment
structurant et son bounding box employ comme lment structurant sont identiques . . . . . . . . . . . . . 103
5.3 Division dun array la zone de lintrieur et la zone du bord . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.4 Dcomposition du traitement de limage en traitement de bord et en traitement de la zone intrieure . . . . . 104
5.5 Graphe de ux exprimant le fonctionnement du skeleton algorithmique ngbAlgoIB . . . . . . . . . . . . . . 104
5.6 Dcomposition du traitement de limage plusieurs zones dans lesquelles les traitements distincts peuvent tre
effectus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.7 Exemple de la modication de llment structurant lors du traitement dun pixel du coin de limage convenable
aux dilatations / rosions o une seule valeur de bord est assume. . . . . . . . . . . . . . . . . . . . . . . . 106
5.8 Graphe de ux exprimant le fonctionnement du skeleton algorithmique ngbAlgoGen de traitement gnral de
voisinage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.9 Fonctionnement du kernel traitant un superpixel en 8-voisinage . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.10 Fonctionnement du kernel traitant un superpixel en 4-voisinage . . . . . . . . . . . . . . . . . . . . . . . . 111
5.11 Fonctionnement du kernel traitant un superpixel en 6-voisinage . . . . . . . . . . . . . . . . . . . . . . . . 112
5.12 Fonctionnement du kernel traitant un superpixel SIMD en 8-voisinage . . . . . . . . . . . . . . . . . . . . . 114
5.13 Fonctionnement du skeleton algorithmique ngbGAlgoGen de traitement du voisinage avec le masque dans le
cas spcial o nous ne fractionnons pas limage aux diffrentes zones . . . . . . . . . . . . . . . . . . . . . 116
5.14 Utilisation des oprations de Minkowski sur les GPU pour le calcul morphologique. Les rectangles rendre
sont dcals selon les vecteurs de llment structurant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.15 Utilisation dchantillonnage de la texture dans lunit de traitement des fragment pour lextraction du voisinage 121
5.16 Comparaison des temps dexcution de la dilatation pour diffrents logiciels et diffrentes implmentations, sur
les GPP/GPPMM (Intel Pentium 4 2,4 GHz ; 512 ko L2 ; classe 0-F-2-4-1E) et les GPU (NVidia GeForce FX
6800 ; AGP 4x 375 MHz). Les temps pour les GPU nincluent pas les transferts. . . . . . . . . . . . . . . . 125
6.1 Dcoupage dun array 3 3 macro blocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.2 Transpositions et rotations dun array utilisant lapproche macro blocs . . . . . . . . . . . . . . . . . . . . . 130
6.3 La gamme des fonctions shufe pour les vecteurs paquets de 8 lments . . . . . . . . . . . . . . . . . . . 134
6.4 Transposition par diagonale SIMD par shufes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
6.5 Illustration du fonctionnement de la fonction tr2DDiag8x8bf1 . . . . . . . . . . . . . . . . . . . . . . . . . 136
6.7 La transposition dun array dont les dimensions ne sont pas un multiple de la taille dun registre multimdia de
64 bits ; TD = macro bloc transpos par la diagonale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.6 Code de la transposition par diagonale dun macro bloc 8 8 en langage C utilisant loutil de dveloppement
multiplateforme MorphoMedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.8 Code de la transposition par diagonale dun macro bloc 8 8 crit manuellement en langage C en utilisant le
jeu dinstructions 128 bits Intel SSE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
6.9 Rsultats de diverses implmentations de la transposition par diagonale pour diffrentes tailles dimages . . . 144
7.1 Dcomposition du kernel en deux parties et en deux parcours de limage lors de lvaluation des fonctions
distance chamfer. Lexemple dlment structurant pour le 4-voisinage et la grille carre. . . . . . . . . . . . 148
7.2 Dcomposition du kernel en quatre parties et en quatre parcours de limage. Lexemple dlment structurant
pour le 4-voisinage et la grille carre. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
7.3 Remplacement de la propagation SIMD en direction parallle au sens du stockage par les transpositions par
diagonale de larray et par lapplication de la propagation en sens perpendiculaire laxe de vectorisation.
Lexemple dlment structurant pour la grille carre et le 4-voisinage. . . . . . . . . . . . . . . . . . . . . . 150
7.4 Fonctionnement du skeleton applico-rductif mfoldl. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
7.5 Fonctionnement du skeleton applico-rductif mfoldl1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
208
Jaromr BRAMBOR Liste des gures
7.6 Initialisation des images avant lexcution de lalgorithme de la fonction distance. . . . . . . . . . . . . . . . 154
7.7 Nivellements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
7.8 Calcul des nivellements en tant que combinaison des sur-nivellements et les sous-nivellements . . . . . . . . 156
7.9 Les images dentre aux fonctions de sur- et sous-nivellements et lexemple de leur contenu. . . . . . . . . . 157
7.10 La chane de traitement dun macro bloc o la premire propagation est suivie directement par la transposition
par diagonale et par la deuxime propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
7.11 Propagation lchelle des macro blocs lors du calcul avec plusieurs units excutives. Une des valeurs inter-
mdiaires est stocke localement dans lunit, la deuxime est transmise par le rseau dinterconnexion lunit
suivante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
7.12 Rsultats exprimentaux des algorithmes dpendant du sens prdni du parcours de limage . . . . . . . . . 161
7.13 Application des nivellements au ltrage des images conditionn par un masque, dimensions de limages 382
288, nivellements effectus sur la luminance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
8.1 Exemples des lments structurants ayant la forme dun segment . . . . . . . . . . . . . . . . . . . . . . . . 165
8.2 Dcomposition dun lment structurant sur la grille carre . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
8.3 Schma de fonctionnement de lalgorithme de van Herk-Gil-Werman . . . . . . . . . . . . . . . . . . . . . . 168
8.4 Phases p
1
et p
2
de propagation des valeurs de lalgorithme de van Herk-Gil-Werman . . . . . . . . . . . . . 169
8.5 Schma de fonctionnement de lalgorithme de van Herk, phase p
3
. . . . . . . . . . . . . . . . . . . . . . . 170
8.6 Exemple de la fusion des valeurs des buffers ^ et B lors de la phase p
3
pour un pixel dans la zone intrieure de
limage et pour les pixels dans les zones touchant les bords de limage . . . . . . . . . . . . . . . . . . . . . 171
8.7 Les temps du calcul des implmentations de la dilatation / rosion par un segment pour une image 768576
8 bits = 432 ko . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
9.1 Temps du transfert, depuis GPU vers GPP, AGP (1x, dbit thorique maximal 266 Mo/s). GPU = NVidia
GeForce 6800 LE, GPP = Intel Pentium 4 @ 2.4 GHz 512 Mo RAM . . . . . . . . . . . . . . . . . . . . . . 184
9.2 Temps du transfert estim depuis GPP vers GPU, pour PCI Express (16x) et les textures xed-point 8 bit BGRA
(bas sur les donnes ofcielles de NVidia
NVi05
). GPP = AMD Athlon 64 bit 3500+, 1 Go RAM . . . . . . . 185
209
Liste des tableaux
1.1 volution de nombre des transistors par produit Intel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2 Architectures multimdia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1 Le nombre et la dsignation des registres multimdia des reprsentants des architectures grand public . . . . 41
3.2 Consommation dnergie des GPP/GPPMM, des GPU et des consoles de jeux . . . . . . . . . . . . . . . . . 43
3.3 Rsultats exprimentaux de lopration addition sur les streams utilisant Brook pour lexcution dans le GPU 57
4.1 Types de donnes pour les algorithmes utilisant le pipeline graphique et les GPU . . . . . . . . . . . . . . . 77
4.2 Signatures de type des primitives du calcul du pipeline graphique et les GPU . . . . . . . . . . . . . . . . . . 81
5.1 Rsultats exprimentaux de diverses implmentations de la dilatation morphologique . . . . . . . . . . . . . 124
6.1 Algorithmes de transposition par diagonale et antidiagonale ; comparaison des temps de calcul et des taux
dacclration pour diverses implmentations et des tailles dimages . . . . . . . . . . . . . . . . . . . . . . 143
7.1 Rsultats exprimentaux pour diverses implmentations de la fonction distance sur la grille carre et 4-voisins
par pixel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
7.2 Rsultats exprimentaux pour diverses implmentations des nivellements sur la grille carre et 4-voisins par pixel 161
8.1 Rsultats exprimentaux de diverses implmentations de la dilatation par segments . . . . . . . . . . . . . . 174
9.1 Temps du calcul de lopration addition avec saturation sur les images dont les lments sont du type unsigned
integer 8bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
9.2 Test comparatif de performances dafchage dun rectangle couvrant entirement la scne . . . . . . . . . . 186
211
Bibliographie
[AD03] Marco ALDINUCCI et Marco DANELUTTO : An Operational Semantics for Skeletons. Prsentation. ParCo
2003, 2003. Disponible sur : http://www.di.unipi.it/~aldinuc/paper_les/2004_sem_parco03.pdf. [rf. du : 09
may 2006]. Format PDF. 26
[ADGkG96] Peter AU, John DARLINGTON, Moustafa M. GHANEM et Yi ke GUO : Co-ordinating heterogeneous parallel
computation. volume 1, pages 601614. Springer-Verlag, aot 1996. Disponible sur : http://hpc.doc.ic.ac.uk/
environments/coordination/papers/europar96.ps. [rf. du : 20 oct 2005]. Format PS. 26
[Ake03] Kurt AKELEY : Data Storage and Transfer in OpenGL. Prsentation. SIGGRAPH 2003, juillet 2003. Dis-
ponible sur : http://developer.nvidia.com/docs/IO/8229/Data-Xfer-Store.pdf. [rf. du : 14 may 2006]. Format
PDF. 183
[AMD06] AMD : Multi-Core Processors - the Next Evolution in Computing. 2006. Disponible sur : http://multicore.
amd.com/WhitePapers/Multi-Core_Processors_WhitePaper.pdf. [rf. du : 04 apr 2006]. Format PDF. 2006.
49
[ARM06] ARM : ARM11 MPCore. 2006. Disponible sur : http://www.arm.com/products/CPUs/
ARM11MPCoreMultiprocessor.html. [rf. du : 03 apr 2006]. Format HTML. 2006. 43, 49
[ATI06] ATI : Radeon X850 - The Performance Leader, Reviews. 2006. Disponible sur : http://www.ati.com/
products/radeonx850/reviews.html. [rf. du : 06 feb 2006]. Format HTML. 2006. 43
[Bac77] John BACKUS : Can Programming Be Liberated from the von Neumann Style ? A Functional Style and
Its Algebra of Programs. ACM Turing Award Lecture, 21(8):613641, aot 1977. Disponible sur : http:
//www.stanford.edu/class/cs242/readings/backus.pdf. [rf. du : 31 jul 2005]. Format PDF. 59
[Bag02] Daniele BAGNI : DSP and System-on-Chip. Prsentation. DSP Application Day 2002, 2002. 37, 39, 42
[BB94] Henk P. BARENDREGT et Erik BARENDSEN : Introduction to Lambda Calculus. Programming Methodology
Group, University of Gteborg and Chalmers University of Technology, 1994. Disponible sur : http://citeseer.
ist.psu.edu/barendregt94introduction.html. [rf. du : 11 oct 2005]. Format PS, PDF, PS.GZ. 59, 60, 61
[BBM
+
96] Andreas BIENIEK, Hans BURKHARDT, Heiko MARSCHNER, Gerald SCHREIBER et Michael NLLE : A
Parallel Watershed Algoritm. Rapport technique, Technische Informatik I, TU-HH, Universitt Freiburg, juin
1996. Disponible sur : ftp://www.ti1.tu-harburg.de/pub/papers/bie:etal:ib96.ps. [rf. du : 12 jul 2005]. Format
PS. 28
[BD93] Andy D. BEN-DYKE : Architectural Taxonomy - A Brief Review. 1993. Disponible sur : http://phase.hpcc.
jp/mirrors/parallel/faqs/comp-architecture-taxonomy. [rf. du : 11 jul 2005]. Format TXT. 1993. 31
[Beu84] Serge BEUCHER : Implantation dun logiciel de Morphologie Mathmatique sur calculateur Propal 2. Rapport
technique N-923, Centre de Gostatistique et de Morphologie Mathmatique, Ecole Nationale Suprieure des
Mines de Paris, 35, rue Saint Honor, 77300 Fontainebleau CEDEX, octobre 1984. Rapport nal. 46
[Beu90] Serge BEUCHER : Segmentation dimages et Morphologie mathmatique. Thse de doctorat, Ecole Nationale
Suprieure des Mines de Paris, juin 1990. Disponible sur : http://cmm.ensmp.fr/~beucher/publi/SB_these.pdf.
[rf. du : 22 apr 2006]. Format PDF. 99, 205
[BFH
+
04a] Ian BUCK, Tim FOLEY, Daniel HORN, Jeremy SUGERMAN, Kayvon FATAHALIAN, Mike HOUSTON et Pat
HANRAHAN : Brook for GPUs : Stream Computing on Graphics Hardware. SIGGRAPH 2004, 2004. Dispo-
nible sur : http://graphics.stanford.edu/papers/brookgpu/brookgpu.pdf. [rf. du : 02 aug 2005]. Format PDF.
56
[BFH
+
04b] Ian BUCK, Tim FOLEY, Daniel HORN, Jeremy SUGERMAN, Kayvon FATAHALIAN, Mike HOUSTON et Pat
HANRAHAN : Brook for GPUs : Stream Computing on Graphics Hardware. Prsentation. SIGGRAPH 2004,
2004. Disponible sur : http://graphics.stanford.edu/papers/brookgpu/buck.Brook.pdf. [rf. du : 02 aug 2005].
Format PDF. 56
213
[BHM
+
00] Prasenjit BISWAS, Atsushi HASEGAWA, Srinivas MANDAVILLE, Mark DEBBAGE, Andy STURGES, Fumio
ARAKAWA, Yasuhiko SAITO et Kunio UCHIYAMA : SH-5 : The 64-bit SuperH Architecture. IEEE Micro,
20(4):2839, juilletaot 2000. Disponible sur : http://dx.doi.org/10.1109/40.865864. [rf. du : 17 mar 2006].
Format PDF. INSPEC Accession Number :6678832. 38
[Bil92] Michel BILODEAU : Architecture logicielle pour processeur de morphologie mathmatique. Thse de doc-
torat, Ecole Nationale Suprieure des Mines de Paris, Centre de Morphologie Mathmatique, janvier 1992.
28
[BM83] Serge BEUCHER et F. MARTIN : Implantation dun logiciel de Morphologie Mathmatique sur calculateur
Propal 2. Rapport technique N-803, Centre de Gostatistique et de Morphologie Mathmatique, Ecole Natio-
nale Suprieure des Mines de Paris, 35, rue Saint Honor, 77300 Fontainebleau CEDEX, mars 1983. Rapport
technique no. 1. 46
[BM98] Andreas BIENIEK et Alina MOGA : A Connected Component Approach to the Watershed Segmentation. In
Mathematical Morphology and its Applications to the Image and Signal Processing, volume 12, pages 215
222. Kluwer Academic Publishers, 1998. Disponible sur : ftp://ftp.informatik.uni-freiburg.de/papers/lmb/bi:
mo:ismm98.ps.gz. [rf. du : 5 mar 2005]. Format PS.GZ. 28
[Boh02] Mark BOHR : Intels 90 nm Technology : Moores Law and More. Prsentation. Intel Developer Forum
Fall 2002, septembre 2002. Disponible sur : ftp://download.intel.com/technology/silicon/Bohr_IDF_0902.
pdf. [rf. du : 17 jul 2005]. Format PDF. 20
[Boh04] Mark BOHR : Intels 65 nm Process Technology. Prsentation. Intel Developer Forum, 2004. Disponible
sur : ftp://download.intel.com/technology/silicon/IRDS002_65nm_logic_process_100_percent.pdf. [rf. du :
17 jul 2005]. Format PDF. 19, 20
[Bra02] Jaromir BRAMBOR : Implementation Notes On Binary Dilation And Erosion On 64bit SH-5 Processor (Prin-
ciples of binary dilation and erosion using Minkowski Addition on 64-bit RISC SH-5 SuperH Multimedia
Architecture). Rapport technique, Centre de Morphologie Mathematique, Ecole Nationale Superieure des
Mines de Paris, Fontainebleau, October 2002. Disponible sur : http://cmm.ensmp.fr/~brambor/publications/
(Bramb02)Implementation-Notes-On-Binary-Dilation-and-Erosion-On-64bit-SH5-Processor.en.pdf. [rf.
du : 15 jul 2005]. Format PDF. 21, 65
[Bra05] Jaromir BRAMBOR : MorphoMedia documentation. Rapport technique, Centre de Morphologie Mathma-
tique Ecole Nationale Suprieure des Mines de Paris, ARMINES, juin 2005. 41, 42, 65, 207
[Bre65] Jack E. BRESENHAM : Algorithm for Computer Control of a Digital Plotter. IBM Systems Journal, 4(1):25
30, 1965. Disponible sur : http://www.research.ibm.com/journal/sj/041/ibmsjIVRIC.pdf. [rf. du : 06 jan
2006]. Format PDF. Reprinted in Interactive Computer Graphics, Herbert Freeman ed., IEEE catalog no.
EHO 156-0, Library of Congress no. 79-91237, 1980, and Seminal Graphics : Pioneering Efforts That Shaped
The Field, Rosalee Wolfe ed., ACM SIGGRAPH, ACM order no. 435985, ISBN 1-58113-052-X, 1998. 167
[Bre05] Clay P. BRESHEARS : Intel Threading Tools and OpenMP. avril 2005. Disponible sur : http://cache-www.
intel.com/cd/00/00/21/70/217017_217017.pdf. [rf. du : 31 mar 2006]. Format PDF. avril 2005. 50
[BW95] V. Michael Jr. BOVE et John A. WATLINGTON : Cheops : A Recongurable Data-Flow System for Video
Processing. IEEE Transactions on Circuits and Systems for Video Technology, pages 140149, avril 1995.
Disponible sur : http://web.media.mit.edu/~wad/cheops_CSVT/cheops.pdf. [rf. du : 16 feb 2006]. Format
PDF. 46
[Cam96] Duncan K. G. CAMPBELL : Towards the Classication of Algorithmic Skeletons. dcembre 1996. Disponible
sur : http://www.cs.uiuc.edu/homes/snir/PPP/skeleton/classication.pdf. [rf. du : 04 apr 2006]. Format PDF.
dcembre 1996. 27
[Cas03] S. CASS : Supercheap Supercomputer. Spectrum, IEEE, 40(7):1717, juillet 2003. Disponible sur : http:
//dx.doi.org/10.1109/MSPEC.2003.1209605. [rf. du : 21 mar 2006]. Format PDF. 37
[CDPS03] Joao Luiz Dihl COMBA, Carlos A. DIETRICH, Christian A. PAGOT et Carlos E. SCHEIDEGGER : Computation
on GPUs : From a Programmable Pipeline to an Efcient Stream Processor. 2003. Disponible sur : http:
//www.sci.utah.edu/~cscheid/pubs/rita_survey.pdf. [rf. du : 02 aug 2005]. Format PDF. 56
[CHD
+
02] Yen-Kuang CHEN, Matthew HOLLIMAN, Eric DEBES, Sergey ZHELTOV, Alexander KNYAZEV, Stanislav
BRATANOV, Roman BELENOV et Ishmael SANTOS : Media Applications on Hyper-Threading Technology.
In Intel Technology Journal (2002, Volume 06 Issue 01)
Int02
, pages 4757. Disponible sur : ftp://download.
intel.com/technology/itj/2002/volume06issue01/vol6iss1_hyper_threading_technology.pdf. [rf. du : 31 mar
2006]. Format PDF. 50
[Col89] Murray I. COLE : Algorithmic Skeletons : Structured Management of Parallel Computation. MIT Press, 1989.
Disponible sur : http://homepages.inf.ed.ac.uk/mic/Pubs/skeletonbook.ps.gz. [rf. du : 11 oct 2005]. Format
PS.GZ. 26
214
Jaromr BRAMBOR Bibliographie
[Cou02] Rmi COUDARCHER : Composition de squelettes algorithmiques : application au prototypage rapide dap-
plications de vision. Thse de doctorat, Laboratoire des Sciences et Matriaux pour lElectronique, et dAuto-
matique (LASMEA), UNIVERSITE BLAISE PASCAL - CLERMONT-FERRAND II, dcembre 2002. Dis-
ponible sur : http://tel.ccsd.cnrs.fr/documents/archives0/00/00/33/50/tel-00003350-02/tel-00003350.pdf. [rf.
du : 20 oct 2005]. Format PDF. 26
[CT93] Michel COSNARD et Denis TRYSTRAM : Algorithmes et architectures paralleles. InterEditions, Paris, 1993.
31, 32
[Cui99] Olivier CUISENAIRE : Distance Transformations : Fast Algorithms and Applications to Medical Image Pro-
cessing. Thse de doctorat, Universit Catholique de Louvain, octobre 1999. 28, 147
[CW02] Cem CEBENOYAN et Matthias WLOKA : Graphics Performance : Balancing the Rendering Pipeline. Prsen-
tation. GDC2002, 2002. Disponible sur : http://www.cs.virginia.edu/~gfx/Courses/2002/RealTime.fall.02/
GDC2002_PipePerformance.ppt. [rf. du : 13 may 2006]. Format PPT. 183
[Dal03] Daniel Sanchez-Crespo DALMAU : Core Techniques and Algorithms in Game Programming. New Riders
Publishing, novembre 2003. 55
[Dar98] John DARLINGTON : Generic Co-ordination Forms for Parallel Application Construction. Rapport technique,
Imperial College, 1998. Disponible sur : http://hpc.doc.ic.ac.uk/environments/coordination/nal.ps. [rf. du :
20 oct 2005]. Format PS. 26
[DB05] Marc Van DROOGENBROECK et M. BUCKLEY : Morphological erosions and openings : Fast algorithms
based on anchors. Journal of Mathematical Imaging and Vision, Special Issue on Mathematical Morphology
after 40 Years, 22(2-3):121142, mai 2005. Disponible sur : http://dx.doi.org/10.1007/s10851-005-4886-2.
[rf. du : 09 may 2005]. Format HTML. Springer Netherlands. 168, 174
[DD03] Eva DEJNOZKOVA et Petr DOKLADAL : A multiprocessor architecture for PDE-based applications. Visual
Information Engeneering, -:, juillet 2003. Disponible sur : http://cmm.ensmp.fr/~dejnozke/professionnel/
Dejnozkova_VIE2003_nal.pdf. [rf. du : 17 jul 2005]. Format PDF. 28
[DD04] Eva DEJNOZKOVA et Petr DOKLADAL : Asynchonous Multi-core Architecture for Level Set Methods. IEEE
International Conference on Accoustics, Speech and Signal Processing ICASSP, -:, mai 2004. Disponible
sur : http://cmm.ensmp.fr/~dejnozke/professionnel/dejnozkova.pdf. [rf. du : 17 jul 2005]. Format PDF. 28
[DD06] Renaud DARDENNE et Marc Van DROOGENBROECK : The libmorpho library. 2006. Disponible sur :
http://www.ulg.ac.be/telecom/research/libmorpho.html. [rf. du : 03 july 2006]. Format HTML. 2006. 168,
174
[Dej04] Eva DEJNOZKOVA : Architecture ddi au traitement dimages bas sur les equations aux drives partielles.
Thse de doctorat, Ecole des Minbes de Paris, mars 2004. Disponible sur : http://cmm.ensmp.fr/~dejnozke/
these_print_dejnozkova_v2.pdf. [rf. du : 17 jul 2005]. Format PDF. 24, 28
[DFH
+
93] J. DARLINGTON, A. J. FIELD, P. G. HARRISON, P. H. J. KELLY, D. W. N. SHARP, Q. WU et R. L. WHILE :
Parallel Programming Using Skeleton Functions. In A. BODE, M. REEVE et G. WOLF, diteurs : PARLE 93 :
Parallel Architectures and Languages Europe, pages 146160. Springer-Verlag, Berlin, DE, 1993. Disponible
sur : http://citeseer.ist.psu.edu/darlington93parallel.html. [rf. du : 10 oct 2005]. Format PDF, PS. 26, 66, 67
[DGG
+
96] John DARLINGTON, Yike GUO, Moustafa GHANEM, Jin YANG, Kwok Tat Peter AU et Rami SIK : Co-
ordinating Combined Parallel Vector and Scalar Computation. Rapport technique IFPC-TR-96-1, Imperial
College, janvier 1996. Disponible sur : http://hpc.doc.ic.ac.uk/environments/coordination/papers/ifpc-tr-96-1.
ps. [rf. du : 20 oct 2005]. Format PS. 26
[DGGT97] John DARLINGTON, Moustafa M. GHANEM, Yike GUO et H. W. TO : Performance models for co-
ordinating parallel data classication. septembre 1997. Disponible sur : http://hpc.doc.ic.ac.uk/environments/
coordination/papers/pcw97-datamining.ps. [rf. du : 20 oct 2005]. Format PS. 26
[DGTY95a] J. DARLINGTON, Y. GUO, H. W. TO et J. YANG : Parallel skeletons for structured composition. Fifth
ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, pages 1928, juillet 1995.
Disponible sur : http://hpc.doc.ic.ac.uk/environments/coordination/papers/ppopp.ps. [rf. du : 20 oct 2005].
Format PS. 26
[DGTY95b] John DARLINGTON, Yike GUO, Hing Wing TO et Jin YANG : Functional Skeletons for Parallel Coordination.
In Euro-Par 95 : Proceedings of the First International Euro-Par Conference on Parallel Processing, volume
996, pages 5566, London, UK, 1995. Springer-Verlag. Disponible sur : http://hpc.doc.ic.ac.uk/environments/
coordination/papers/europar95.ps. [rf. du : 04 apr 2006]. Format PS. 26, 67
[DkGT95] John DARLINGTON, Yi ke GUO et Hing Wing TO : Stuctured Parallel Programming : Theory meets Practice.
1995. Disponible sur : http://hpc.doc.ic.ac.uk/environments/coordination/papers/book.ps. [rf. du : 18 oct
2005]. Format PS. 26
215
[DkGTY96] John DARLINGTON, Yi ke GUO, Hing Wing TO et Jin YANG : SPF : Structured Parallel Fortran. page 6,
1996. Disponible sur : http://hpc.doc.ic.ac.uk/environments/coordination/papers/pcw96-spf.ps. [rf. du : 15
dec 2005]. Format PS. 26
[DMO
+
92] Marco DANELUTTO, Robert Di MEGLIO, Salvatore ORLANDO, Susanna PELAGATTI et Marco VANNESCHI :
A methodology for the development and the support of massively parallel programs. Future Generation
Computer Systems, 8(1-3):205220, juillet 1992. Disponible sur : ftp://ftp.di.unipi.it/pub/project/p3l/orence.
ps.gz. Format PS.GZ. pre-print. 26
[DNG00] John DARLINGTON, Steven NEWHOUSE et Yike GUO : Parallel Problem Solving Course 2000. Prsentation.
2000. Disponible sur : http://hpc.doc.ic.ac.uk/PPS/PPS00ALL.ppt. [rf. du : 15 dec 2005]. Format PPT. 26
[DPRS01] Udo DIEWALD, Tobias PREUSSER, Martin RUMPF et Robert STRZODKA : Diffusion Models and Their
Accelerated Solution in Image and Surface Processing. Acta Mathematica Universitatis Comenianae, 70(1):
1531, 2001. 28
[DT95] J. DARLINGTON et H. W. TO : Building Parallel Applications Without Programming. In J. R. DAVY et P. M.
DEW, diteurs : Abstract Machine Models for Highly Parallel Computers, pages 140154. Oxford University
Press, 1995. Disponible sur : http://hpc.doc.ic.ac.uk/ala/papers/H.W.To/leeds.ps.Z. [rf. du : 12 oct 2005].
Format PS.Z. 26
[DT96] Marc Van DROOGENBROECK et Hugues TALBOT : Fast computation of morphological operations with
arbitrary structuring elements. Pattern Recogn. Lett., 17(14):14511460, 1996. Disponible sur : http:
//www.ulg.ac.be/telecom/publi/publications/mvd/anydila.pdf. 168
[Dun90] Ralph DUNCAN : A Survey of Parallel Computer Architectures. IEEE Computer, 23(2):516, fvrier 1990.
Disponible sur : http://dx.doi.org/10.1109/2.44900. [rf. du : 12 jul 2005]. Format PPT. 31, 33, 35
[Eng78] J. N. ENGLAND : A system for interactive modeling of physical curved surface objects. In SIGGRAPH 78 :
Proceedings of the 5th annual conference on Computer graphics and interactive techniques, pages 336340,
New York, NY, USA, 1978. ACM Press. Disponible sur : http://doi.acm.org/10.1145/800248.807412. [rf.
du : 16 feb 2006]. Format PDF. 56
[FBF00] Paolo FARABOSCHI, Geoffrey BROWN et Joseph A. FISHE : Lx : A Technology Platform for Customi-
zable VLIW Embedded Processing. In The 27th Annual International Symposium on Computer architecture
2000, pages 203213, New York, NY, USA, 2000. ACM Press. Disponible sur : http://citeseer.ist.psu.edu/
faraboschi00lx.html. [rf. du : 20 mar 2006]. Format PDF. 37, 42
[FF88] Alain FOURNIER et Donald FUSSELL : On the power of the frame buffer. ACM Trans. Graph., 7(2):103128,
1988. Disponible sur : http://doi.acm.org/10.1145/42458.42460. [rf. du : 16 feb 2006]. Format PDF. 56
[FH05] M. J. FLYNN et P. HUNG : Microprocessor design issues : thoughts on the road ahead. Micro, IEEE, 25(3):16
31, 2005. Disponible sur : http://dx.doi.org/10.1109/MM.2005.56. [rf. du : 31 mar 2006]. INSPEC Accession
Number :8512670. 23, 48
[FK03] Randima FERNANDO et Mark J. KILGARD : The Cg Tutorial. Addison-Wesley, fvrier 2003. NVidia. 51, 55
[Fly66] Michael J. FLYNN : Very High-speed Computing Systems. Proceedings of IEEE, 54(12):19011909,
dcembre 1966. Disponible sur : http://ieeexplore.ieee.org/iel5/5/31091/01447203.pdf?tp=&arnumber=
1447203&isnumber=31091. [rf. du : 12 jul 2005]. Format PPT. 31
[FS02] Inc. FREESCALE SEMICONDUCTOR : MPC750 and MPC740 Microprocessors, Fact Sheet, 2002. Disponible
sur : http://www.freescale.com/les/32bit/doc/fact_sheet/MPC750FACT.pdf. [rf. du : 03 apr 2006]. Format
PDF. 43
[GAA97] David Z. GEVORKIAN, Jaakko T. ASTOLA et Samvel M. ATOURIAN : Improving Gil-Werman Algorithm for
Running Min and Max Filters. In IEEE Trans. Pattern Anal. Mach. Intell.
GW93
, pages 526529. Disponible
sur : http://dx.doi.org/10.1109/34.589214. [rf. du : 06 jan 2006]. Format PDF. 167, 217
[Gav05a] Ilya GAVRICHENKOV : First Look at Presler : Intel Pentium Extreme Edition 955 CPU Review. dcembre
2005. Disponible sur : http://www.xbitlabs.com/articles/cpu/display/presler.html. [rf. du : 14 mar 2006].
Format HTML. dcembre 2005. 43
[Gav05b] Ilya GAVRICHENKOV : Intel Pentium 4 6XX and Intel Pentium 4 Extreme Edition 3.73GHz CPU Review.
fvrier 2005. Disponible sur : http://www.xbitlabs.com/articles/cpu/display/pentium4-6xx_8.html. [rf. du :
14 mar 2006]. Format HTML. fvrier 2005. 43
[Gav06] Ilya GAVRICHENKOV : AMD Athlon 64 FX-60 CPU Review. janvier 2006. Disponible sur : http://www.
xbitlabs.com/articles/cpu/display/athlon64-fx60.html. [rf. du : 14 mar 2006]. Format HTML. janvier 2006.
43
[GCRW
+
99] Antonio GENTILE, Jos L. CRUZ-RIVERA, D. Scott WILLS, Leugim BUSTELO, Jos J. FIGUEROA, Javier E.
FONSECA-CAMACHO, Wilfredo E. LUGO-BEAUCHAMP, Ricardo OLIVIERI, Marlyn QUIONES-CERPA,
Alexis H. RIVERA-ROS, Iomar VARGAS-GONZLES et Michelle VIERA-VERA : Real-Time Image Pro-
cessing on a Focal Plane SIMD Array. IPPS/SPDP Workshops, pages 400405, 1999. Disponible sur :
http://ipdps.cc.gatech.edu/1999/wpdrts/gentile.pdf. [rf. du : 17 oct 2005]. Format PS, PS.GZ, PDF. 35
216
[Gha99] Moustafa Mahmoud Hafez GHANEM : Structured Parallel Programming Using Performance Models and
Skeletons. Thse de doctorat, University of London, Imperial College of Sciences, Technology and Medicine,
Department of Computing, fvrier 1999. Disponible sur : http://hpc.doc.ic.ac.uk/environments/coordination/
papers/mmg.ps. [rf. du : 18 oct 2005]. Format ps. 26
[GHC] The GHCTEAM : The Glorious Glasgow Haskell, Compilation System Users Guide, Version 6.4.1. Dis-
ponible sur : http://www.haskell.org/ghc/docs/latest/users_guide.pdf. [rf. du : 01 dec 2005]. Format PDF.
62
[Gib94] Jeremy GIBBONS : An Introduction to the Bird-Meertens Formalism. New Zealand Formal Program Deve-
lopment Colloquium Seminar, page 12, 1994. Disponible sur : http://cs.anu.edu.au/people/Clem.Baker-Finch/
AFP/nzfpdc-squiggol.ps.gz. 27
[GK02] Joseph (Yossi) GIL et Ron KIMMEL : Efcient Dilation, Erosion, Opening, and Closing Algorithms. IEEE
Trans. Pattern Anal. Mach. Intell., 24(12):16061617, 2002. Disponible sur : http://dx.doi.org/10.1109/
TPAMI.2002.1114852. [rf. du : 06 jan 2006]. Format PDF. 167
[Gom01] Cristina GOMILA : Mise en correspondance de partitions en vue du suivi dobjets. Thse de doctorat en
morphologie mathmatique, Ecole Nationale Suprieure des Mines de Paris, 2001. Disponible sur : http:
//cmm.ensmp.fr/~gomila/These_Gomila.pdf. [rf. du : 27 mar 2006]. Format PDF. 27, 36
[GPG] GPGPU. Disponible sur : http://www.gpgpu.org/. [rf. du : 09 mar 2006]. Format HTML. 22, 56
[Gra03] Kris GRAY : Microsoft DirectX 9 Programmable Graphics Pipeline. Microsoft Press, juillet 2003. CDROM.
54, 55
[Gre05] Will GREENWALD : Xbox 360 : BEWARE, I HUNGER! ! ! dcembre 2005. Disponible sur : http://reviews.
cnet.com/4531-10921_7-6398157.html. [rf. du : 14 mar 2006]. Format HTML. dcembre 2005. 43
[Gro02] Andy GROVE : Changing Vectors of Moores Law. Prsentation. International Electron Devices Meeting,
dec 2002. Disponible sur : http://www.intel.com/pressroom/archive/speeches/grove_20021210.pdf. [rf. du :
07 mar 2006]. Format PDF. Intel Corporation. 19
[GS03] Charles W. GWYN et Peter J. SILVERMAN : EUVL : transition from research to commercialization. Pho-
tomask and Next-Generation Lithography Mask Technology X, 5130(1):9901004, 2003. Disponible sur :
http://dx.doi.org/10.1117/12.504239. [rf. du : 8 mars 2006]. Format PDF. 20
[GS05] John GOODACRE et Andrew N. SLOSS : Parallelism and the ARM Instruction Set Architecture. IEEE
Computer, 38(7):4250, juillet 2005. Disponible sur : http://dx.doi.org/10.1109/MC.2005.239. [rf. du : 04
apr 2006]. Format PDF. INSPEC Accession Number :8513365. 43
[GW93] J. GIL et M. WERMAN : Computing 2-D Min, Median, and Max Filters. In IEEE Trans. Pattern Anal. Mach.
Intell.
GAA97
, pages 504507. Disponible sur : http://dx.doi.org/10.1109/34.211471. [rf. du : 06 jan 2006].
Format PDF. 167, 216
[GWH05] Nolan GOODNIGHT, Rui WANG et Greg HUMPHREYS : Computation on Programmable Graphics Hardware.
IEEE Comput. Graph. Appl., 25(5):1215, 2005. Disponible sur : http://dx.doi.org/10.1109/MCG.2005.101.
[rf. du : 30 nov 2005]. Format PDF. 56
[HAL04] Kevin HAWKINS, Dave ASTLE et Andr LAMOTHE : OpenGL Game Programming. The Premier Press,
2004. CDROM. 55
[HCSL02] Mark J. HARRIS, Greg COOMBE, Thorsten SCHEUERMANN et Anselmo LASTRA : Physically-Based Visual
Simulation on Graphics Hardware. Graphics Hardware, pages 110, 2002. Disponible sur : http://www.
markmark.net/cml/dl/HWW02_Harris_electronic.pdf. 56
[HE00] Matthias HOPF et Thomas ERTL : Accelerating Morphological Analysis with Graphics Hardware. 2000.
Disponible sur : http://wwwvis.informatik.uni-stuttgart.de/eng/research/pub/pub2000/vmv00-hopf.pdf. [rf.
du : 12 jul 2005]. Format PDF. 2000. 28, 118
[Hei95] Henk J.A.M. HEIJMANS : Mathematical Morphology : Basic Principles. 1995. Disponible sur : http://citeseer.
ist.psu.edu/heijmans95mathematical.html. [rf. du : 07 mai 2006]. Format PS, PDF. 84
[HMJH05] Tim HARRIS, Simon MARLOW, Simon Peyton JONES et Maurice HERLIHY : Composable Memory Tran-
sactions. ACM Conference on Principles and Practice of Parallel Programming 2005 (PPoPP05), page 13,
juin 2005. Disponible sur : http://research.microsoft.com/Users/simonpj/papers/stm/stm.pdf. [rf. du : 29 mar
2006]. 60
[HPF99] Paul HUDAK, John PETERSON et Joseph H. FASEL : A Gentle Introduction to Haskell 98. page 64, octobre
1999. Disponible sur : http://www.haskell.org/tutorial/haskell-98-tutorial.pdf. [rf. du : 9 apr 2006]. Format
HTML. 61
[Ian88] Robert A. IANNUCCI : A dataow/von Neumann hybrid architecture. Thse de doctorat, Massachusetts
Institute of Technology. Dept. of Electrical Engineering and Computer Science, 1988. Disponible sur : http:
//hdl.handle.net/1721.1/14778. [rf. du : 39 mar 2006]. Format PDF. 47
217
[Int02] INTEL, diteur. Intel Technology Journal (2002, Volume 06 Issue 01), volume 06, fvrier 2002. Disponible
sur : ftp://download.intel.com/technology/itj/2002/volume06issue01/vol6iss1_hyper_threading_technology.
pdf. [rf. du : 29 mar 2006]. Format PDF. 214, 219, 221
[Int05] INTEL : Platform 2015 : Intel Processor and Platform Evolution for the Next Decade. page 12, 2005. Dis-
ponible sur : ftp://download.intel.com/technology/computing/archinnov/platform2015/download/Platform_
2015.pdf. [rf. du : 17 jul 2005]. Format PDF. 20
[Int06a] INTEL : Intel First to Demonstrate Working 45nm Chips. 2006. Disponible sur : http://www.intel.com/
technology/silicon/new_45nm_silicon.htm. [rf. du : 2 fev 2006]. Format HTML. 2006. 20
[Int06b] INTEL : Intel Integrated Perfromance Primitives. 2006. Disponible sur : http://www.intel.com/cd/software/
products/asmo-na/eng/perib/ipp/index.htm. [rf. du : 26 mar 2006]. Format HTML. 2006. 41
[Int06c] INTEL : Intel Pentium Processor Extreme Edition 995, Product Brief. 2006. Disponible sur : http://www.
intel.com/products/processor/pentiumXE/index.htm. [rf. du : 14 mar 2006]. Format HTML. 2006. 43
[Int06d] INTEL : Processeur Intel Core Duo, Product Brief. 2006. Disponible sur : http://www.intel.com/products/
processor/coreduo/product-brief.pdf. [rf. du : 04 apr 2006]. Format PDF. 2006. 49
[ITR] International Technology Roadmap for Semiconductors. Disponible sur : http://public.itrs.net/. [rf. du : 13
mars 2006]. Format HTML. 24
[Jon03] Simon Peyton JONES : Haskell 98 Language and Libraries The Revised Report, janvier 2003. Disponible
sur : http://www.haskell.org/denition/haskell98-report.pdf. 60, 64
[Jou91] Guido K. JOURET : Compiling Functional Languages for SIMD Architectures. Parallel and Distributed
Processing, Proceedings of the Third IEEE Symposium on, pages 7986, dcembre 1991. Disponible sur :
http://dx.doi.org/10.1109/SPDP.1991.218294. [rf. du : 11 oct 2005]. Format PDF. ISBN : 0-8186-2310-1. 26
[KBR03] John KESSENICH, Dave BALDWIN et Randi ROST : The OpenGL Shading Language version 1.051, feb 2003.
55
[KDK
+
01] B. KHAILANY, W. DALLY, U. KAPASI, P. MATTSON, J. NAMKOONG, J. OWENS, B. TOWLES, A. CHANG
et S. RIXNER : Imagine : Media Processing with Streams. IEEE Micro, 21(2):3546, mars 2001. Disponible
sur : http://cva.stanford.edu/cs99s/papers/imagine-ieeemicro.pdf. 37, 46
[KDR
+
02] Ujval J. KAPASI, William J. DALLY, Scott RIXNER, John D. OWENS et Brucek KHAILANY : The Imagine
Stream Processor. IEEE International Conference on Computer Design, pages 282288, 2002. Disponible
sur : http://www.iccd-conference.org/proceedings/2002/17000282.pdf. 37, 46
[KEH
+
02] Steffen KLUPSCH, Markus ERNST, Sorin A. HUSS, Martin RUMPF et Robert STRZODKA : Real Time
Image Processing based on Recongurable Hardware Acceleration. 2002. Disponible sur : http://numod.
ins.uni-bonn.de/research/papers/public/KlErHuRuSt02.pdf. [rf. du : 22 apr 2006]. Format PDF. 28
[Ker97] Renaud KERIVEN : Equation aux Drives Partielles, Evolution de Courbes et de Surfaces et Espaces
dEchelle : Application la Vision par Ordinateur. Thse de doctorat, Ecole Nationale de Ponts et Chausses,
1997. Disponible sur : http://tel.ccsd.cnrs.fr/tel-00005617/en/. [rf. du : 22 apr 2006]. Format PDF,PS. 28
[KKI04] Takashi KOMURO, Shingo KAGAMI et Masatoshi ISHIKAWA : A Dynamically Recongurable SIMD Pro-
cessor for a Vision Chip. IEEE JOURNAL OF SOLID-STATE CIRCUITS, 39(1):265268, janvier 2004.
Disponible sur : http://dx.doi.org/10.1109/JSSC.2003.820876. [rf. du : 10 jan 2006]. Format PDF. 65
[Kra04] Tom KRAZIT : Transmetas M8800 Efceon Processor Powers Down, New version of the processor uses only
3 watts of power at 1-GHz speed. octobre 2004. Disponible sur : http://www.pcworld.com/news/article/0,aid,
118063,00.asp. [rf. du : 20 mar 2006]. Format HTML. octobre 2004. 37, 43, 44
[KRD
+
03] Ujval J. KAPASI, Scott RIXNER, William J. DALLY, Brucek KHAILANY, Jung Ho AHN, Peter MATTSON et
John D. OWENS : Programmable Stream Processors. IEEE Computer, 36(8):5462, aot 2003. Disponible
sur : ftp://cva.stanford.edu/pub/publications/ieeecomputer_stream.pdf. [rf. du : 07 nov 2005]. Format PDF.
46
[Kre05] Tino KREISS : Twos Company, Fours a WOW! Sneak Preview of NVIDIA Quad GPU Graphics. 2005.
Disponible sur : http://www.tomshardware.com/2005/12/14/sneak_preview_of_the_nvidia_quad_gpu_setup/
print.html. [rf. du : 14 mar 2006]. Format HTML. 2005. 43, 51
[Lab97] Bell LABS : Bell Labs celebrates 50 years of the Transistor. 1997. Disponible sur : http://www.lucent.com/
minds/transistor/pdf/inventor.pdf. [rf. du : 2 fev 2006]. Format PDF. 1997. 23
[LBB98] Alina LINDNER, Andreas BIENIEK et Hans BURKHARDT : PISA Parallel Image Segmentation Algorithms.
, 1998. 1998. 28
[Lee00] Ruby B. LEE : Subword Permutation Instructions for Two-Dimensional Multimedia Processing in Micro-
SIMD Architectures. Application-Specic Systems, Architectures, and Processors, 2000. Proceedings. IEEE
International Conference on, pages 314, juillet 2000. Disponible sur : http://dx.doi.org/10.1109/ASAP.2000.
862373. [rf. du : 8 mar 2006]. Format PDF. INSPEC Accession Number : 6741658. 145
218
[Lem96] Fabrice LEMONNIER : Architecture lectronique ddie aux algorithmes rapides de segmentation bass sur
la morphologie mathmatique. Thse de doctorat, Ecole Nationale Suprieure des Mines de Paris, dcembre
1996. 28, 46
[LFB01] Ruby B. LEE, A. Murat FISKIRAN et Abdulla BUBSHAIT : Multimedia Instructions in IA-64. IEEE
International Conference on Multimedia and Expo 2001, pages 281284, aot 2001. Disponible sur :
http://dx.doi.org/10.1109/ICME.2001.1237694. [rf. du : 8 mar 2006]. Format PDF. 21, 145
[LM99] Lacezar LICEV et David MORKES : Procesory - Architektura, funkce, pouziti. Computer Press, 1999. 38
[Lov05] Anthony LOVESEY : A Comparison of Real Time Graphical Shading Languages. mars 2005. Disponible
sur : http://www.cs.unb.ca/undergrad/html/documents/Lovesey_Senior_TechReport.pdf. Faculty of Computer
Science, University of New Brunswick, Canada, mars 2005. 55
[Lue04] David LUEBKE : General-Purpose Computation on Graphics Hardware. 2004. Disponible sur : http://www.
gpgpu.org/s2004/slides/luebke.Introduction.ppt. [rf. du : 12 jul 2005]. Format PPT. 2004. 23
[Mah05] Joseph M. MAHONEY : 3D Graphics Then and Now : From the CPU to the GPU. Proceedings of the
5thWinona Computer Science Undergraduate, pages 1420, avril 2005. Disponible sur : http://cs.winona.edu/
CSConference/2005proceedings/joe.pdf. 23
[MBH
+
02] Deborah T. MARR, Frank BINNS, David L. HILL, Glenn HINTON, David A. KOUFATY, J. Alan MILLER
et Michael UPTON : Hyper-Threading Technology Architecture and Microarchitecture. In Intel Technology
Journal (2002, Volume 06 Issue 01)
Int02
, pages 415. Disponible sur : ftp://download.intel.com/technology/itj/
2002/volume06issue01/vol6iss1_hyper_threading_technology.pdf. [rf. du : 31 mar 2006]. Format PDF. 48
[Mei04] Arnold MEIJSTER : Efcient Sequential and Parallel Algorithms for Morphological Image Processing.
Thse de doctorat, Rijksuniversiteit Groningen, mars 2004. Disponible sur : http://rc60.service.rug.nl/~arnold/
articles/DigThesis.pdf. [rf. du : 12 jul 2005]. Format PDF. ISBN 90-367-1978-x (digital version). 28
[Mey03] Fernand MEYER : Floodings, razings and levellings. Prsentation. Centre de Morphologie Mathmatique,
mars 2003. 154
[MGR
+
05a] Victor MOYA, Carlos GONZALEZ, Jordi ROCA, Agustin FERNANDEZ et Roger ESPASA : Shader Performance
Analysis on a Modern GPU Architecture. Micro38 Barcelona, Spain, pages 110, novembre 2005. Disponible
sur : http://personals.ac.upc.edu/vmoya/docs/vmoya-ShaderPerformance.pdf. [rf. du : 2 fev 2006]. Format
PDF. 54
[MGR
+
05b] Victor MOYA, Carlos GONZLEZ, Jordi ROCA, Agustn FERNNDEZ et Roger ESPASA : A Single (Unied)
Shader GPU Microarchitecture for Embedded Systems. HiPEAC 2005, 2005 International Conference on
High Performance Embedded Architectures & Compilers, pages 115, novembre 2005. Disponible sur :
http://personals.ac.upc.edu/vmoya/docs/EmbeddedGPU.pdf. [rf. du : 2 fev 2006]. Format PDF. 54
[Mig04] Pascal MIGNOT : Pipeline graphique, Leon n2 : concept et organisation du pipeline graphique de Di-
rectX 9. Prsentation. 2004. Disponible sur : http://helios.univ-reims.fr/UFR/Info/Image/DirectX/cours/
02-Pipelinegraphique.pdf. [rf. du : 10 apr 2006]. Format PDF. Universit de Reims. 55
[Moo65] Gordon E. MOORE : Cramming more components onto integrated circuits. Electronics, 38(8):114117, avril
1965. Disponible sur : ftp://download.intel.com/museum/Moores_Law/Articles-Press_Releases/Gordon_
Moore_1965_Article.pdf. [rf. du : 13 jul 2005]. Format PDF. 19
[Moo98] Gordon E. MOORE : Cramming More Components onto Integrated Circuits. In IEEE, diteur : Proceedings
of the IEEE, volume 86, pages 8285, janvier 1998. Disponible sur : http://dx.doi.org/10.1109/JPROC.1998.
658762. [rf. du : 13 jul 2005]. Format PDF. 19
[Moo03a] Gordon MOORE : No exponential is forever : but "Forever" can be delayed ! In Solid-State Circuits Confe-
rence, 2003. Digest of Technical Papers. ISSCC. 2003 IEEE International
Moo03b
, pages 2023. Disponible
sur : http://dx.doi.org/10.1109/ISSCC.2003.1234194. [rf. du : 8 mars 2006]. Format PDF. INSPEC Acces-
sion Number : 7785691. 23, 219
[Moo03b] Gordon E. MOORE : No exponential is forever. Prsentation. Solid-State Circuits Conference 2003, IEEE In-
ternational, In Solid-State Circuits Conference, 2003. Digest of Technical Papers. ISSCC. 2003 IEEE Interna-
tional
Moo03a
, pages 2023. Disponible sur : http://ieeexplore.ieee.org/xpl/multimedia.jsp?arnumber=1234194.
[rf. du : 15 avr 2006]. Format ZIP. INSPEC Accession Number : 7785691. 23, 219
[MR96] A. MEIJSTER et J. B. T. M. ROERDINK : Computation of Watersheds Based on Parallel Graph Algorithms.
Mathematical Morphology and its Applications to Image and Signal Processing, pages 305312, 1996. 28
[NH00] Desikachari NADADUR et Robert M. HARALICK : Recursive binary dilation and erosion using digital line
structuring elements in arbitrary orientations. In Proc. SPIE Vol. 3026, p. 95-105, Nonlinear Image Processing
VIII, Edward R. Dougherty ; Jaakko T. Astola ; Eds.
NHS97
, pages 749759. Disponible sur : http://dx.doi.org/
10.1109/83.841511. [rf. du : 06 jan 2006]. Format PDF. 167, 220
219
[NHS97] D. NADADUR, R. M. HARALICK et F. H. SHEEHAN : Recursive binary dilation using digital line-structuring
elements in arbitrary orientations. In Proc. SPIE Vol. 3026, p. 95-105, Nonlinear Image Processing VIII,
Edward R. Dougherty ; Jaakko T. Astola ; Eds.
NH00
, pages 95105. Disponible sur : http://adsabs.harvard.edu/
cgi-bin/nph-bib_query?bibcode=1997SPIE.3026...95N&db_key=PHY. [rf. du : 06 jan 2006]. Format PDF.
167, 219
[Nog97] D. NOGUET : A massively parallel implementation of the watershed based oncellular automata. pages
4252, 1997. Disponible sur : http://ieeexplore.ieee.org/iel3/4817/13318/00606811.pdf?tp=&arnumber=
606811&isnumber=13318. [rf. du : 12 jul 2005]. Format PPT. 28
[Nog98] Dominique NOGUET : Architectures parallles pour la morphologie mathmatique godsique. Thse de
doctorat, Institut National Polytchnique de Grenoble, janvier 1998. Disponible sur : http://tel.ccsd.cnrs.fr/
documents/archives0/00/00/30/40/tel-00003040-00/tel-00003040.pdf. [rf. du : 12 jul 2005]. Format PDF.
ISBN (paperback) : 2-913329-23-3 ; ISBN (electronic format) : 2-913329-23-3 ; Thse de Doctorat INPG,
Spcialit Microlectronique. 28, 194
[Nog02] Aleksey NOGIN : A Review of Theorem Provers. fvrier 2002. Disponible sur : http://www.cs.cornell.
edu/Nuprl/PRLSeminar/PRLSeminar01_02/Nogin/PRLseminar7b.pdf. [rf. du : 7 may 2006]. Format PDF.
fvrier 2002. 195
[Nor01] Per NORDLOW : Implementation Aspects Of Image Processing. Mmoire de D.E.A., Institutionen for sys-
temteknik, Department of Electrical Engineering, Linkopings universitet, Sweden, mars 2001. Disponible
sur : http://www.cvl.isy.liu.se/ScOut/Masters/Papers/Ex3088.pdf. [rf. du : 16 feb 2006]. Format PDF. 43, 50
[NSG05a] Samuel NAFFZIGER, Blaine STACKHOUSE et Tom GRUTKOWSKI : The Implementation of a 2-core, Multi-
threaded Itanium Family Processor. ISSCC 2005, San Francisco, mars 2005. Disponible sur : http://www.
ewh.ieee.org/r5/denver/sscs/Presentations/2005.03.Naffziger.pdf. [rf. du : 2 fev 2006]. Format PDF. 19, 20
[NSG05b] Samuel NAFFZIGER, Blaine STACKHOUSE et Tom GRUTKOWSKI : The Implementation of a 2-core, Multi-
threaded Itanium Family Processor. Prsentation. ISSCC 2005, San Francisco, mars 2005. Disponible sur :
http://www.ewh.ieee.org/r5/denver/sscs/Presentations/2005.03.Montecito1.pdf. [rf. du : 2 fev 2006]. Format
PDF. 19, 43
[NVi05] NVIDIA : Fast Texture Downloads and Readbacks using Pixel Buffer Objects in OpenGL, Technical Brief.
aot 2005. Disponible sur : http://download.nvidia.com/developer/Papers/2005/Fast_Texture_Transfers/Fast_
Texture_Transfers.pdf. [rf. du : 14 may 2006]. Format PDF. aot 2005. 185, 186, 209
[NVi06] NVIDIA : NVidia GeForce 7 Series GPUs Specications. 2006. Disponible sur : http://www.nvidia.com/
object/7_series_techspecs.html. [rf. du : 9 mar 2006]. Format HTML. 2006. 22
[OLG
+
05] John D. OWENS, David LUEBKE, Naga GOVINDARAJU, Mark HARRIS, Jens KRGER, Aaron E. LEFOHN et
Timothy J. PURCELL : A Survey of General-Purpose Computation on Graphics Hardware. In Eurographics
2005, State of the Art Reports, pages 2151, aot 2005. Disponible sur : http://graphics.idav.ucdavis.edu/
publications/func/return_pdf?pub_id=844. [rf. du : 12 jul 2005]. Format PDF. 22, 44, 56
[Ope06] OPENMP : OpenMP Web site. 2006. Disponible sur : http://www.openmp.org. [rf. du : 21 may 2006].
Format HTML. 2006. 50
[ORK
+
02] John D. OWENS, Scott RIXNER, Ujval J. KAPASI, Peter MATTSON, Brian TOWLES, Ben SEREBRIN et
William J. DALLY : Media Processing Applications on the Imagine Stream Processor. Proceedings of the
2002 International Conference on Computer Design, 2002. Disponible sur : http://www.iccd-conference.org/
proceedings/2002/17000295.pdf. 37, 46
[Owe04] John OWENS : GPUs : Engines for Future High-Performance Computing. 2004. Disponible sur : http:
//www.ece.ucdavis.edu/~jowens/talks/owens-hpec04-gpgpu.pdf. [rf. du : 12 jul 2005]. Format PDF. 2004.
22, 23
[Pel93] Susanna PELAGATTI : A methodology for the development and the support of massively parallel programs.
Thse de doctorat, Dipartimento di Informatica, Universita di Pisa, mars 1993. Disponible sur : ftp://ftp.di.
unipi.it/pub/Papers/susanna/thesis.ps.gz. [rf. du : 12 oct 2005]. Format PS.GZ. 26
[PJ00] Stelian PERSA et Pieter JONKER : Real Time Image Processing Architecture for Robot Vision. 2000. Dis-
ponible sur : http://www.ph.tn.tudelft.nl/People/pieter/pdfs/stelian_PE_SPIE2000.pdf. [rf. du : 12 jul 2005].
Format PDF. 2000. 65
[Pri06] Marc PRIEUR : AMD Torrenza, co-proc pour Opteron. juin 2006. Disponible sur : http://www.hardware.fr/
news/imprimer/8194/. [rf. du : 06 jun 2006]. Format HTML. juin 2006. 194
[Rey06] John REYNOLDS : NVIDIAs GeForce 7800 GTX, preview. 2006. Disponible sur : http://www.simhq.com/
_technology/technology_056a.html. [rf. du : 06 feb 2006]. Format HTML. 2006. 43
[RM00] Jos B. T. M. ROERDINK et Arnold MEIJSTER : The Watershed Transform : Denitions, Algorithms and
Parallelization Strategies. Fundamenta Informaticae, 41:178228, 2000. 28
220
[RS01] Martin RUMPF et Robert STRZODKA : Using Graphics Cards for Quantized FEM Computations. Proceedings
VIIP01, pages 193202, 2001. 28
[Rys05] Ondrej RYSAVY : Specifying and reasoning in the calculus of objects. Thse de doctorat, Faculty of Infor-
mation Technology, Brno University of Technology, 2005. Disponible sur : http://www.t.vutbr.cz/research/
view_pub.php?id=7921. [rf. du : 7 may 2006]. Format HTML. 195
[Sas02] Raphal SASPORTAS : Etude darchitectures spciques aux applications danalyse dimage par morphologie
mathmatique. Thse de doctorat, Ecole Nationale Suprieure des Mines de Paris, octobre 2002. 28, 46
[SBJ96] Pierre SOILLE, Edmond J. BREEN et Ronald JONES : Recursive Implementation of Erosions and Dilations
along discrete lines at arbitrary angles. 1996. Disponible sur : http://citeseer.ist.psu.edu/96171.html. [rf. du :
06 jan 2005]. Format PDF, PS. 167
[SDR04] R. STRZODKA, M. DROSKE et M. RUMPF : Image Registration by a Regularized Gradient Flow- AStreaming
Implementation in DX9 Graphics Hardware. Computing, page 18, 2004. Disponible sur : http://numerik.math.
uni-duisburg.de/research/papers/public/DrRuSt04.pdf. Format PDF. 28
[Sei04] Chris SEITZ : Evolution of GPUs. Prsentation. Perfect Kitchen Art, 2004. 23
[Ser88] Jean SERRA : Image Analysis and Mathematical Morphology, Volume 2 : Theoretical Advances, volume 2.
Academic Press, 3rd dition, 1988. Centre de Morphologie Mathmatique, Ecole Nationale Suprieure des
Mines de Paris, France. 84
[Ser89] Jean SERRA : Image Analysis and Mathematical Morphology, Volume 1, volume 1. Academic Press, 3rd
dition, 1989. Centre de Morphologie Mathmatique, Ecole Nationale Suprieure des Mines de Paris, France.
84, 86
[Ser00] Jean SERRA : Cours de la morphologie mathmatique - Chapitre 6 : Connexion et fonctions numriques.
Prsentation. Cours de la morphologie mathmatique, 2000. 115
[Sho51] William SHOCKELEY : Circuit Element Utilizing Semiconductive Material. septembre 1951. Disponible
sur : http://www.bellsystemmemorial.com/pdf/02569347.pdf. [rf. du : 22 mar 2006]. Format PDF. septembre
1951. 23
[Ski92] D.B. SKILLICORN : The Bird-Meertens Formalism as a Parallel Model. Rapport technique, Department of
Computing and Information Science, Queens University, Kingston, Ontario, 1992. Disponible sur : http:
//ftp.qucis.queensu.ca/TechReports/Reports/1992-332.pdf. 27
[Ski98] David B. SKILLICORN : A Taxonomy for Computer Architectures. IEEE COMPUTER, 21(11):4657, no-
vembre 1998. Disponible sur : http://dx.doi.org/10.1109/2.86786. [rf. du : 12 jul 2005]. Format PDF. Dept.
of Comput. & Inf. Sci., Queens Univ., Kingston, Ont., Canada ; ISSN : 0018-9162. 27, 31
[Soi03] Pierre SOILLE : Morphological Image Analysis : Principles and Applications. Springer-Verlag, second edition
dition, 2003. Disponible sur : http://portal.acm.org/citation.cfm?id=773286. [rf. du : 07 mar 2006]. Format
citation HTML. 84, 85, 147, 167
[Spi03] John SPITZER : Graphics Performance Optimisation. Prsentation. GDCE 2003, 2003. Disponible sur : http:
//developer.nvidia.com/docs/IO/8343/Performance-Optimisation.pdf. [rf. du : 13 may 2006]. Format PDF.
183
[SRU01] Jurij SILC, Borut ROBIC et Theo UNGERER : Asynchrony in parallel computing : from dataow to multithrea-
ding. Progress in Computer Research, 1:133, 2001. Disponible sur : http://www.informatik.uni-augsburg.
de/~ungerer/JPDCPdataow.pdf. [rf. du : 29 mar 2006]. 47
[ST04] Robert STRZODKA et Alexandru TELEA : Generalized Distance Transforms and Skeletons in Graphics Hard-
ware. pages 221230, 2004. Disponible sur : http://numerik.math.uni-duisburg.de/research/papers/public/
StTe04skeletons.pdf. 28
[Sta06] William STALLINGS : Computer Organization and Architecture Designing for Performance. Pearson Prentice
Hall, seventh dition, 2006. 47, 48, 207
[Str02] R. STRZODKA : Virtual 16 Bit Precise Operations on RGBA8 Textures. VMV, page 9, novembre 2002. 28
[Str04] Robert STRZODKA : Hardware Efcient PDE Solvers in Quantized Image Processing. Thse de doctorat,
Universitaet Duisburg-Essen, 2004. Disponible sur : http://www.ub.uni-duisburg.de/ETD-db/theses/available/
duett-02242005-000216/unrestricted/Strzodkadiss2004.pdf. [rf. du : 19 jul 2005]. Format PDF. 23, 28, 38
[Sup02] SUPERH : SH-5 product brief, 2002. Disponible sur : http://www.superh.com. [rf. du : 15 dec 2002]. Format
PDF. document code : 05-PB-10001 V1.0. 43
[TBG
+
02] Xinmin TIAN, Aart BIK, Milind GIRKAR, Paul GREY, Hideki SAITO et Ernesto SU : Intel OpenMP
C++/Fortran Compiler for Hyper-Threading Technology : Implementation and Performance. In Intel Tech-
nology Journal (2002, Volume 06 Issue 01)
Int02
, pages 3646. Disponible sur : ftp://download.intel.com/
technology/itj/2002/volume06issue01/vol6iss1_hyper_threading_technology.pdf. [rf. du : 31 mar 2006]. For-
mat PDF. 50
221
[TC05] Pedro TRANCOSO et Maria CHARALAMBOUS : Exploring Graphics Processor Performance for General
Purpose Applications. 2005. Disponible sur : http://216.228.112.225:8080/t/340/703432/225/0/. [rf. du : 12
jul 2005]. Format PDF. 2005. 56
[To95] Hing Wing TO : Optimising the Parallel Behaviour of Combinations of Program Components. Thse de doc-
torat, University of London, Imperial College of Sciences, Technology and Medicine, Department of Com-
puting, septembre 1995. Disponible sur : http://hpc.doc.ic.ac.uk/environments/coordination/papers/hwt.ps.gz.
[rf. du : 18 oct 2005]. Format PS.GZ. 26
[TP05] Damien TRIOLET et Marc PRIEUR : NVIDIA GeForce 7800 GTX. juin 2005. Disponible sur : http://www.
hardware.fr/art/lire/574/. [rf. du : 9 mar 2006]. Format HTML. juin 2005. 22, 43
[Tra05a] TRANSMETA : Crusoe : Architecture, 4 Instruction Issue, 128-bit VLIW Engine. 2005. Disponible sur :
http://www.transmeta.com/crusoe/vliw.html. [rf. du : 15 mar 2006]. Format HTML. 2005. 37, 42
[Tra05b] TRANSMETA : Efceon : Architecture, High Performance 8 Instruction Issue, 256-Bit VLIW Engine. 2005.
Disponible sur : http://www.transmeta.com/efceon/vliw.html. [rf. du : 15 mar 2006]. Format HTML. 2005.
37, 42
[Tra05c] TRANSMETA : Efceon Model TM8800 Processor - Specications. 2005. Disponible sur : http://www.
transmeta.com/efceon/efceon_tm8800.html. [rf. du : 20 mar 2006]. Format HTML. 2005. 43, 44
[Tur37] A. M. TURING : Computability and -Denability. Journal of Symbolic Logic, 2(4):153163, dcembre
1937. 59
[Unk06] Author UNKNOWN : Eleven Reasons to use Haskell as a Mathematician. janvier 2006. Disponible sur : http:
//sigfpe.blogspot.com/2006/01/eleven-reasons-to-use-haskell-as.html. [rf. du : 17 feb 2006]. Format HTML.
janvier 2006. 60
[Ven03] Suresh VENKATASUBRAMANIAN : The Graphics Card as a Stream Computer. SIGMOD-DIMACS Workshop
on Management and Processing of Data Streams, 2003. Disponible sur : http://www.research.att.com/~suresh/
papers/mpds/mpds.pdf. [rf. du : 31 jul 2005]. Format PDF. 56
[vH92] Marcel van HERK : Afast algorithmfor local minimumand maximumlters on rectangular and octagonal ker-
nels. Pattern Recogn. Lett., 13(7):517521, 1992. Disponible sur : http://dx.doi.org/10.1016/0167-8655(92)
90069-C. [rf. du : 28 mar 2006]. Format PDF. 167, 168
[Wik05a] WIKIPEDIA : Instructions per second. octobre 2005. Disponible sur : http://en.wikipedia.org/wiki/Million_
instructions_per_second. [rf. du : 14 nov 2005]. Format HTML. octobre 2005. 43
[Wik05b] WIKIPEDIA : Lambda calcul. 2005. Disponible sur : http://fr.wikipedia.org/wiki/Lambda-calcul. [rf. du : 14
oct 2005]. Format HTML. 2005. 59
[Wik05c] WIKIPEDIA : Pseudocode. 2005. Disponible sur : http://en.wikipedia.org/wiki/Pseudocode. [rf. du : 14 oct
2005]. Format HTML. 2005. 26
[Wik05d] WIKIPEDIA : Thse de Church-Turing. 2005. Disponible sur : http://fr.wikipedia.org/wiki/Thse_de_
Church-Turing. [rf. du : 14 oct 2005]. Format HTML. 2005. 59
[Wik06a] WIKIPEDIA : Abou-Jafar-Muhammad-Ibn-Musa-al-Khuwarizmi. 2006. Disponible sur : http://fr.wikipedia.
org/wiki/Al-Khwarizmi. [rf. du : 30 apr 2006]. Format HTML. 2006. 177
[Wik06b] WIKIPEDIA : Algbre. 2006. Disponible sur : http://fr.wikipedia.org/wiki/Algbre. [rf. du : 10 may 2006].
Format HTML. 2006. 177
[Wik06c] WIKIPEDIA : Currycation. 2006. Disponible sur : http://fr.wikipedia.org/wiki/Currycation. 2006. 61
[Wik06d] WIKIPEDIA : Dhrystone. 2006. Disponible sur : http://en.wikipedia.org/wiki/Dhrystone. [rf. du : 04 apr
2006]. Format HTML. 2006. 205
[Wik06e] WIKIPEDIA : Donald Ervin Knuth. 2006. Disponible sur : http://fr.wikipedia.org/wiki/Donald_Knuth. [rf.
du : 30 apr 2006]. Format HTML. 2006. 178
[Wik06f] WIKIPEDIA : FLOPS. novembre 2006. Disponible sur : http://en.wikipedia.org/wiki/FLOPS. [rf. du : 14
nov 2005]. Format HTML. novembre 2006. 205
[Wik06g] WIKIPEDIA : Haskell Brooks Curry. 2006. Disponible sur : http://en.wikipedia.org/wiki/Haskell_Curry. [rf.
du : 9 apr 2006]. Format HTML. 2006. 60
[Wik06h] WIKIPEDIA : Multimdia. janvier 2006. Disponible sur : http://fr.wikipedia.org/wiki/Multimedia. [rf. du :
16 feb 2006]. Format HTML. janvier 2006. 29, 43, 206
[Wik06i] WIKIPEDIA : PlayStation 3. 2006. Disponible sur : http://en.wikipedia.org/wiki/PS3. [rf. du : 14 mar 2006].
Format HTML. 2006. 37, 43
[Wik06j] WIKIPEDIA : Processus lger. 2006. Disponible sur : http://fr.wikipedia.org/wiki/Thread. [rf. du : 30 mar
2006]. Format HTML. 2006. 47
222
[Wik06k] WIKIPEDIA : Wikipedia. 2006. Disponible sur : http://fr.wikipedia.org/wiki/Wikipdia. [rf. du : 22 apr
2006]. Format HTML. 2006. 29
[Wik06l] WIKIPEDIA : XBOX 360. 2006. Disponible sur : http://en.wikipedia.org/wiki/Xbox_360. [rf. du : 14 mars
2006]. Format HTML. 2006. 37, 43
[Wil94] Herbert S. WILF : Algorithms and Complexity. 1st dition, 1994. Disponible sur : http://www.math.upenn.
edu/~wilf/AlgoComp.pdf. [rf. du : 22 apr 2006]. Format PDF. University of Pennsylvania, Philadelphia. 178,
179
[Wlo03] Matthias WLOKA : Batch, Batch, Batch : What Does It Really Mean ? Prsentation. Game Developers Confe-
rence 2003, 2003. Disponible sur : http://developer.nvidia.com/docs/IO/8230/BatchBatchBatch.ppt. [rf. du :
13 may 2006]. Format PPT. 187
[WNDS99] Mason WOO, Jackie NEIDER, Tom DAVIS et Dave SHREINER : OpenGL Programming Guide. Addison-
Wesley, third edition dition, octobre 1999. 51, 54, 55
[Yan97] Jin YANG : Co-ordination Based Structured Parallel Programming. Thse de doctorat, University of London,
Imperial College of Sciences, Technology and Medicine, Department of Computing, octobre 1997. Disponible
sur : http://hpc.doc.ic.ac.uk/environments/coordination/papers/jy.ps. [rf. du : 18 oct 2005]. Format ps. 26, 73
[YW02] Ruigang YANG et Greg WELCH : Fast Image Segmentation and Smoothing Using Commodity Graphics
Hardware. Journal of Graphics Tools, 2002. Disponible sur : http://www.cs.unc.edu/~stc/publications/Yang_
jgt22003.pdf. [rf. du : 12 jul 2005]. Format PDF. 2002. 28
223
Index
Symbols
++, fonction . . . 62, 76, 91, 104, 107, 109, 116, 133, 136, 137,
152, 170
:, fonction 6264, 88, 103, 107, 109, 116, 133, 136, 138, 150,
151, 199
$, fonction . . . . . . . . . . . . . . . . . . . 6062, 6872, 75, 76, 8183,
90, 91, 94, 100, 102, 104, 107, 109, 114, 116, 122,
132, 133, 135140, 147149, 152, 153, 157, 167,
169, 171173, 199, 202, 203
, fonction. . . . . . . 62, 66, 68, 76, 83, 100, 104, 107, 109, 114,
132, 136140, 147149, 152, 153, 157, 167, 169,
171173, 182, 199
\\, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
1D, q.v. Liste de termes et dabrviations . 39, 68, 70, 72, 202,
208
2D, q.v. Liste de termes et dabrviations . . . . . 23, 39, 46, 51,
53, 57, 65, 6870, 72, 73, 7780, 84, 85, 100, 101,
108, 131, 132, 134, 135, 145, 165, 202, 205, 208
3D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3D, q.v. Liste de termes et dabrviations . . . . . 21, 22, 39, 51,
5355, 57, 7779, 81
A
ADCIS SA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
add, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Advanced Micro Devices, Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
AGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184, 209
AGP, q.v. Liste de termes et dabrviations . . . . . . . . . 183, 186
Alf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
algoHGWFst, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . 171173
algoHGWFstSIMD, fonction . . . . . . . . . . . . . . . . . . . . . 173, 174
algoHGWSndSIMD, fonction . . . . . . . . . . . . . . . . . . . . 173, 174
alter, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . 133, 134, 136139
AltiVec, marque commerciale dpose . . . . . . . . . . . . . . . . 2, 21
ALU, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . 46
AMD Athlon, marque commerciale dpose . . 2, 43, 185, 209
AMD Opteron, marque commerciale dpose. . . . . . . . . 2, 194
AMD64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
AMD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42, 65
AMD, marque commerciale dpose . 2, 21, 49, 134, 145, 194
Amerinex Applied Imaging, Inc. . . . . . . . . . . . . . . . . . . . . . . . . . 2
Aphelion, marque commerciale dpose . . . . . . . . . . . . . 2, 124
API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55, 186
API, q.v. Liste de termes et dabrviations . 14, 50, 51, 53, 54,
186, 187, 193
Ar, type . . . . . . . . . . . 65, 66, 6870, 72, 75, 77, 78, 80, 84, 89,
90, 92, 95, 100, 102, 104, 105, 107, 109, 113118,
128, 129, 131134, 140, 141, 152154, 156, 157,
167, 169173, 201, 202
ARB Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
ARB Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
ARB, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . 55
ARM Limited. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
ARM11, marque commerciale dpose. . . . . . . . . . . . . . . . 2, 43
ARM, marque commerciale dpose . . . . . . . . . . . . . . . . . . 2, 49
Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
array, fonction du Haskell . . . . . . . . . 65, 69, 71, 101, 107, 151
Array, type du Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
arrayFromMxNBlocs, fonction . . . . . . 131, 132, 140, 152, 172
arrayToMxNBlocs, fonction . . . . . . . . 131, 132, 140, 152, 172
ASIC, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . 37
ATI Technologies Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
ATI, marque commerciale dpose. . . . . . . . . . . . 2, 43, 51, 121
B
Basic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Bell Labs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
blending, q.v. Liste de termes et dabrviations . . . 28, 54, 119
Bool, type du Haskell . . . . . . . . . . . . . . . . . . . . . 63, 68, 154, 203
BorderFnc, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
bounds, fonction du Haskell . . . . . . . 68, 69, 71, 72, 75, 76, 81,
90, 91, 94, 100, 102, 104, 107, 109, 114, 116, 135,
137139, 152, 157, 169, 171, 202, 203
brcc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
BroderFnc, type . . . . . . . . . . . . . . . . . . . . . . . . . . 8991, 171173
Brook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56, 57, 194
brt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
C
C++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50, 60
c3e, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78, 201
c4e, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78, 201
C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55, 56, 60, 141
C, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7781, 201, 202
cBorder, fonction . . . . . . . . . . . . . . . . . . . 89, 101, 102, 105, 114
cBorderSIMD, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
CCD, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . 46
CElmnt, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 78, 201
Cg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Char, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Char, type du Haskell . . . . . 70, 72, 75, 92, 129, 132, 139, 140,
152154, 157, 169171
CI, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7779, 202
CISC, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . 39
CMOS, q.v. Liste de termes et dabrviations . . . . . . . . . 35, 46
CMP, q.v. Liste de termes et dabrviations . . . . . . . . . . . 48, 49
CMT, q.v. Liste de termes et dabrviations . . . . . . . . . . 48, 49
cndmoveSIMD, fonction . . . . . . . . . . . . . . . . 154, 157, 158, 203
Commands, type . . . . . . . . . . . . . . . . . . . . . . . 77, 80, 81, 83, 122
225
Coq. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
CPU, q.v. Liste de termes et dabrviations . . . . 22, 46, 47, 56
CrossFire, marque commerciale dpose . . . . . . . . . . . . . . 2, 51
Crusoe, marque commerciale dpose. . . . . . . . . . . . . . . . . 2, 42
curry, fonction du Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
currycation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
D
dc, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67, 68, 141
dilHEXR, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102, 181
dilIBHEXR, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
dilIBSQR, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
dilSQR, fonction . . . . . . . . . . . . . . . . . . . . . . . 101, 102, 167, 181
dilSQRHomothetic, q.v. Liste de termes et dabrviations 167
dilSQRHomothetic, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . 167
dilSQRSIMD, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
dimsAr1D, fonction . . . . . . . . . . . . . . . . . . . . . . . . . 133, 134, 202
dimsAr2D, fonction. . . . . . . 128, 129, 131, 140, 152, 172, 202
DirectX9, marque commerciale dpose . . . . . . . . . . . . . . . . . 57
DirectX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
DirectX, marque commerciale dpose . . . 2, 54, 55, 186, 187
div, fonction du Haskell . . . . . . . 68, 69, 75, 92, 131, 133, 134,
137140, 152, 171, 172
DMIPS, q.v. Liste de termes et dabrviations . . . . . . . . . . . . 43
Dpth, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7780, 202
E
Efceon, marque commerciale dpose . . . . . 2, 21, 37, 4244
elems, fonction du Haskell . 94, 132, 135, 140, 141, 152, 157,
158, 172, 203
Env, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 8083, 122, 202
extract, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91, 92, 208
extrBNgbHEXR, fonction . . . . . . . . . . . . . . . . . . . . . . . . . 91, 105
extrBNgbSQR, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . 91, 105
extrINgbHEXR, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . 91, 105
extrINgbSQR, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 91, 105
extrNgb, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90, 91
ExtrNgb, type . . 9092, 95, 100, 101, 104, 107, 113, 116, 118
extrNgbHEXR, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . 91, 102
ExtrNgbSP, type . . . . . . . . . . . . . . . . . . . . . . . . 95, 109, 115, 117
extrNgbSQR, fonction . . . . . . . . . . . . . . . . . . . . . . . . 91, 101, 102
extrNgbSQRSIMD, fonction. . . . . . . . . . . . . . . . . . . . . . . 92, 114
F
F, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 79, 8183, 202
farm, fonction . . . . . . . . . . . . . . . . . . . 67, 71, 120, 141, 182, 194
FB, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 80, 81, 83, 202
FBO, type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 80
lter, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
FLOPS, q.v. Liste de termes et dabrviations . . . 42, 205, 206
fncDistanceSQR4, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
foldl1, fonction. . . . . . . . . . . . . . . . . . . . . . . . . 62, 76, 92, 94, 109
foldl1, fonction du Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
foldl, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63, 83
foldl, fonction du Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
foldr1, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62, 63, 66
foldr, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Fortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
fpDilate, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
fpDilateSQR4, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
FPGA, q.v. Liste de termes et dabrviations . . . . 37, 163, 194
fpid, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
fprocessor, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . 8183, 120
FProg, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8183, 122
fps, q.v. Liste de termes et dabrviations . . . . . . . . . . 186, 187
fpTexture, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
fragment, q.v. Liste de termes et dabrviations . . . . . . . . . . . 23
fst, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
G
G5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
GeForce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121, 123, 124
GeForce, marque commerciale dpose . . . . . . . 2, 22, 57, 125,
184186, 208, 209
getArFromTX, fonction. . . . . . . . . . . . . . . . . . . . . . . . 78, 81, 201
getFB, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80, 83, 202
getTXBFromTX, fonction. . . . . . . . . . . . . . . . . . . . . . 78, 81, 201
getTXs, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80, 122, 202
GFLOPS, q.v. Liste de termes et dabrviations . . . . . . . . . . 22
GLSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Go. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Go, q.v. Liste de termes et dabrviations . . . . . . 183, 185, 209
GPGPU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
GPGPU, q.v. Liste de termes et dabrviations . . . 55, 56, 183,
187, 188
GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54, 57
GPP, q.v. Liste de termes et dabrviations 12, 14, 2022, 24,
37, 42, 43, 46, 47, 51, 54, 55, 57, 68, 99, 112, 114,
115, 119, 121, 123125, 132, 179, 180, 183187,
192194, 208, 209, 211
GPPMM, q.v. Liste de termes et dabrviations . . . . . . . 12, 14,
21, 37, 40, 42, 43, 50, 68, 112, 113, 115, 125, 133,
134, 179, 180, 187, 194, 208, 211
GPU, q.v. Liste de termes et dabrviations . . . 11, 12, 14, 15,
2124, 40, 42, 43, 51, 5357, 7683, 99, 118125,
183187, 192195, 202, 205, 206, 208, 209, 211
gpuDilate, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
gpuDilateGPUSQR4, fonction. . . . . . . . . . . . . . . . . . . . . . . . . 122
gpuTexture, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121, 122
H
HAL, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . 42
Haskell98 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60, 61
Haskell . . . . 7, 9, 12, 44, 55, 5966, 68, 70, 71, 73, 75, 77, 83,
84, 88, 89, 102, 132, 135, 150, 158, 167, 171, 192,
194, 199, 225229
HDTV, q.v. Liste de termes et dabrviations. . . . . . . . . . . . . 46
HGW, q.v. Liste de termes et dabrviations. . . 168172, 174,
176
hilevelSQR4, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . 157, 158
Hitachi Ltd. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
HLSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Hyper-Threading Technology . . . . . . . . . . . . . . . . . . . . . . . . . . 48
I
I, type . . . . . . . . . . . . . . . . . . . . . . . 6466, 6870, 72, 7580, 84,
8892, 94, 95, 100, 102105, 107, 109, 113118,
128, 129, 131134, 136141, 152154, 156, 157,
167, 169173, 192, 201203
IA-32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41, 160, 173, 174
IA-64. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41, 65, 134, 145
IBM, marque commerciale dpose . . . . . . . . . . . . . . . . . . . 2, 41
ICC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
ICC, marque commerciale dpose . . . . . . . . . . . . . . . . . . . . 181
226
Jaromr BRAMBOR INDEX
ICL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173, 174
id, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61, 71
id, fonction du Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61, 71
IEEE, marque commerciale dpose . . . . . . . . . . . . . . . . . . 2, 19
ielems, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133, 134
Ikonas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Imagine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37, 46, 194
inbounds2D, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
indices, fonction du Haskell . . . . . . . . . . . . . . 71, 102, 114, 171
inRange, fonction du Haskell . . . . . . . . . . . . . . . . . . . . . . 90, 102
Int, type du Haskell . . . . . . . . . . . . . . . . . . . . 64, 66, 77, 137, 199
Intel Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2, 19
Intel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50, 65, 124
Intel, marque commerciale dpose. . . . . 2, 1922, 41, 43, 44,
48, 49, 57, 123, 125, 134, 141143, 145, 148, 160,
161, 173175, 181, 184, 186, 207209, 211
International Business Machines Corporation . . . . . . . . . . . . . 2
International Technology Roadmap for Semiconductors . . . 23
IPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Itanium, marque commerciale dpose. . . . . . . . . . . . . 2, 41, 43
iterate, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167, 199
Ix, classe du Haskell . . . . . . . . . . . . . . . . . . . . . . . 75, 89, 90, 133
J
Java. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
K
Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
ko, q.v. Liste de termes et dabrviations . 123, 124, 143, 160,
161, 174, 175, 181, 206, 209
L
Lambda calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5961, 192, 195
lambda calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7, 99
lambda calculus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
last, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167, 199
levelSQR4, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
levelSQR4, fonction du Haskell . . . . . . . . . . . . . . . . . . . . . . . 157
Line, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 79
Linus Torvalds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Linux, marque commerciale dpose . . . 2, 55, 143, 160, 161,
181, 186, 187
LISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44, 59
listArray, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
listArray, fonction du Haskell71, 94, 132135, 140, 152, 157,
158, 171, 172, 203
listDivAlter, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136139
Loi de Moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19, 2224
lolevelSQR4, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . 157, 158
LPE, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . . 99
Lx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
M
Mandrake . . . . . . . . . . . . . . . . . . . . . . . . . 143, 160, 161, 181, 186
map2, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158, 203
map, fonction . . . . . . . . . . . . . . . . . . . . 62, 67, 68, 70, 71, 75, 76,
82, 88, 91, 92, 100, 104, 107, 109, 116, 122, 132,
136140, 152, 157, 169, 171, 172, 194, 203
map, fonction du Haskell . 67, 70, 76, 100, 101, 132, 141, 182
MATLAB, marque commerciale dpose . . . . . . . . 2, 123, 124
max, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
max, fonction du Haskell . . . . . . . . . . . . . . . . . . . . . . . 92, 94, 103
maxSIMD, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94, 157
Mesa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54, 55, 186
MFLOPS, q.v. Liste de termes et dabrviations . . . . . 43, 205
mfoldl1, fonction. . . . . . . . . . . . . . 150152, 159, 163, 169, 208
mfoldl, fonction . . . . . . . . . . 150, 151, 158, 159, 163, 169, 208
Microsoft Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Microsoft Press, marque commerciale dpose . . . . . . . . . . . . 2
Microsoft, marque commerciale dpose 2, 37, 43, 54, 55, 60,
174, 186
MIMD, q.v. Liste de termes et dabrviations . . 31, 33, 39, 49
min, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
min, fonction du Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . 94, 103
minSIMD, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . 94, 154, 157
MIPS, q.v. Liste de termes et dabrviations. . . . . . 42, 43, 205
Miranda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
MISD, q.v. Liste de termes et dabrviations . . . . . . 31, 33, 34
mkAr1DFromAr1DPVec, fonction . . . . . . . . . . . . . . . . . . . . . . 70
mkAr1DPVec, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
mkAr2DFromAr2DPVec, fonction. . . . 70, 140, 152, 157, 158
mkAr2DFromAr2DPVecByFst, fonction . . . . . . . . . . . . . . . . 70
mkAr2DFromAr2DPVecBySnd, fonction . . . . . . . . . . . 70, 173
mkAr2DPVec, fonction . . . . . . . . . . . . . . 70, 140, 152, 157, 158
mkAr2DPVecByFst, fonction . . . . . . . . . . . . . . . . . . . . . . . 69, 70
mkAr2DPVecBySnd, fonction . . . . . . . . . . . . . . . . . . 69, 70, 173
mkEnv, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80, 202
mkF, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79, 122, 202
mkTX, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78, 201
mkV, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79, 202
ML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
MMX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65, 142
MMX, marque commerciale dpose2, 21, 44, 134, 142, 143,
148, 160
Mo, q.v. Liste de termes et dabrviations . 21, 183, 184, 186,
187, 209
Morphe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123, 124
MorphoMedia . . . . . . . . . . . . . . 42, 65, 141, 142, 159, 207, 208
Motorola, Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
MOTOROLA, marque commerciale dpose . . . . . . . . . . 2, 21
MPCore, marque commerciale dpose. . . . . . . . . . . . . . . . . . 43
MrphMedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
MT, q.v. Liste de termes et dabrviations . . . . . . . . . . . . 47, 50
multithread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
N
nD, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . . . 68
Ngb, type . . . . . . . . . . 88, 91, 92, 102, 103, 105, 114, 122, 167
ngbAlgo, fonction . . . . . . . . . . . . . 100102, 113, 181, 182, 208
ngbAlgoGen, fonction . . . . . . . . . . . . . . . . . . 106109, 113, 208
ngbAlgoGenSIMD, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . 113
ngbAlgoGenSP, fonction . . . . . . . . . . . . . . . . . . . . . . . . . 109, 115
ngbAlgoGenSPSIMD, fonction. . . . . . . . . . . . . . . . . . . . . . . . 115
ngbAlgoIB, fonction . . . . . . . . . . . . . . . 103105, 107, 113, 208
ngbAlgoIBSIMD, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
ngbAlgoSIMD, fonction . . . . . . . . . . . . . . . . . . . . . . . . . 113, 114
ngbBB, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
ngbBB, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103, 105
ngbDilate, fonction . . . . . 92, 94, 101, 102, 105, 109, 114, 122
ngbDilateSIMD, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
ngbErode, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
ngbErodeSIMD, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
ngbGAlgoGen, fonction . . . . . . . . . . . . . . . . . . . . . 116118, 208
227
ngbGAlgoGenSIMD, fonction . . . . . . . . . . . . . . . . . . . . 117, 118
ngbGAlgoGenSP, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
ngbGDilate, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
ngbGErode, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
NgbGOp, type . . . . . . . . . . . . . . . . . . . . . . . . . . 94, 115, 116, 118
NgbGOpSP, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
NgbOp, type . . . . . . . . . . . . . . . . . 92, 94, 95, 100, 104, 107, 113
NgbOpSP, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95, 109, 115
ngbSQR4, fonction . . . . . . . . . . . . . . . . . . . . . . . 88, 92, 101, 114
ngbSQR4WC, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
ngbSQR6, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88, 89
not, fonction du Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
NVIDIA Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
NVidia Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22, 23
NVIDIA Quadro, marque commerciale dpose . . . . . . . . . . . 2
NVidia Quadro, marque commerciale dpose . . . . . . 185, 186
NVidia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23, 121, 123, 124, 207
NVidia, marque commerciale dpose . . 2, 22, 43, 51, 55, 57,
125, 184187, 207209
O
OpenGL ES, marque commerciale dpose . . . . . . . . . . . . 2, 54
OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55, 205
OpenGL, marque commerciale dpose2, 54, 55, 57, 186, 187
OpenMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Ord, classe du Haskell89, 91, 92, 94, 102, 105, 114, 152, 153,
167, 169, 170
P
p2D, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78, 201
p3D, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78, 201
P, type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7780, 201, 202
Pascal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
PC, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . . . 24
PCI Express, marque commerciale dpose . 2, 183, 185, 186,
209
PCI-SIG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Pentium 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Pentium, marque commerciale dpose . . . . . . . . . . . . . . . 2, 41,
43, 48, 57, 123, 125, 142, 143, 160, 161, 174, 181,
184, 186, 208, 209
pGen, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152, 153
pGenMB, fonction . . . . . . . . . . . . . . . . . 151, 152, 163, 169, 170
phase1, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170172
phase2, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170172
phase3Gen, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170172
phaseHGW, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169, 170
pipe, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . 66, 137139, 207
pipeGPU, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83, 122
pipeline graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Pixar Animation Studios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2, 55
Platform 2015 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
PlayStation, marque commerciale dpose . . . . . . . . . 2, 37, 43
Point, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 79
Pos, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 78, 201
POSIX, marque commerciale dpose . . . . . . . . . . . . . . . . 2, 50
PowerPC, marque commerciale dpose . . . . . . . . . . . 2, 41, 43
propAlgSQR4, fonction . . . . . . . . . . . . 153, 154, 157, 158, 163
pvec, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . 65, 68, 69, 91, 201
PVec, type . . . . . . . . . . . . . . . . . . . . . . . 65, 66, 6870, 77, 78, 89,
91, 92, 94, 112115, 118, 133, 134, 136141, 152,
153, 172, 192, 202, 203
PX, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 80
Python. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44, 55
R
Radeon, marque commerciale dpose . . . . . . . . . . . . . . . . 2, 43
range, fonction du Haskell . . . . . . . . . . 68, 69, 75, 76, 131, 133
rangeSize, fonction du Haskell . . . . . . . . 72, 75, 114, 137139
rasterize, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Rasterizer, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82, 83
Rect, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 79
refreshFB, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80, 83
RenderMan, marque commerciale dpose . . . . . . . . . . . . 2, 55
RISC, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . 39
rot2DMinus90, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
rot2DMinus90MB, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . 133
rot2DMinus90NxPVecNbf, fonction . . . . . . . . . . . . . . . . . . . 139
rot2DMinus90NxPVecNb, fonction. . . . . . . . . . . . . . . . . . . 139
rot2DPlus90, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 128, 129
rot2DPlus90MB, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
rot2DPlus90NxPVecNbf, fonction. . . . . . . . . . . . . . . . . 138, 139
rot2DPlus90NxPVecNb, fonction . . . . . . . . . . . . . . . . 138, 139
rpid, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
rprocessor, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . 81, 83, 119
RProg, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81, 83
S
sampB, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90, 91, 102
SampFnc, type . . . . . . . . . . . . . . . . . . . . . . . . . . . 8992, 115, 116
SampFncSP, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
sampFncSP, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
SampFncSP, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75, 117
sampGen, fonction . . . . . . . . . . . . . . . . . . 90, 102, 114, 170, 171
sampI, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90, 91, 102
Sampler, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
sampSPGen, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75, 76
scanl1, fonction du Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
scanl, fonction du Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
seqPow2, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137139
SH-5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38, 40, 41, 43, 134, 159
Shape, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 7982
shfhi, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134, 136139
sho, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . 133, 134, 136139
SHmedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65, 145, 148
Silicon Graphics Incorporated . . . . . . . . . . . . . . . . . . . . . . . . 2, 54
SIMD12, 25, 99, 113115, 117, 131, 140, 142, 145, 147150,
152, 153, 156, 157, 160, 163, 166, 168176, 180,
181, 191, 193, 208
SIMD, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . 7,
9, 12, 13, 15, 26, 31, 3335, 39, 43, 50, 64, 68, 78,
89, 91, 94, 112115, 118, 123, 125, 127, 133135,
140143, 145, 147, 148, 151, 153, 158, 160, 163,
172174, 181, 191, 193, 202, 208
SISD, q.v. Liste de termes et dabrviations . . . . . . . . . . 3134
SKIZ, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . 99
SLI, marque commerciale dpose. . . . . . . . . . . . . . . . . . . . 2, 51
smpBorder, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81, 122
SMT, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . 48
snd, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Sony Corporation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Sony, marque commerciale dpose . . . . . . . . . . . . . . . 2, 37, 43
SpecNgb, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88, 90, 91
specNgbHEXR, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . 88, 91
228
Jaromr BRAMBOR INDEX
specNgbSQR, fonction . . . . . . . . . . . . . . . . . . . . . . . . 88, 91, 122
SPMD, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . 33
SSE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142, 143, 148, 160, 208
SSE3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44, 141, 148
SSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44, 148
ST200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
STMicroelectronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5, 37, 42
streamAr1D, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
streamAr2D, fonction . . . . . . . . . . . . . . . . 7274, 151, 152, 169
StreamAr2DSP, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
streamAr2DSP, fonction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7476
streamB, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
streamI, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Streamize, type . . . . . 72, 73, 75, 100, 104, 107, 113, 116, 118
StreamizeSP, type . . . . . . . . . . . . . . . . . . . . 75, 95, 109, 115, 117
Sun Microsystems, Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Sun, marque commerciale dpose . . . . . . . . . . . . . . . . . . . 2, 21
SuperH, marque commerciale dpose2, 21, 41, 43, 145, 148,
159
superpixel . . . . . . . . . . . . . . . . . . . . . 12, 7376, 94, 95, 114, 208
SWAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
SWAR, q.v. Liste de termes et dabrviations. 13, 50, 67, 112,
127, 131, 134, 180, 191
T
Taiwan Semiconductor Manufacturing Company, Ltd. . . . . . . 2
take, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167, 199
testSIMD, fonction. . . . . . . . . . . . . . . . . 154, 157, 158, 202, 203
texel, q.v. Liste de termes et dabrviations . . . . . 23, 120, 122
texels, q.v. Liste de termes et dabrviations. . . . . . . . . . . . . . 23
tfbo, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
The Institute of Electrical and Electronics Engineers, Incorpo-
rated. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
The MathWorks, Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Torrenza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
tr2DADiag, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128, 129
tr2DADiagMB, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
tr2DADiagNxPVecNbf, fonction . . . . . . . . . . . . . . . . . . . . . . 138
tr2DADiagNxPVecNb, fonction . . . . . . . . . . . . . . . . . . . . . . 138
tr2DDiag8x8bf1, fonction . . . . . . . . . . . . . . . . . . . 135137, 208
tr2DDiag8x8bf2, fonction . . . . . . . . . . . . . . . . . . . . . . . . 135137
tr2DDiag8x8bf3, fonction . . . . . . . . . . . . . . . . . . . . . . . . 135137
tr2DDiag8x8bf, fonction . . . . . . . . . . . . . . . . . . . . . . . . . 135, 136
tr2DDiag, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128, 129
tr2DDiagMB, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
tr2DDiagNxPVecNbf, fonction . . . . . . . . . . 137, 138, 159, 163
tr2DDiagNxPVecNb, fonction . . . . . . . . . . . . . . . . . . . 137, 138
Transmeta Corporation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Transmeta, marque commerciale dpose . . . 2, 21, 37, 42, 43
trRot2D, fonction . . . . . . . . . . . . . . . . . . 129, 131, 132, 140, 144
trRot2DMB, fonction. . . . . . . . . . . . . . . . . . . . . . . . 131133, 144
trRot2DMBSIMD, fonction . . . . . . . . . . . . . 140, 144, 153, 173
trRot2DNxPVecNbf, fonction. . . . . . . . . . . . . . . . . . . . . 139, 140
trRot2DNxPVecNb, fonction. . . . . . . . . . . . . . . . . . . . . . . . . 139
True, type du Haskell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
TSMC, marque commerciale dpose . . . . . . . . . . . . . . . . . 2, 22
TX, type . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 78, 80, 81, 201, 202
TXB, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 78, 201
TXI, type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 79, 202
TXP, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7779, 81, 202
U
unaLoadSQR, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91, 92
uncurry, fonction du Haskell . . . . . . . . . . . . . . . . . . 61, 136, 137
V
V, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77, 79, 81, 82, 202
vertex, q.v. Liste de termes et dabrviations . . . . . . . . . . 23, 53
VIS, marque commerciale dpose . . . . . . . . . . . . . . . . . . . 2, 21
VLIW, q.v. Liste de termes et dabrviations . . . 21, 37, 39, 42
VMT, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . 47
voxel, q.v. Liste de termes et dabrviations . . . . . . . . . . . . . . 51
vpid, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82, 122
vprocessor, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8183
VProg, type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8183
W
Wikimedia Foundation, Inc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Wikipedia, marque commerciale dpose. . . . . . . . . . . . . . 2, 29
Win32, marque commerciale dpose . . . . . . . . . . . . . . . . . 2, 50
Windows, marque commerciale dpose . 2, 55, 174, 186, 187
X
Xbox, marque commerciale dpose. . . . . . . . . . . . . . . 2, 37, 43
xchng, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138, 139
Z
zip, fonction . . . 63, 71, 76, 100, 104, 107, 109, 116, 136, 152,
169
zip, fonction du Haskell . . . . . . . . . . . . . . . 71, 76, 101, 137, 151
zipSP, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
ZipSP, type . . . . . . . . . . . . . . . . . . . . . . . . . . . 75, 76, 95, 109, 115
zipSPGen, fonction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75, 76
zipWith, fonction du Haskell . . . . . . . . . . . . . . . . . . . . . . . 94, 203
229

Brambor Doctoral Thesis

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Brambor Doctoral Thesis

Загружено:

Авторское право:

Доступные форматы

Collge doctoral

N attribu par la bibliothque

- bloc dunit centrale, MEM - bloc de la

(c) grille carre, lment structurant de 4 voisins, taille 1

, qui assurent mutuellement

) = pvec (1,3) [ (1, t

) = array (1,4) [ (1, t

) = pvec (1,3) [ (1, x

- bloc dunit centrale, MEM - bloc de la mmoire, BUS

- thread, DIV - phase

Вам также может понравиться