• Aucun résultat trouvé

2.4.1

Vue globale

Nous d´etaillons ici une nouvelle voie de traitement du parall´elisme avec les processeurs de voisinage. La m´ethode traditionnellement employ´ee pour traiter une image avec un plus fort parall´elisme consiste `a la d´ecouper en morceaux afin d’alimenter plusieurs processeurs en parall`ele. Ce principe est largement abord´e dans le chapitre 4 et n’est pas n´ecessaire- ment optimal notamment au niveau du d´ecoupage des imagettes puisqu’il est n´ecessaire de pr´evoir des zones de recouvrement `a cause du traitement de l’image par un voisinage.

Nous proposons dans cette section, ainsi que dans l’article [23], une autre m´ethode `a un grain beaucoup plus fin. En effet, s’il on consid`ere que le syst`eme alimentant le processeur de voisinage envoie les pixels group´es par paquets de n (ce qui est traditionnellement le cas avec les m´emoires employ´ees de nos jours), il est envisageable d’extraire n voisinages contigus par cycle et ainsi produire n pixels r´esultats par cycles. Le principe g´en´eral pr´esent´e en figure 2.47 n’est pas tr`es diff´erent de la structure standard d´ecrite pr´ec´edemment. Il est juste n´ecessaire de pr´evoir n unit´es de gestion des bords, n unit´es de calcul et un syst`eme d’extraction du voisinage modifi´e. Nous verrons ´egalement qu’il est possible de r´eduire

Fig. 2.46: Arbre de calcul de la reconstruction g´eod´esique

la quantit´e de ressources n´ecessaires, par exemple dans les unit´es de calcul, puisque des op´erations redondantes entre les voisinages contigus peuvent ˆetre regroup´ees.

Fig. 2.47: Structure g´en´erale d’un processeur de voisinage parall´elis´e

2.4.2

Extraction du voisinage

L’objectif est d’exploiter au maximum le d´ebit m´emoire amont, c’est-`a-dire que, si le syst`eme alimentant le processeur fournit n pixels contigus par cycle, il faut pouvoir exploiter

CHAPITRE 2. PROCESSEURS DE VOISINAGE FLOTS DE DONN ´EES

au maximum ce parall´elisme. S’il n’´etait pas exploit´e, il serait n´ecessaire de d´ecouper les paquets de pixels pour les traiter un `a un dans un processeur de voisinage standard et donc multiplier le temps de traitement par n.

L’exploitation du parall´elisme des donn´ees se fait donc en extrayant n voisinages connexes par cycle comme le montre la figure 2.48. On remarque qu’il est n´ecessaire de pr´evoir une zone de recollement entre deux cycles ce qui a pour effet d’ajouter un certain nombre de registres `a l’unit´e d’extraction du voisinage. Si l’on consid`ere des voisinages ayant N lignes et M colonnes il faut pr´evoir N · (M2 + 1) registres de recollement.

Fig. 2.48: Principe d’extraction parall´elis´e de voisinages contigus

Les lignes `a retard sont conserv´ees et leur capacit´e ne change pas, seule la taille des mots est modifi´ee pour correspondre au degr´e de parall´elisme n. Le nombre de registres n´ecessaires `a l’extraction des voisinages s’exprime de la mani`ere suivante :

f (n) = N · n + N · M 2 + 1



= N · n + N · M

2 + N

Si l’on ne consid´erait pas une extraction des voisinages contigus, il serait n´ecessaire d’utiliser le nombre de registres suivant :

g(n) = N · M · n

Afin de connaˆıtre la quantit´e de registres ´economis´ee, on peut ´ecrire la relation suivante : lim n→+∞h(n) = limn→+∞ f (n) g(n) = 1 M

Ainsi le nombre de registres n´ecessaires `a l’extraction de n voisinages connexes tend `a ˆetre M fois plus petit que le nombre de registres utilis´es pour l’extraction de n voisinages non connexes.

L’architecture d’une telle unit´e d’extraction est pr´esent´ee en figure 2.49, on retrouve les registres de recollement RBx, les registres RAx recevant les nouveaux paquets de pixels et les lignes `a retard Lx.

A chaque cycle les registres RAx re¸coivent n pixels en provenance de la ligne `a retard Lx ou, dans le cas de RA0, directement depuis l’entr´ee pixels. On conserve alors les M/2 +

Fig. 2.49: Structure d’un processeur de voisinage N × M parall´elis´e par n

1 valeurs du dernier voisinage dans les registres RBx afin de garantir un recouvrement correct lors du cycle suivant. Une cin´ematique est propos´ee en figure 2.50 dans le cas d’un extracteur de voisinage 3 × 3 parall´elis´e par 4.

Fig. 2.50: Exemple de processeur de voisinage 3 × 3 parall´elis´e par 4

Cette derni`ere figure montre ´egalement, dans le cas T0+ t + 2, les probl`emes de gestion

CHAPITRE 2. PROCESSEURS DE VOISINAGE FLOTS DE DONN ´EES

bords aux mˆemes instants, cet aspect est abord´e dans la section suivante.

Le fonctionnement des lignes `a retard n’est pas aussi simple qu’il y paraˆıt et il n’est pas uniquement n´ecessaire de changer la taille des mots m´emoire afin de les rendre compatibles avec notre extracteur de voisinage parall´elis´e. En effet, le nombre de mots m´emoire (un mot recevant n pixels) multipli´e par n doit ˆetre ´egal `a la taille de la ligne. En d’autres termes, sans modification de la structure des lignes `a retard, la taille d’une ligne doit ˆetre multiple de n. Si cette contrainte n’est pas respect´ee, l’extraction des voisinages ne sera pas correcte, car les lignes `a retard n’auront pas une taille suffisante pour m´emoriser une ligne. On observera alors un d´ecalage grandissant des voisinages extraits au fur et `a mesure que le processeur recevra de nouvelles lignes `a traiter.

La mani`ere la plus simple de s’affranchir de cette contrainte est d’ajouter aux lignes `

a retard le nombre de registres n´ecessaires pour obtenir une taille correspondante `a celle d’une ligne de l’image. Le nombre maximum de registres ainsi ajout´es sur la ligne `a retard ne peut pas exc´eder n − 1 et ces derniers sont ajout´es un `a un sur les sorties de la ligne `

a retard. Un exemple est pr´esent´e en figure 2.51 o`u l’on consid`ere une image 9 × 4, un voisinage 3 × 3 et une extraction parall´elis´ee d’ordre 4. Il est donc n´ecessaire d’ajouter un registre en sortie de la ligne `a retard au niveau du premier ´el´ement pour compl´eter la taille permettant d’atteindre une capacit´e de 9 pixels. Si les lignes de l’image avaient une taille de 10 pixels, il aurait fallu ajouter deux registres, un au niveau du premier ´el´ement et un autre au niveau du second.

Lorsque des registres sont ajout´es, on remarque qu’il est n´ecessaire de proc´eder `a un r´eordonnancement des ´el´ements (a1, b1, c1, d1, dans le sch´ema de la figure 2.51). Les registres ajout´es ont pour effet d’introduire un retard impliquant de rerouter ces signaux par rapport `a ceux ne disposant pas d’un tel registre. Ce reroutage d´epend de la taille de la ligne et du degr´e de parall´elisme. On peut tout `a fait imaginer de figer le degr´e de parall´elisme pour un processeur de voisinage, mais pour ˆetre suffisamment souple, ce dernier doit ˆetre capable de traiter plusieurs tailles de lignes. Il faut ainsi pr´evoir tous les registres en sortie des lignes `a retard ainsi que tous les chemins de donn´ees n´ecessaires `a leur activation, `a leur d´esactivation et au reroutage des donn´ees. Un tel syst`eme est pr´esent´e en figure 2.52 pour des mots de quatre pixels, mais peut ˆetre g´en´eralis´e `a des mots de taille n. La table de v´erit´e commandant les quatre multiplexeurs est propos´ee en 2.8. Elle permet de g´erer toutes les tailles de lignes pour un processeur de voisinage parall´elis´e par 4.

XX XX XX XX XX XX Nb. Reg. Mux ax bx cx dx 0 s1 s2 s3 s4 1 s2 s3 s4 s5 2 s3 s4 s5 s6 3 s4 s5 s6 s7

Tab. 2.8: Table de v´erit´e de s´election des registres de compl´ement de la ligne `a retard dans le cas d’un extracteur parall´elis´e de taille 4.

Une telle structure d’extraction de voisinage permet de r´eduire la latence d’une op´era- tion de voisinage. En effet la latence de ces op´erateurs de voisinage est traditionnellement

CHAPITRE 2. PROCESSEURS DE VOISINAGE FLOTS DE DONN ´EES

Fig. 2.52: Gestion des diff´erentes tailles de lignes pour un extracteur de voisinage parall´elis´e

due aux lignes `a retard fonctionnant pixel par pixel. Avec cette nouvelle structure la la- tence est environ divis´ee par n. Effectivement, mˆeme si la taille de la ligne `a retard n’a pas chang´ee, la taille des mots m´emoire transmis `a chaque cycle se compose maintenant de n pixels.

2.4.3

Gestion des bords

La gestion des bords est assez similaire `a celle mise en place dans les processeurs de voisinage flot de donn´ee standard de la figure 2.13. Il est juste n´ecessaire de dupliquer n fois cette unit´e et de modifier les compteurs de lignes et de colonnes. Chaque unit´e de gestion de bords doit embarquer ses propres compteurs, car comme nous avons pu le voir dans les figures pr´ec´edentes, les voisinages extraits `a instant t peuvent ˆetre `a cheval sur deux lignes. Chacun des compteurs de colonnes doit ˆetre initialis´e avec l’indice du voisinage extrait. Par exemple, le compteur de colonnes correspondant au voisinage le plus `a l’est doit ˆetre initialis´e avec la valeur z´ero et le compteur de colonnes correspondant au voisinage le plus `

a l’ouest doit ˆetre initialis´e avec la valeur n − 1. L’incr´ement des compteurs de colonnes doit ˆetre aussi remplac´e par la valeur n.

Les signaux informant de la position des n voisinages vis-`a-vis des bords de l’image sont ensuite g´en´er´es pour ˆetre utilis´es par les unit´es de remplacement de pixels d´ecrites en figure 2.14. Ces derni`eres sont, elles aussi, r´epliqu´ees pour chaque voisinage extrait.

Nous disposons alors de n voisinages dont les bords ont ´et´e g´er´es en rempla¸cant les voisins hors de l’image par des valeurs qui ne perturberont pas ou peu le calcul. Il est aussi envisageable de transmettre directement les signaux informant de la pr´esence d’un probl`eme de bords pour chacun des n voisinages vers les unit´es de calculs respectives, dans le cas o`u ces derni`eres ne supporteraient pas le remplacement de pixels propos´e.

2.4.4

Optimisation de l’arbre de calcul

Sachant que les n voisinages extraits de l’image se recouvrent, il est peut-ˆetre plus int´eressant d’envisager une unit´e de calcul pour tous les voisinages plutˆot que n unit´es de calcul. En effet, les calculs sur les colonnes d’un voisinage peuvent ˆetre r´eutilis´es pour d’autres voisinages. Ce principe `a d´ej`a ´et´e abord´e dans la section traitant des unit´es de cal- culs des op´erateurs de rang, mais l’´economie se faisait entre deux cycles lorsque le parcours de l’image le permettait, alors qu’ici l’´economie se fait spatialement.

Un exemple d’une unit´e de calcul optimis´e pour le calcul d’une ´erosion avec un ´el´ement structurant 3 × 3 et un degr´e de parall´elisation 4 est propos´e en figure 2.53.

Fig. 2.53: Arbre de recherche du minimum de quatre voisinages connexe

Comme dans le cas des arbres de calculs optimis´es des processeurs de voisinage clas- siques, il est n´ecessaire de d´eporter la gestion des bords au sein de l’unit´e de calcul. En effet une mˆeme colonne peut servir au calcul de deux voisinages. Lorsque cette derni`ere ne doit pas ˆetre prise en compte dans le calcul, car se trouvant dans le bord EST d’un voisinage k, elle doit ˆetre utilis´ee dans le calcul du voisinage k + 1. C’est la raison pour laquelle tous les cas de calculs de minima sur une colonne sont pris en compte comme le montre la figure 2.53.

La figure 2.54 illustre ce ph´enom`ene en consid´erant un extracteur de voisinage 3 × 3 parall´elis´e par 2. On remarque que la colonne C3 du voisinage V1 ne doit pas ˆetre prise en compte alors qu’elle doit ˆetre utilis´ee dans le calcul de V2. Ceci est dˆu au fait que la colonne C3 n’est pas r´eellement hors de l’image puisqu’il n’existe pas de padding, mais se trouve d´ej`a sur la ligne suivante.

CHAPITRE 2. PROCESSEURS DE VOISINAGE FLOTS DE DONN ´EES

Fig. 2.54: Arbre de recherche du minimum de quatre voisinages connexes

la combinatoire du calcul de toutes les op´erations d’une colonne est faible. Dans le cadre de la figure 2.53 on utilise finalement que 26 op´erateurs au lieu de 36 dans le cadre non optimis´e. D`es lors que l’on consid`ere des voisinages plus importants, la combinatoire sur les colonnes est tellement importante qu’il est pr´ef´erable de consid´erer une unit´e de calcul ind´ependante par voisinage. Par exemple, pour des extracteurs parall´elis´es d’ordre 4, une unit´e de calcul “optimis´ee” consid´erant des ´el´ements structurants 5 × 5 utilise 96 op´era- teurs (par exemple min/max pour des ´erosions/dilatations). La version standard utilisera ´

egalement 96 op´erateurs, mais avec des chemins de donn´ees beaucoup plus simples et sans multiplexeurs.