Bilan et ot de traitements

Voyons comment s'enchaînent les traitements qu'eectue notre machine et analysons le ot de traitements, pour déterminer si une source de parallélisme peut être exploitée à ce niveau. Nous avons évoqué le calcul de l'histogramme préalable aux traitements basés sur une FAH. Ce calcul nécessite un parcours exhaustif de tous les points de l'image. Il est donc susceptible d'augmenter sensiblement le temps de calcul d'un traitement par FAH. Or, nous constatons qu'en dehors des cas de marquage manuel, le traitement utilisant la FAH (la LPE) est précédé d'un algorithme à base de le simple qui n'utilise pas la mémoire image (typiquement un étiquetage de région). Un tel opérateur n'utilise pas la TLCA puisque les pointeurs de les sur une le simple sont stockés dans un registre séparé. D'autre part, chaque point de l'image est examiné lors de la phase de recherche des marqueurs de n'importe quel algorithme. Ainsi, pendant le déroulement d'un traitement à base de le, la TLCA est réquisitionnée par un histogrammeur qui stocke les valeurs de l'histogramme, indispensables au traitement suivant. Le calcul du cumul peut, dans bien des cas, être calculé en parallèle avec un traitement utilisant une le simple. Ce calcul s'avère bien moins critique que celui de l'histogramme puisqu'il ne nécessite que le parcours des 256 valeurs de la TLCA. En tirant avantage des deux ports de la TLCA, le cumul est calculé en pipe-line et demande 257 cycles, ce qui est négligeable comparé au temps d'un traitement. L'histogrammeur consiste en une machine d'état gérant les accès à la TLCA en vue du calcul de l'histogramme ou du cumul. Dans le cas d'un marquage manuel, les images ne subissent pas de pré-traitement. L'histogramme pourra être calculé sur le ot de chargement de la mémoire image. Il sera donc également masqué. Diérents cas de gures sont illustrés par la gure 3.23.

Opérateur

géodésique ^{Histogramme Cumul}

Opérateur géodésique

Opérateur géodésique Cumul

Fig. 3.23  Parallélisme de contrôle macroscopique.

Par exemple, nous pouvons envisager la séquence de la gure 3.24 dans le cas du calcul de la LPE à partir des minima régionaux.

C'est un parallélisme de contrôle macroscopique entre l'organe de traitement et l'histo-grammeur qui est exploité ici. Nous remarquons donc que l'utilisation concurrente de ressources de traitement distinctes a été largement mise à prot, tant au niveau des opérations élémentaires que sur le ot de traitements macroscopique. Ainsi, pour garder en mémoire cette particu-larité qui nous paraît fondamentale, et qui est partagée par les processeurs superscalaires, nous avons baptisé notre architecture SPIDDO pour: Superscalar Processor for Image Data Driven Operators, même si le nom de processeur superscalaire peut être discuté, tant il est parfois syno-nyme de super compilateur, ce qui n'est pas le cas ici. En eet, nous avons fait nous-mêmes le travail du compilateur.

3.5. Parallélisme et séquencement des opérations 127 Histogramme Minreg 1 Cumul Etiquetage LPE f : gradient, g : cte = "1"

f : gradient, g : minima binaires

f : gradient, g : minima étiquetés

f : gradient, g : bassins versants étiquetés

Fig. 3.24  Parallélisme de contrôle macroscopique dans le cas du calcul de la LPE. La gure 3.25 représente un schéma synoptique de notre architecture, reprenant les unités fonctionnelles que nous avons décrites dans ce chapitre. Elle n'expose pas la manière dont notre architecture s'interface avec son hôte. Ce point sera explicité en détail dans le chapitre 4.

Pixel propag. Processeur d'adresses vidéo X Y Structure Mémoire IMAGE X Y Structure Mémoire LABEL X Y LAR LABEL FIFO VOIS. LABEL FIFO VOIS. IMAGE X Y Val. affect. FIFO Pixels Y X Pixelin Pixel source Pixel prél. Dout Pixel Indice propag.rd Indice propag.wr Indice prio. Histogr. LAR IMAGE DataToHisto

Unité de test SIMD

Contrôleur général L Y X L Y X L TLCA MFA αp(i) αi(i) αwr CLA α SFS αi αp αrd αwr αrd Dⁱⁿ D^ou t

Tnord Tsud Test Touest

Pixelout

Dout

Din

Performances

Les performances d'une machine sont liées à une architecture appropriée aux traitements à eectuer, mais aussi à la technologie utilisée. Dans ce chapitre, nous avons mis l'accent sur les améliorations architecturales. Nous essaierons, autant que possible, d'évaluer les performances indépendamment de la technologie employée. C'est pourquoi les performances de notre machine seront exprimées en nombre de cycles par pixels requis au cours du traitement. Nous examinerons le cas de la LPE, car tous les points non marqueurs de l'image sont susceptibles de participer à la propagation. C'est donc le traitement requérant le plus grand nombre d'opérations pendant la phase de propagation.

Pendant la phase de recherche des marqueurs, chaque pixel source nécessite deux cycles machines alors que les autres pixels n'ont besoin que d'un cycle. Le temps de cette phase est donc lié à la longueur des lacets de propagation initiaux. Ce nombre étant, sauf exception, très faible, nous admettrons que la phase de recherche des marqueurs dure 1 cycle/pixel.

Concernant la phase de propagation, nous considérons uniquement les points participant à la propagation. En eet, si nous calculions le temps moyen en considérant tous les points de l'image, le résultat obtenu serait optimiste. Commençons par étudier le cas le plus défavorable: chaque pixel provoque une rupture du ux des opérations élémentaires. Ce cas se produit lorsque, pendant le calcul de la LPE, les points sont situés sur une spirale ascendante dans laquelle aucune paire de points n'est à la même altitude et où la source est un point unique à la base de la spirale. Ce cas est illustré par la gure 3.26: chaque prélèvement videra la le prioritaire et il faudra attendre que les insertions soient achevées avant de prélever le point suivant.

0 19 20 21 22 23 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 s

Fig. 3.26  Spirale ascendante.

Nous savons que, pour le calcul de la LPE, chaque point n'est traité qu'une seule fois, ce qui signie qu'une insertion et un prélèvement auront lieu par pixel. Étant donné que chaque prélèvement génère une lecture de voisinage et un test, les opérations élémentaires à eectuer pour tout point du domaine de propagation sont:

 prélèvement: 2 cycles;  lecture du voisinage: 1 cycle;  test du voisinage: 1 cycle;  insertion et aectation: 2 cycles.

Ainsi, la propagation théorique la plus défavorable requiert 6 cycles/pixel. Nous pouvons compa-rer ce nombre à celui des opérations séquentielles. En prenant en compte le fait que le prélèvement et l'insertion durent chacun 2 cycles, on obtiendrait en c-4:

3.5. Parallélisme et séquencement des opérations 129  lecture du voisinage: 4 cycles;

 test du voisinage: 4 cycles;  insertion: 2 cycles;

 aectation: 1 cycle.

soit 13 cycles par pixel. Le passage de 13 à 6 cycles provient uniquement des structures de mémorisation, puisque l'on étudie un cas où le parallélisme de ux est nul. Or, le parallélisme de ux entre en jeu pour les images industrielles que nous avons traitées.

Nos améliorations sont d'ailleurs largement basées sur des études statistiques de ce type d'images. De ce fait, nous sommes amenés à étudier les performances de notre architecture dans le cadre de cas concrets. Nous remarquons que le type d'images provoquant une rupture systématique du pipe-line est un cas d'école. Aussi nous attendons-nous à de bien meilleurs résultats dans la pratique. Voyons les temps eectifs mesurés sur 10 images industrielles avec des marqueurs de petite tailles. Ils sont donnés par le tableau 3.9. Notons que ces temps ont été relevés pour l'algorithme susceptible de provoquer le plus grand nombre de ruptures de pipe-line: la LPE, et sur des images variées. En tenant compte du cycle de la phase de propagation,

Tab.3.9  Performances mesurées pour la phase de propagation de la LPE.

Mesures Min Moy Max

Nombre de cycles 2,5 2,8 3,2

3,8 cycles/pixel sont nécessaires en moyenne pour le calcul de la LPE. Nous pouvons comparer les 3,8 opérations à eectuer par point sur notre architecture aux 30 opérations sur l'architecture PIMM10. Le gain est de l'ordre de 8. Nous sommes également en mesure d'évaluer la fréquence de fonctionnement qui permettrait d'atteindre des cadences de traitement typiques des applications industrielles. En nous basant sur le cas le plus défavorable mesuré, cette fréquence doit être de 28 MHz pour calculer la LPE à la cadence vidéo à raison de 25 images/seconde1, et de 11 MHz pour traiter 10 images/seconde. L'accélération d'un facteur 100 par rapport à l'implantation de l'algorithme à FAH su SUN SPARC 10 est, quant à elle, obtenue pour une fréquence de l'ordre de 25 MHz.

Examinons le temps de traitement pour les autres opérateurs. En fait, contrairement au cas de la LPE, le domaine de propagation géodésique peut être de taille très variable d'une image à l'autre. Il n'est donc pas possible de mener une étude aussi générique que dans le cas de la LPE. Nous noterons que la LPE constitue l'opérateur le plus défavorable pour comparer un algorithme à balayage dépendant des données par rapport à des algorithmes classiques. En eet, que ce soit pour les approches parallèles ou séquetielles à balayage régulier, toute l'image est parcourue lors de l'étape de propagation, alors que seuls les pixels du domaine géodésiques sont traités dans le cas d'un algorithme à balayage optimisé. Nous donnons, à titre d'exemples des temps mesurés sur des images industrielles pour d'autres traitements. Ils sont consignés dans le tableau 3.10. On notera les 4 cycles de la phase d'initialisation de la reconstruction. Il s'agit en fait de la propagation à balayage régulier vidéo et anti-vidéo, nécessitant chacun 2 cycles/pixel.

Tab. 3.10  Mesures du nombre de cycles par pixel pour diérents opérateurs. Opérateur Initialisation Propagation Total

Reconstruction numérique 4 0,2 4,2

Extréma régionaux 1 1,9 2,9

Étiquetage 1 0,5 1,5

3.5.7 Conclusion

Dans la présente section, nous avons montré comment tirer partie du parallélisme de ux et de contrôle dans le séquencement des opérations. Au niveau des opérations élémentaires, tout d'abord, nous avons souligné l'intérêt du prélèvement par anticipation. Cette technique permet de gagner le temps d'amorçage de la séquence d'opérations. Nous avons également présenté le parallélisme de contrôle exploité lors d'une succession de traitements géodésiques en mettant en avant le masquage temporel du calcul de l'histogramme nécessaire à l'initialisation de la FAH. Enn, nous avons dressé un bilan de notre architecture, présenté sa structure et déterminé les performances que nous pouvons en attendre. L'architecture que nous proposons est la structure mono-processeur la plus rapide connue à ce jour, laissant envisager, le calcul de la LPE à cadence vidéo.

3.6 Conclusion

Nous avons présenté, dans ce chapitre, une structure originale dédiée aux opérateurs géodé-siques. Elle s'appuie sur l'analyse d'algorithmes génériques paramétrables que nous avons décrits. Deux familles d'algorithmes ont été identiés, qui se distinguent par une propagation séparée ou imbriquée dans l'étape de recherche des marqueurs. Les paramètres de conguration déterminent l'identication des points source, les conditions de propagation et les données à propager. Une liste de ces paramètres a été dressée dans le cadre des traitements qui nous intéressent, mais reste ouverte à tout autre opérateur basé sur le même principe.

Le passage à l'implantation matérielle fait clairement apparaître que les accès aux données en mémoire image et label, et dans la le d'attente, constituent le principal goulet d'étranglement de ce type d'algorithmes. Dans le but d'améliorer les performances de notre architecture, nous avons développé des structures de mémorisation particulières qui permettent l'augmentation du débit des données. Les solutions choisies dans le cadre des mémoires image et label, d'une part, et de la le d'attente, de l'autre, sont radicalement diérentes. Elles reposent sur une analyse précise du comportement propre à chacune de ces structures. Nous avons ensuite cherché à augmenter les cadences de traitements, tant au niveau des opérations élémentaires qu'à celui de la chaîne complète d'opérateurs géodésiques. On retiendra que pour la LPE: 7 cycles sont nécessaires par pixel dans le cas théorique le plus défavorable. Ce chire se réduit à 4,2 cycles/pixel dans le cas le plus défavorable que nous ayons mesuré. À notre connaissance, ces cadences sont les plus élevées à ce jour, sur machine mono-processeur. De plus, la LPE est l'opérateur le plus défavorable pour comparer SPIDDO à des machines à balayage régulier, car le nombre de pixels traités est le même dans les deux cas. En eet, les performances de SPIDDO par rapport à ces machines sont d'autant plus importantes que le domaine de propagation est petit. Nous verrons, dans le prochain chapitre, que le coût matériel de SPIDDO est également réduit.

Mise en ÷uvre

Les calculs numériques qu'aura à résoudre complètement l'Ingénieur resteront toujours justiciables de la simple machine à calculer à mani-velle et de l'arsenal ordinaire des tables numériques.

Préface de  Compléments de ma-thématique (1957) 

André Angot

4.1 Introduction

Le chapitre 3 a permis d'étudier l'architecture que nous voulons réaliser. Nous commençons par examiner comment SPIDDO s'insérera dans son environnement système. Nous nous inté-ressons ensuite à son implantation et décrivons la méthodologie de conception mise en ÷uvre pour y parvenir. Cette méthode repose sur l'utilisation de VHDL à toutes les étapes de dévelop-pement, un choix qui nous permet de faire évoluer notre projet architectural indépendamment de la technologie cible, du moins pendant les premières phases. Nous déterminons les nouvelles contraintes imposées par le choix d'une technologie cible et qu'il s'agit de prendre en compte. Nous montrons que la conception d'un ASIC doit être envisagée pour que SPIDDO devienne un produit industriel répondant à nos attentes en cadence de traitement. Dans le cadre de notre étude, nous avons décidé de réaliser un démonstrateur à base de circuits programmables. Le but de cette démarche est de valider la fonctionnalité de SPIDDO et de permettre d'aner en détail le cahier des charges du circuit nal en fonction des exigences des utilisateurs. Nous précisons enn les spécications fonctionnelles et matérielles de ce prototype.