SKIZ isotrope

Le SKIZ isotrope [10], op´eration d´ej`a d´ecrite dans le chapitre 2, est une op´eration visant `

a calculer la zone d’influence de diff´erents constituants d’une image binaire et pouvant ˆetre utilis´e dans le calcul de la ligne de partage des eaux. Cette op´eration est it´erative et est compos´ee, `a chaque ´etape, d’une dilatation d’une image binaire labelis´ee suivie d’une ´etape de r´egularisation afin de bloquer les zones o`u les labels sont en collisions. La taille de la dilatation `a un impact sur la taille de la fronti`ere s´eparant les zones, et nous nous pla¸cons dans le cas de dilations de rayon unitaire.

La figure 4.45 pr´esente sur un exemple simple les deux ´etapes de l’algorithme, on constate qu’`a l’issue de la dilatation les formes ayant un label plus ´elev´e empi`etent sur les formes de labels inf´erieurs. L’´etape de r´egularisation corrige cet effet en bloquant les dilatations l`a o`u une fronti`ere entre les formes est minimale, c’est-`a-dire l`a o`u la fronti`ere correspond au rayon de la dilatation.

Nous avons d´ej`a d´etaill´e le fonctionnement des op´erations d’´erosion et de dilatation au sein des processeurs vectoriels, nous allons donc voir comment mettre en place l’´etape de r´egularisation au sein de ces derniers. Cette ´etape prend en entr´ee l’image binaire labellis´ee f et l’image dilat´ee g = δ(f ) et renvoie l’image h r´egularis´ee. Pour tous les indices p des pixels de l’image, h peut alors s’´ecrire :

h(p) = (

0, si (f (p) 6= g(p)) ∧ (f (q) 6= 0) ∧ (f (q) 6= g(p))

g(p), sinon , avec q ∈ {Nf(p) ∪ p}

On remarque que pour calculer la r´egularisation il faut disposer `a la fois de l’image binaire labellis´ee et de l’image dilat´ee, ce qui nous oriente imm´ediatement vers l’utilisation d’un seul processeur pour r´ealiser la dilatation-r´egularisation. En effet la dilatation n´ecessite de proc´eder `a une extraction du voisinage de l’image source et la r´egularisation n´ecessite d’une part d’avoir `a disposition les voisinages de l’image source et d’autre part, de disposer du r´esultat de la dilatation. Il est donc possible de calculer toutes ces ´etapes dans un mˆeme processeur.

CHAPITRE 4. PROCESSEURS VLIW VECTORIELS

Un peu comme les op´erations g´eod´esiques, le SKIZ isotrope n´ecessite un grand nombre d’it´erations de dilatation-r´egularisation. Nous pouvons ainsi d´eployer dans notre r´eseau de processeurs arrang´es en s´erie, seize it´erations `a condition de ne pas oublier de mettre en place le calcul du volume juste avant la sortie des deux derniers processeurs pour disposer ainsi d’un crit`ere nous informant si un flot de calcul suppl´ementaire est n´ecessaire ou non. La difficult´e concernant la mise en œuvre de l’op´eration de r´egularisation consiste `a r´ealiser les tests sur le voisinage de f de mani`ere vectorielle. L’algorithme 12 d´ecrit le noyau de calcul `a mettre en place pour un ´el´ement structurant carr´e unitaire et suppose que tous les voisinages correspondant aux pixels d’une ligne sont extraits dans neuf tableaux. L’algorithme renvoie alors la ligne dilat´ee et r´egularis´ee. En r´ep´etant ce calcul sur toutes les lignes, on obtient une it´eration du SKIZ isotrope.

Algorithme 12 Noyau de calcul en ´etat permanent d’une it´eration du SKIZ isotrope avec un ´el´ement structurant carr´e unitaire

EN T R É E S: Dij avec i ∈ [0, 2], j ∈ [0, 2] SO R T I E S: δreg /* Dilatation */ tmp0 = infLigne(D00,D01) tmp0 = infLigne(tmp0,D02) tmp1 = infLigne(D10,D11) tmp1 = infLigne(tmp1,D12) tmp2 = infLigne(D20,D21) tmp2 = infLigne(tmp2,D22) δreg = infLigne(tmp0,tmp1)

δreg = infLigne(δreg,tmp2)

/* Régularisation */ cmp1 = compareLigne(D11,δreg) Pour i ∈ [0, 2], j ∈ [0, 2] Faire cmp2 = compareLigne(Dij,0) cmp3 = compareLigne(Dij,δreg) cmp3 = ouLigne(cmp3,cmp2) cmp3 = ouLigne(cmp3,cmp1) δreg = etLigne(cmp3,δreg) Fin pour

4.5

Conclusion

Le processeur pr´esent´e dans ce chapitre permet d’utiliser des vecteurs de fortes tailles et est principalement construit pour travailler sur quelques lignes d’une image mˆeme si des techniques de s´eparation des plans de bits d’une image permettent d’acc´eder `a une image binaire dans sa totalit´e en m´emoire locale.

L’unit´e de calcul vectoriel est int´eressante, car elle permet de simplifier la gestion du parall´elisme au niveau des instructions et il est alors juste n´ecessaire de correctement ordonnancer les acc`es m´emoire avec cette unit´e. En effet, nous savons qu’en traitement d’image, les mˆemes calculs sont toujours it´er´es sur tous les pixels de l’image, il est alors inutile de disposer d’un grand nombre d’unit´es de calcul ind´ependantes qui saturerait la file de registres en connexions.

La gestion de la m´emoire locale est simple puisque les deux clusters du processeur ont acc`es `a cette derni`ere et peuvent ainsi s’´echanger des donn´ees. Il serait certainement int´eressant de pr´evoir un lien plus rapide entre les deux clusters pour permettre `a l’unit´e scalaire de modifier un ´el´ement dans un vecteur. Nous avons pr´ef´er´e laisser de cˆot´e cette possibilit´e afin de ne pas alourdir le circuit avec des connexions suppl´ementaires, soit entre les deux files de registres, soit entre les unit´es de calcul vectoriel et scalaire.

CHAPITRE 4. PROCESSEURS VLIW VECTORIELS

La possibilit´e de disposer d’un flot de processeurs via un m´ecanisme de communication asynchrone nous permet de travailler `a plusieurs niveaux de granularit´e de fa¸con simple et performante. De plus, ce syst`eme nous laisse encore d’autres possibilit´es que nous n’avons pas explor´ees, notamment la possibilit´e de placer des points d’entr´ees de flux de pixels `

a n’importe quel ´etage du r´eseau de processeurs pour faciliter certains ordonnancements de calculs. Une piste ´egalement tr`es prometteuse serait de faire ´evoluer le m´ecanisme de connexion entre les cœurs vectoriels en employant un NoC type mesh [57], ce qui aurait pour effet d’augmenter le nombre de chemins de donn´ees du syst`eme et permettrait par la mˆeme de sp´ecifier simplement les points d’entr´ee et de sortie des diff´erents flux d’images.

Un processeur de taille moyenne compos´e d’une unit´e scalaire sur 32 bits et d’une unit´e vectorielle sur 512 bits avec une fr´equence de 100 Mhz nous permet d’atteindre une puis- sance de calcul brute de 6.4 GOPS lorsqu’on travaille avec des images 8 bits. Pour disposer d’une plus grande puissance de calcul, nous avons alors la possibilit´e, soit d’´elargir les vec- teurs, ce qui nous permettrait d’atteindre une puissance de 12.8 GOPS avec des vecteurs de 1024 bits, soit de raccorder en parall`ele et en s´erie un grand nombre de processeurs. Une structure compos´ee de 16 processeurs de 512 bits fonctionnant `a 100 Mhz d´elivre une puissance brute de 102 GOPS. On se rend alors bien compte des possibilit´es d’´evolution de notre processeur ce qui nous permet `a la fois de cibler des circuits FPGA ayant des ressources modestes ou alors des circuits ASIC avec de fortes possibilit´es d’int´egrations.

Une grande puissance de calcul n’est pas suffisante pour r´ealiser des applications de trai- tement d’images en temps r´eel. Il faut ´egalement disposer de m´emoires rapides permettant d’acheminer les pixels `a traiter rapidement au r´eseau de processeurs. Il est n´ecessaire qu’un syst`eme hˆote performant orchestrant, via des DMA et des m´emoires rapides, l’envoi et la r´eception d’images vers notre acc´el´erateur. Un parall´elisme massif est difficile `a alimenter, car le flux de pixels peut ˆetre tr`es important. La capacit´e de notre r´eseau de processeurs `

a exploiter un parall´elisme `a la fois spatial et temporel permet de relˆacher les contraintes qui p`esent sur le d´ebit m´emoire en entr´ee et en sortie de l’acc´el´erateur tout en conservant une puissance de calcul ´elev´ee.

Les diverses applications propos´ees dans ce chapitre montrent l’efficacit´e de la solution et la souplesse d’utilisation grˆace d’une part, au principe de traitement de voisinages par d´e- calage de lignes au sein d’un processeur vectoriel et d’autre part, au r´eseau de processeurs supportant des topologies de d´eploiements d’applications assez diff´erentes. Il reste tout de mˆeme une certaine difficult´e pour l’utilisateur devant programmer chacun des proces- seurs sp´ecifiquement pour chaque ´etape d’une application. Une perspective serait d’utiliser le syst`eme de g´en´eration automatique de flots d’op´erateurs mat´eriels pour le traitement d’images, pr´esent´e dans le chapitre 3, non plus pour g´en´erer une description mat´erielle d’un flot d’op´erateurs, mais pour g´en´erer le micro logiciel ex´ecut´e par chaque processeur du r´eseau.

Le prochain chapitre va nous permettre d’analyser finement les performances de notre machine VLIW vectorielle mais ´egalement les performances des pipelines de processeurs de voisinage d´etaill´es aux chapitres pr´ec´edents. Des politiques de comparaison sont d´efinis mettant `a la fois en avant des possibilit´es de parall´elisme spatial et temporel. Elles per- mettent de tester ´equitablement nos architectures avec des processeurs multicœurs et des acc´el´erateurs graphiques que l’on retrouve aujourd’hui dans le commerce.

Chapitre 5

Comparaison des diff´erentes

architectures

Dans les pr´ec´edents chapitres, nous avons pr´esent´e diff´erentes architectures d´edi´ees au traitement d’images avec pour chacune d’elles des degr´es diff´erents de programmabilit´e. En effet, nous avons commenc´e par d´ecrire dans le chapitre 2 la structure d’un processeur de voisinage flot de donn´ees qui est `a la fois limit´e par le type d’op´eration cˆabl´e et par la topologie du voisinage, ses deux param`etres ´etant d´ecrits souvent mat´eriellement.

Dans le chapitre 3, nous avons donc cherch´e `a produire, par un assemblage de proces- seurs de voisinage, de multiplexeurs et d’unit´es arithm´etiques et logiques, une architecture flot de donn´ees capable de calculer un plus grand nombre d’op´erations morphologiques. Une telle structure dispose de param´etrages plus avanc´ees, car il est possible de s´electionner `a la fois les chemins de donn´ees `a mettre en place et ´egalement les param`etres de calculs des diff´erents composants du pipeline.

Enfin, dans le chapitre 4, nous avons propos´e une architecture de processeur beaucoup plus g´en´eraliste disposant d’instructions vectorielles larges afin d’allier performance et g´e- n´ericit´e. Ce dernier syst`eme permet de r´ealiser efficacement un grand nombre d’op´erations de traitement d’images en r´e´ecrivant simplement du microcode pour les diff´erents pro- cesseurs qui composent l’architecture. Une telle souplesse permet ´egalement de viser des applications bas´ees sur d’autres corpus th´eoriques que la morphologie math´ematique.

Le leitmotiv de ces trois chapitres n’a donc cess´e d’ˆetre la recherche d’un maximum de programmabilit´e tout en sacrifiant au minimum les performances, mais nous pouvons nous demander quelles sont celles que nous pouvons esp´erer atteindre pour chaque degr´e de libert´e ainsi gagn´e. Nous proposons ici, au travers d’une politique de tests pr´ealablement d´efinie, de comparer les architectures pr´ec´edemment d´ecrites `a deux syst`emes couramment employ´es dans le domaine du calcul scientifique, `a savoir les processeurs multicœurs et les acc´el´erateurs 3D.