Estimateur de mouvement h´ et´ erog` ene

L’estimation de mouvement est une op´eration demandant beaucoup de bande pas- sante m´emoire et de puissance de calcul. Sur DSP, les algorithmes rapides mettent `

a profit les capacit´es `a faire des branchements conditionnels et des acc`es al´eatoires `a la m´emoire, ce qui est difficile `a mettre en oeuvre sur une architecture cˆabl´ee. L’es- timation de mouvement pixel entier (IME) atteint de bonnes performances sur un DSP. Par contre, Le raffinement subpix´elique (FME), travaillant sur une fenˆetre de recherche tr`es r´eduite, est plus coˆuteux (cf. paragraphe 5.4). La quantit´e de donn´ees source r´eduite et les op´erations r´eguli`eres (interpolation et calcul de distorsion) per- mettent de tirer parti d’une architecture cˆabl´ee. Une implantation FPGA peu coˆuteuse permet d’obtenir de meilleures performances qu’un DSP. L’op´eration d’interpolation d´ecuple les donn´ees en interne, et permet d’atteindre un parall´elisme ´elev´e avec une faible bande passante en entr´ee.

Nous pr´esentons dans ce paragraphe un prototype d’estimateur de mouvement h´et´erog`ene o`u IME est ex´ecut´e sur un DSP et FME est acc´el´er´e sur un FPGA, fonc- tionnant comme un coprocesseur. Les calculs sont mis en pipeline par bloc afin de les parall´eliser.

6.1.2.1 Plate-forme de prototypage

Le mat´eriel utilis´e est une plate-forme de prototypage Sundance (Fig 5.8) ´equip´ee d’un module SMT395 (DSP Texas Instrument C6416 `a 1 GHz avec un FPGA Xilinx Virtex II Pro XC2VP20). Le FPGA g`ere les transferts entre le DSP et le monde ext´erieur. Il n’est pas utilis´e `a 100% et permet donc l’implantation de fonctions d´edi´ees. Le FPGA est branch´e sur le bus m´emoire externe du DSP avec une largeur de 32 bits et une fr´equence de 133 MHz. Afin de personnaliser le FPGA, le fabriquant fournit les sources du programme du FPGA (firmware) [Sun]. Cela concerne les liens de communications d´ej`a implant´ees. La figure 6.7 pr´esente le sch´ema bloc du FPGA.

On retrouve plusieurs types de blocs :

– le Processor block g`ere l’interface entre le DSP et le FPGA, c’est lui qui impl´emente le protocole du bus externe du DSP, d´ecode les adresses et g´en`ere les interruptions,

– un Connector block interface le FPGA avec un ´el´ement ext´erieur (Bus PCI, autre FPGA, LED, ...), il g`ere le protocole du lien de communication,

– un Interface block permet de faire le lien entre les deux pr´ec´edents blocs. Nous avons choisi d’int´egrer nos d´eveloppements au niveau d’un interface block afin de r´eutiliser au maximum les ´el´ements d´ej`a existants. Ce bloc est donc modifi´e pour prendre en compte les sp´ecificit´es de l’application et devient un User block, auquel nous connectons le coprocesseur proprement dit. Ceci permet d’utiliser simplement les d´eveloppements existants. En effet, sur les plates-formes de type Sundance, les communications inter-processeurs sont r´ealis´ees par l’interm´ediaire de FIFO sur le

6.1 r´ealisation d’un coprocesseur 147

Fig. 6.7 – Sch´ema g´en´eral du Firmware Sundance

FPGA. Dans le cadre des biblioth`eques de communication (noyaux SynDEx, cf. para- graphe 4.1.6), des fonctions de communication permettant d’envoyer et de recevoir des donn´ees sur le DSP, ont donc d´ej`a ´et´e d´evelopp´ees. Du point de vue du DSP, il faut envoyer les donn´ees dans une FIFO, comme pour une communication avec l’ext´erieur, et se mettre en attente du r´esultat. Du point de vue du coprocesseur, d`es qu’une donn´ees est re¸cue dans le User block, celui-ci est activ´e et et les donn´ees sont trait´ees. Le r´esultat est ensuite renvoy´e vers le DSP en fin de calcul.

6.1.2.2 Parall´elisation des op´erations

L’estimation de mouvement est bas´ee sur un algorithme pr´edictif. Les vecteurs de mouvements d´ej`a calcul´es sont donc n´ecessaires pour pr´edire le mouvement courant ainsi que pour calculer le coˆut du vecteur. Cela cr´ee des d´ependances de donn´ees entre IME et FME, ce qui r´esulte in´evitablement en une ex´ecution s´equentielle. Pour exploiter le parall´elisme de la plate-forme et utiliser les composants de mani`ere efficace il est n´ecessaire d’extraire du parall´elisme de l’application, sans introduire de perte de performances de compression. Pour cela il est possible de modifier les d´ependances de donn´ees pour cr´eer un pipeline au niveau bloc compos´e de deux ´etages : IME et FME. Le vecteur du bloc de gauche est donc entr´e dans l’´etage IME `a la pr´ecision pixel au lieu du quart de pixel. Il est donc possible de parall´eliser IME sur le bloc suivant avec FME sur le bloc courant (Fig. 6.8).

Le pipeline au niveau bloc permet donc de r´ealiser le raffinement des vecteurs au quart de pixel de mani`ere transparente sur FPGA. L’impact de la modification des d´ependances sur les r´esultats et de la latence due `a la taille du pipeline sont n´egligeables au niveau image.

6.1.2.3 M´ethode de d´eveloppement

Le coprocesseur est utilis´e de mani`ere transparente avec l’outil de prototypage. En effet certaines limitations nous empˆechent `a l’heure actuelle de bien exploiter le co-

Fig. 6.8 – Implantation du pipeline au niveau bloc

processeur. Il manque une notion de multi-rythme pour dissocier le fonctionnement au niveau image des traitements au niveau bloc et une notion de pipeline permettant de parall´eliser IME et FME.

Les r´esultats de l’utilisation de SynDEx ont montr´e que la notion de boucle n’est pas bien prise en compte dans l’outil actuel. Par cons´equent une description fine au niveau bloc conduit `a un nombre d’op´erations ´el´ementaires trop important car les boucles sont d´eroul´ees exhaustivement. Il n’est alors pas possible de r´ealiser une des- cription au niveau bloc pour faire apparaˆıtre les op´erations IME et FME. L’algorithme d’estimation de mouvement est donc d´ecrit au niveau image. De plus, la distribution et l’ordonnancement optimaux sont ici simples `a identifier, ce qui limite l’int´erˆet de l’outil.

Les interfaces entre le DSP et le FPGA sont existantes, il est donc rapide de mettre au point les op´erations de transfert et de synchronisation optimis´ees. Afin de simplifier le d´eveloppement, le coprocesseur peut ˆetre utilis´e comme un p´eriph´erique mˆeme du DSP. Une macro-instruction est donc d´evelopp´ee selon l’algorithme 6.3.

Algorithme 6.3 Macro-instruction de raffinement subpix´elique

si (indice de bloc 6= 0) (pipeline initialis´e ?) lire r´esultat du bloc pr´ec´edent

fin de si

transf´erer donn´ees du bloc courant (lancer le traitement sur de nouvelles donn´ees) si (indice de bloc = dernier bloc) (fin du pipeline ?)

lire r´esultat du bloc courant fin de si

L’outil de prototypage est toutefois utilis´e au niveau image pour la description globale de l’algorithme. Il permet d’ex´ecuter l’estimation de mouvement sur la plate- forme h´et´erog`ene, et de r´ealiser les op´erations de lecture de flux et d’affichage sur PC. Les transferts et synchronisations sont g´er´es automatiquement. Il permet ´egalement de faire la v´erification fonctionnelle et des chronom´etrages (cf. paragraphe 4.1.7).

6.1.2.4 Performances

Une fois que la v´erification fonctionnelle a ´et´e valid´ee avec le mod`ele PC, le chro- nom´etrage de plusieurs configurations permettent d’´evaluer les performances de la solution h´et´erog`ene. Les temps d’ex´ecution apparaissent dans le tableau 6.4 avec pour r´ef´erence les r´esultats de IME sur DSP, FME sur DSP et FPGA, et l’estimateur com-

6.1 r´ealisation d’un coprocesseur 149

plet (IME+FME h´et´erog`ene). Les temps d’ex´ecution sont donn´es pour seulement une taille de bloc, avec le niveau de pleine r´esolution de l’algorithme HDS pour IME.

IME est ex´ecut´e en 900 ns pour un bloc 8x8 et 2800 ns pour un bloc 16x16. Le raffinement quart de pixel est ex´ecut´e sur DSP en 1200 ns pour un bloc 8x8 et 4400 ns pour un bloc 16x16 alors que cela ne requiert seulement que 842 et 1925 ns sur FPGA. De plus les traitements sont parall´elis´es et le fonctionnement du FPGA est donc `a priori transparent. Les mesures de l’application parall´elis´ee sur l’architecture h´et´erog`ene donnent des temps d’ex´ecution de 1250 et 3900 ns pour des blocs 8x8 et 16x16 respectivement. Le fonctionnement du FPGA n’est donc pas totalement trans- parent. Effectivement, le temps global devrait ˆetre celui celui du plus long traitement, soit 1200 et 4400 ns et il est sup´erieur. Le temps suppl´ementaire est dˆu au transfert des donn´ees entre le DSP et le FPGA. En effet Le DSP place les donn´ees (bloc cou- rant, fenˆetre de recherche, vecteur et multiplicateur de Lagrange) en m´emoire interne pour les envoyer vers le FPGA de mani`ere contigu¨e. De plus, les transferts de donn´ees occupent le bus m´emoire et ralentissent donc l´eg`erement les traitements.

Taille de bloc 8x8 16x16

IME sur DSP 900 ns (720p frame : 13 ms) 2800 ns (10 ms)

FME sur DSP 1200 ns (17.3 ms) 4400 ns (15.8 ms)

FME sur FPGA 842 ns (12 ms) 1925 ns (7 ms)

IME sur DSP

+ FME sur FPGA 1250 ns (720p frame : 18 ms) 3900 ns (14 ms)

Tab. 6.4 – Chronom´etrages par bloc (et par image 720p)

L’utilisation d’un FPGA pour r´ealiser l’op´eration de raffinement subpix´elique des vecteurs de mouvement permet de r´eduire consid´erablement l’impact de cette op´eration sur le temps de traitement. Le coprocesseur cadenc´e `a 133 MHz a des per- formances du mˆeme ordre de grandeur que IME sur DSP, ce qui permet une utilisation des ressources efficace avec une parall´elisation des traitements sur les deux composants. Il est donc possible d’atteindre 55 (resp. 70) images par secondes pour l’esti- mation de mouvement au quart de pixel d’une image 1280x720 pour des blocs 8x8 (resp. 16x16). L’introduction du coprocesseur permet d’atteindre le temps-r´eel pour des blocs 16x16 et d’en ˆetre tr`es proche pour des blocs de taille 8x8.

6.1.2.5 Estimateur de mouvement complet

Les performances pr´esent´ees ci-dessus prennent en compte seulement le niveau pleine r´esolution de l’algorithme HDS, en ne consid´erant qu’une taille de bloc. Cependant, un estimateur de mouvement complet pour la compression vid´eo H.264 suppose de prendre en compte ´egalement plusieurs tailles de bloc et les niveaux hi´erarchiques. Un module DSP+FPGA n’est alors plus `a mˆeme de traiter toutes les tailles de mani`ere exhaustive en temps r´eel.

L’algorithme all´eg´e d´ecrit au paragraphe 5.4.2.5 permet de ne raffiner qu’un seul mode sur les quatre tailles consid´er´ees. Cette r´eduction de complexit´e permet d’envi- sager un estimateur de mouvement `a taille de bloc variable `a 25 images par seconde en 720p. Une r´eduction de complexit´e de l’algorithme pixel entier `a taille de bloc variable

est n´ecessaire pour atteindre de meilleures performances. Par exemple un algorithme bas´e sur EPZS 8x8, avec un regroupement des blocs pour obtenir les vecteurs des autres tailles (sans mise en correspondance), permettrait d’atteindre les 50 images par secondes, avec une perte de qualit´e des vecteurs de mouvement.

Une autre solution, beaucoup plus coˆuteuse, consiste `a r´ealiser l’estimation de mouvement des niveaux hi´erarchiques sur un processeur dans un premier ´etage de pipeline, puis de dupliquer le sch´ema IME+FME pour chaque taille de bloc dans un deuxi`eme ´etage de pipeline. Cette solution n´ecessite donc au total cinq DSP et quatre petits FPGA pour r´ealiser l’estimation de mouvement H.264 pour une image de r´ef´erence en 720p 50 Hz, ce qui est cher et donc non envisageable dans un contexte industriel.