Le contrôle non destructif par ultrasons et méthodes de reconstruction

Télécharger le fichier pdf d’un mémoire de fin d’études

Techniques d’inspection en CND par ultrasons

Il existe de nombreuses techniques d’inspection par ultrasons permettant d’utiliser au mieux les traducteurs pour couvrir un maximum du volume que l’opérateur souhaite contrôler. Nous allons brièvement présenter deux techniques communément utilisées en CND US.
La commutation électronique : Les traducteurs multiéléments permettent d’ajouter, voire dans certains cas de substituer au balayage mécanique du capteur, un balayage électro-nique qui permet des cadences d’acquisition beaucoup plus élevées qu’un déplacement mécanique. Le principe est d’utiliser un groupe d’éléments actifs (par exemple 16 élé-ments d’un réseau en comportant 64) en émission-réception, puis de décaler les éléments actifs.
Le balayage angulaire : lors d’un contrôle par ultrasons classique, afin de détecter des fissures se propageant généralement perpendiculairement à la pièce, le traducteur est in-cliné afin de générer un faisceau à un angle donné dans la pièce et déplacé à la surface de celle-ci. Pour les multiéléments, l’inclinaison peut être obtenue par loi de retard. Le contrôle par multiéléments autorise également à réaliser un contrôle à des angles diffé-rents (tirs) pour une même position. Des algorithmes de repositionnement sont fréquem-ment utilisés pour représenter les données expérimentales issues de ce type de contrôle. Ils vont être présentés par la suite.

Méthodes de reconstruction

L’objectif de la reconstruction est de localiser et de caractériser les défauts à l’origine des échos détectés. Les différentes méthodes ont pour point commun d’associer aux données ex-périmentales des données de simulées et de produire une image dans le repère cartésien de la pièce (c.f. figure 1.14).
Le DISC propose deux grandes familles d’algorithmes :
La première est basée sur une approximation du parcours de l’onde dans la pièce sous forme de polylignes appelées « trajets ». Par hypothèse, on considère donc que la propa-gation de l’écho ultrason se fait le long d’un rayon. Ce rayon est obtenu en effectuant un lancer de rayon depuis le centre de l’émetteur avec la direction principale d’émission (généralement la normale de l’émetteur) [Porre et al., 2005]. Le rayon est propagé selon les propriétés des matériaux (calcul de réfraction aux interfaces) et sa propagation est stoppée par un critère d’arrêt (nombre de rebonds, ou sortie de la pièce). Une hypothèse importante pour ce type d’approximation est de considérer que l’onde parcourt le même trajet en émission et en réception. La figure 1.15 présente le parcours d’un trajet dans une soudure.
Une fois le trajet calculé, il est possible de projeter l’information temporelle du signal dans le repère de la pièce, en tenant compte des temps de vol et des vitesses de propagation dans les matériaux. Les images reconstruites de cette manière sont appelées « vues vraies ». La figure 1.16 présente la différence entre un B-Scan et un B-Scan Vrai.
La deuxième famille d’algorithmes se base sur une méthode dite par ouverture synthé-tique, inspirée de la méthode SAFT : la méthode de Focalisation en Tout Point (FTP) [Sey-del, 1982] [Holmes et al., 2004]. Contrairement à la méthode basée sur la notion de trajet où le parcours géométrique de l’onde est utilisé, c’est le temps de propagation qui va être utilisé pour effectuer ces reconstructions. Le calcul des temps de vol de l’onde acoustique en chaque point de la zone de reconstruction peut se faire par une simulation complète du champs ultrasonore ou par une approximation géométrique. La méthode FTP fera l’objet d’une étude approfondie dans le chapitre 3 où nous nous intéresserons à la fois à la reconstruction et au calcul de simulation.
Dans le domaine du CND US, peu d’études d’accélérations d’algorithmes sur architectures parallèles sont présentes. Parmi les études existantes, on peut noter plus particulièrement deux études : l’une d’un portage d’une variante de l’algorithme FTP sur architecture GPU, et l’autre d’un portage d’un algorithme simplifié de calcul de champs ultrasonore, toutes deux réalisées par la même équipe [Romero-Laorden et al., 2011a] [Romero-Laorden et al., 2011b].
En dehors des ultrasons, on peut trouver quelques études en Courants de Foucault ou en Radiographie X. Pour cette dernière technique, on trouve par exemple un retour d’expérience présentant une nouvelle méthode de reconstruction ainsi que des gains significatifs apportés par la parallélisation sur GPU [Wang et al., 2011]. On peut aussi trouver des études plus larges, comparant les performances de multicoeurs, de GPU et de FPGA [Gac et al., 2008]. Les auteurs de cet article détaillent le travail effectué pour contourner le goulet d’étranglement existant au niveau de la bande passante mémoire sur un algorithme de rétro-projection en tomographie par émission de positrons. Un travail de parallélisation, pipeline et de pré-extraction est réalisé sur un algorithme de cache de données déjà existant. Les optimisations portent à la fois sur du réordonnancement de boucle afin d’optimiser les accès aux caches des multicoeurs et à l’usage de localité spatiale pour minimiser les besoins en bande passante.

La plateforme logicielle CIVA

CIVA est une plateforme logicielle qui a pour but de capitaliser les résultats de la recherche et des développements menés par le CEA et ses partenaires dans le domaine du CND. Il concerne les principales techniques que sont les ultrasons, les courants de Foucault et la radiographie X ou Gamma. CIVA propose dans un même environnement différents modules de simulation adaptés aux besoins des industriels et de recherche et développement. Son système d’imagerie ultrasonore associé à des modules de traitement d’image et du signal permet l’interprétation et l’expertise des résultats expérimentaux et de simulation.

Présentation générale

Les simulations accessibles par le logiciel CIVA permettent d’optimiser les choix d’une pro-cédure de contrôle. En effet, le logiciel permet de prendre en compte la plupart des paramètres influents mis en jeu lors d’un contrôle, tant pour le capteur, la géométrie ou le matériau de la pièce inspectée, que pour les défauts recherchés. En jouant sur l’ensemble de ces paramètres, il est alors possible de sélectionner la méthode la plus appropriée au contrôle à effectuer, ou encore d’évaluer la performance et la pertinence d’une procédure existante.
La simulation est un atout majeur de réduction des coûts. La possibilité de faire varier les paramètres d’un contrôle (de façon maîtrisée) permet par exemple d’anticiper le contrôle dès le stade de la conception d’un composant, ou encore de minimiser le nombre de maquettes à réaliser pour démontrer la performance d’un contrôle. La conception d’un capteur peut par ailleurs être guidée par les outils de simulation, notamment lorsqu’il s’agit de technologie mul-tiéléments.
Les domaines d’application de CIVA sont très variés. La plateforme est utilisée dans le do-maine nucléaire par la plupart des acteurs mondiaux, de la France à la Corée du Sud, en passant par les Etats-Unis, la Chine ou le Japon. Conception de nouveaux contrôles, mise en place de solutions innovantes à l’aide de capteurs multi éléments, démonstration de performance ou qualification de dossier, CIVA est un allié incontournable pour allier optimisation technique et réduction des coûts. L’aéronautique est un domaine dans lequel CIVA apporte aussi des solutions rentables. La prise en compte de matériaux complexes, la possibilité de prédire le comportement de la méthode sur des pièces de géométries variées, l’étendue considérable des capteurs et sondes disponibles donnent aux bureaux d’études et aux concepteurs de contrôles un atout qui devient rapidement incontournable.
Dans les domaines comme les transports, la métallurgie, l’aérospatiale, la pétrochimie, CIVA apporte non seulement une solution technique permettant de comprendre les phénomènes complexes, mais CIVA est aussi et avant tout un moyen de réduire les coûts. CIVA est aujour-d’hui une référence dans le domaine du CND et dispose aujourd’hui de plus de 250 licences dans le monde. La plateforme est développée par 4 laboratoires du CEA-LIST et dispose de plus de 30 développeurs permanents.

CIVA ultrasons

Deux principaux types de simulation sont disponibles : le calcul de champs et le calcul de repose défaut ou calcul d’écho. Le premier permet de simuler le faisceau ultrasonore rayonné dans la pièce et éventuellement dans le couplant. Le faisceau peut être visualisé dans la ma-tière en amplitude de couleur ou en surface iso-amplitude. Les directions locales et les fronts d’ondes peuvent également être visualisés (et sauvegardés sous forme d’animation). La figure 1.17 présente une capture d’écran issue de CIVA du point de vue utilisateur pour les simula-tions de champs. Le second module permet de simuler l’interaction faisceau/défaut et prédit l’amplitude et le temps de vol des échos de chaque type : direct, écho de coin. Il calcule égale-ment les échos de géométrie, l’écho de surface et tient compte des conversions de modes. C’est sur ce type d’informations que les reconstructions qui vont être étudiées dans le manuscrit sont effectuées.
Le module ultrasons prend en charge un très large panel d’éléments. Il permet de simu-ler l’ensemble d’une procédure de contrôle. Les différents capteurs mono-éléments et multi-éléments vus en section 1.1.2.3 sont donc tous pris en charge et le choix est bien plus large puisqu’il est possible de créer ses traducteurs.
Un grand nombre de traitements du signal classiques (filtres, méthode de déconvolution, etc.), ou évolués (ondelettes, déconvolution double Bernouilli-gaussienne), sont mis à dispo-sition. Un outil de segmentation permet le regroupement 3D des signaux, la gestion de ces groupes et la création de rapports d’examen.
Des outils de reconstruction sont intégrés au logiciel, en particulier la Focalisation en Tout Point, algorithme que nous allons étudier dans le chapitre 3. Ce traitement permet, à l’issue d’une acquisition ou d’une simulation multiéléments, de reconstruire une image présentant en chaque point l’amplitude obtenue en combinant les signaux de manière à focaliser au mieux. Un utilitaire de tracé de rayon complète ces différents outils (il gère les conversions de mode, les rebonds, et permet l’affichage des temps de parcours).

Architectures parallèles

Le Calcul Haute Performance (HPC) a longtemps été associé aux supercalculateurs, assem-blages de milliers voir de centaines de milliers de processeurs. Aujourd’hui, on trouve de plus en plus d’architectures parallèles dans des machines de type station de travail et permettant d’atteindre des performances de calcul très élevées. Une carte graphique vendue 300 euros au grand public en 2009 pouvait atteindre les performances du plus puissant supercalculateur de l’an 2000, ASCI Red, avec une consommation environ 4000 fois inférieure. L’évolution est extrêmement rapide et permet d’envisager des solutions qui ne l’étaient pas quelques années auparavant. Là où le HPC se limitait à un nombre restreint de domaines tels que le nucléaire ou la météorologie, il répond maintenant à des besoins toujours plus étendus. Le marché propose des puces hautement parallèles, mélangeant processeurs généralistes (GPP) et processeurs spé-cialisés (e.g. les GPU).
La structure de ces nouvelles architectures a donc évolué. La montée en fréquence des GPP ayant atteint un palier du fait des difficultés à contrôler la dissipation thermique à un certain niveau de finesse de gravure, les constructeurs ont trouvé d’autres moyens de poursuivre l’aug-mentation de performances. La loi de Moore, qui se vérifie encore aujourd’hui, nous indique que les puces disposent d’un nombre de transistors toujours plus importants. Un Core 2 Duo, de 2006, dispose d’environ 300 millions de transistors pour une dimension de 200 mm2. En comparaison, un GPP Intel Sandy Bridge de 6 coeurs dispose d’environ 2,3 milliards de tran-sistors pour une surface de 434 mm2. En termes de performances brutes, le Core 2 Duo était capable de près de 20 GFLOPS contre environ 180 sur le 6 coeurs Sandy Bridge. Cette évolu-tion des performances est permise grâce à l’évolution de la taille des registres SIMD qui permet d’améliorer les performances pour du parallélisme de données, ainsi qu’à la multiplication des coeurs, qui même s’ils sont plus orientés parallélisme de tâches, apportent eux aussi un moyen d’augmenter considérablement les performances.
Hormis les architectures GPP, on constate un autre courant d’évolution avec l’arrivée d’ar-chitectures novatrices telles que : les architectures multicoeurs de Tilera ou le multicoeurs 64 coeurs d’Adapteva. Le Xeon Phi d’Intel se place à la croisée entre ces deux courants d’évolu-tion. Dans les deux cas, les constructeurs font face à un réel problème : l’utilisation du potentiel de leurs puces. Cette difficulté se répartit entre pilotes, API, compilateurs, outils de debogage et de profiling et modèles de parallélisme. Ces aspects sont critiques pour l’avenir des architec-tures.
Dans le cadre de l’intégration dans la plateforme CIVA, certaines architectures sont à ex-clure du fait de la complexité de mise en place sur des machines de type station de travail. Nous allons donc nous concentrer sur les architectures parallèles les plus adaptées actuelle-ment pour une intégration industrielle, ainsi que sur les modèles pouvant être exploités sur celles-ci.

Les architectures GPP multicoeurs

Les deux principaux acteurs du marché des GPP multicoeurs pour machines de type sta-tion de travail sont Intel et AMD ; ARM ne ciblant pas encore ce type de machines. Ces deux concepteurs de puces ont tous deux commencé à proposer des puces intégrant du parallélisme à partir de 2006 (IBM proposait déjà un dual-core depuis 2004 avec le POWER 5, mais c’est bien Intel et AMD qui ont vraiment lancé le mouvement). Depuis, le nombre de coeurs ne cesse d’augmenter avec en 2012 des processeurs atteignant 12 coeurs pour AMD et 10 coeurs pour Intel.

Origine des multicoeurs

Ces architectures sont directement issues des processeurs monocoeurs existant auparavant.
Ces anciennes architectures avaient déjà profité de nombreuses avancées à différents niveaux :
réduction de la finesse de gravure,
augmentation de la fréquence des transistors,
pipelining,
amélioration des mémoires caches, prédiction de branchements,
exécution superscalaire.
En règle générale, ces évolutions ont toujours été dans le sens de l’amélioration d’un flux unique de calcul, et ce, aussi bien au niveau des compilateurs que des langages de programma-tion. Les GPP sont donc des architectures très optimisées et disposent d’un environnement de développement très complet. Les compilateurs ont évolué de manière à suivre les avancées ma-térielles. Les caches permettent à la plupart des développeurs d’utiliser au mieux l’architecture sans avoir nécessairement à la connaitre parfaitement. La complexité est cachée au maximum pour les utilisateurs.
Ce n’est donc que depuis quelques années que les GPP ont évolué vers des architectures parallèles. Cependant, la majorité des améliorations apportées continue d’aller dans le sens de l’exécution de flux séquentiels : il suffit d’observer la place que prennent les unités de calcul en entiers et flottants pour comprendre ce fait. En effet, elles ne prennent qu’une partie minime de la puce sur les architectures récentes.
FIGURE 1.18 – Photo d’un Intel Core i7 Bloomfield de génération Nehalem disposant de 4 coeurs SMT (Simultaneous Multithreading ou Hyperthreading chez Intel), 8 Mo de cache L3. En rouge, la surface de la puce dédiée aux unités de calcul (entiers et flottants).
La figure 1.18 présente une photo de la puce d’un Intel Core i7 Bloomfield de génération Nehalem. On peut constater en rouge le peu de place prise sur la puce dédiée aux unités de calcul, ce qui illustre les propos précédents. En revanche, la place prise par le cache est très importante (environ 50% de la surface). Ces caches se basent sur le fait que les données vont être réutilisées très rapidement. Autant cela permet d’accélérer certains types de flux de calculs, autant le traitement de volumes de données importants ne va pas forcément être approprié sur ce type d’architecture. Une partie du cache pourrait donc par exemple être remplacée par des unités de calcul.
De la même manière, des unités de prédiction de branchements et des caches rapides vont permettre d’accélérer des codes où la localité des données et le nombre de branches sont importants. En revanche, dans le cas de calcul intensif, comme peuvent l’être un certain nombre de codes de calcul scientifique, certaines fonctionnalités ne seront pas utilisées, rendant le GPP moins efficace.

L’architecture Nehalem

L’architecture Nehalem (Westmere) étant au centre de nos travaux, nous allons en faire une synthèse.Cette architecture comprend un ensemble de fonctionnalités à la pointe de leur évo-lution : exécution out-of-order, SIMD 128 bits, prédiction de branchements, Simultaneous Multi-threading, contrôleur mémoire embarqué, très grands caches dont un L3 partagé entre tous les coeurs, et un bus d’interconnexion pour relier plusieurs processeurs.
Chaque coeur dispose de quatre décodeurs d’instructions qui peuvent travailler en paral-lèle, même si un seul est capable de décoder les instructions x86 complexes. Les opérations sont ensuite exécutées de manière out-of-order. Le Nehalem dispose de registres SIMD 128 bits et de la possibilité d’exécuter jusqu’à 4 instructions par cycle d’horloge. La puissance de calcul d’un processeur Nehalem va donc être calculée de la manière suivante :
< F requence > < N ombre de coeurs > < N ombre d0instructions par cycle >
Pour un Intel Xeon X5690 Westmere disposant de 6 coeurs et fonctionnant à 3,47 GHz, cela fait donc 83 GFLOPS simple précision et moitié moins en double précision.
Quant à la bande passante, elle atteint 32 Go/s. Ce chiffre est intéressant car cela représente à peu près un accès mémoire d’un octet en DRAM contre trois opérations flottantes. Un grand nombre d’applications de calcul intensif risquent d’être limitées par la bande passante dans la mesure où théoriquement, il sera nécessaire d’effectuer 24 opérations flottantes pour une va-leur double précision (8 octets).
La génération qui suit l’architecture Nehalem/Westmere est l’architecture Sandy Bridge/Ivy Bridge. Plusieurs points ont évolué, parmi lesquels :
Latence des caches L1 et L2 a été légèrement modifiée,
bus SIMD est doublé avec un nouveau jeu d’instructions : AVX,
ajout d’un processeur graphique intégré partageant le cache L3 du GPP.
Les GPP continuent d’évoluer de manière importante. Pendant ce temps, leurs défauts ont tenté d’être contournés par les concepteurs d’architectures. Intel travaille depuis plusieurs an-nées sur une puce qui initialement devait se placer sur le marché des GPU haut de gamme : le Xeon Phi (anciennement appelé Larabee, Knight’s Corner, Knight’s Ferry ou encore MIC). Cette puce vient d’être lancée officiellement ; Intel tente de combiner les avantages des GPP tout en augmentant au maximum le parallélisme de données avec un bus SIMD de 512 bits et de nouvelles instructions de gather/scatter permettant un adressage dispersé, un nombre de coeurs élevé (’ 60 coeurs). C’est du coté des puces graphiques qu’à émergé une architecture qui semble vouloir tenir dans le temps : le G80 de Nvidia.

Table des matières

Introduction générale 
1 Contexte 
1.1 Le contrôle non destructif par ultrasons
1.1.1 Les ultrasons
1.1.1.1 Types de propagation d’une onde ultrasonore
1.1.1.2 Interaction d’une onde avec une interface plane
1.1.2 Les traducteurs ultrasonores
1.1.2.1 Emission et réception des ondes ultrasonores
1.1.2.2 Différents types de focalisation
1.1.2.3 Différents types de traducteur
1.1.3 Le contrôle non destructif par ultrasons et méthodes de reconstruction
1.1.3.1 Exemple de contrôle en CND US
1.1.3.2 Représentation des données d’un contrôle ultrasons
1.1.3.3 Techniques d’inspection en CND par ultrasons
1.1.3.4 Méthodes de reconstruction
1.1.4 La plateforme logicielle CIVA
1.1.4.1 Présentation générale
1.1.4.2 CIVA ultrasons
1.2 Architectures parallèles
1.2.1 Les architectures GPP multicoeurs
1.2.1.1 Origine des multicoeurs
1.2.1.2 L’architecture Nehalem
1.2.2 Les architectures GPU
1.2.2.1 Historique
1.2.2.2 L’architecture Fermi
1.3 Outils de programmation et de parallélisation
1.3.1 Outils natifs
1.3.1.1 CUDA
1.3.1.2 OpenMP
1.3.1.3 Threading Building Blocks
1.3.1.4 Cilk+
1.3.2 Outils hybrides
1.3.2.1 OpenCL
1.3.2.2 HMPP
1.3.2.3 OpenACC
1.3.3 Conclusion sur les modèles de programmation
1.4 De l’intégration de codes parallélisés dans un contexte industriel
1.4.1 Langages de programmation
1.4.2 Envrionnement multithread
1.4.3 Coût de développement
1.4.4 Maintenance, évolutions, pérennité
1.4.5 Matériel
1.4.6 Perspectives par rapport à la plateforme CIVA
1.4.7 Mesures de performances
1.4.8 Conclusion sur les problématiques d’intégration
1.5 Conclusion
2 Etude de la parallélisation de l’algorithme Image Vraie Cumulée 
2.1 Présentation de l’algorithme d’Images Vraies Cumulées
2.1.1 Présentation fonctionnelle
2.1.2 Pseudo-code de l’algorithme et implémentation de référence
2.1.3 Description des données
2.1.3.1 Signaux
2.1.3.2 Trajets
2.1.3.3 Zone de reconstruction
2.1.4 Complexité algorithmique
2.2 Optimisation du traitement d’image
2.2.1 Description du traitement d’image existant
2.2.2 Remplacement du traitement par un opérateur de morphologie mathématique
2.3 Présentation du benchmark
2.3.1 Aspects logiciels et matériels
2.3.2 Cadre d’utilisation et temps de transferts
2.3.3 Présentation des jeux de données
2.3.3.1 PMF
2.3.3.2 EXZ
2.4 Mise en évidence des approches de parallélisation
2.4.1 Approche par parallélisation pixel
2.4.2 Approche par parallélisation trajet
2.5 Etude des performances de la parallélisation sur GPU
2.5.1 Implémentation GPU
2.5.2 Validation de l’approche de parallélisation sur GPU
2.5.2.1 Etude de performances des instructions atomiques du GPU
2.5.2.2 Ordonnancement des accès mémoire en cas de parallélisation trajet
2.5.3 Benchmarks et analyses de performances
2.5.3.1 Impact de l’optimisation du traitement d’image
2.5.3.2 Impact de l’irrégularité des trajets
2.5.3.3 Fermi : modes de cache et comparaison C2070/GTX580
2.5.3.4 Comparaison CUDA / OpenCL
2.6 Etude de la parallélisation sur GPP multicoeurs
2.6.1 Implémentations GPP multicoeurs
2.6.2 Benchmarks et analyses de performances
2.6.2.1 Impact du passage en post-traitement du traitement d’images
2.6.2.2 Passage à l’échelle de l’implémentation OpenMP
2.6.2.3 Comparatif OpenMP / OpenCL
2.7 Analyse générale GPP multicoeurs et GPU
2.7.1 Comparaison GPP / GPU
2.7.2 Comparaison entre modèles de programmation
2.8 Intégration de l’algorithme IVC dans la plateforme CIVA
2.8.1 Présentation du prototype
2.8.1.1 Contournement de la limitation de l’instruction atomique
2.8.1.2 Extraction des informations supplémentaires
2.8.2 Benchmark
2.8.3 Conclusion
2.9 Conclusion
3 Etude de la parallélisation de l’algorithme de Focalisation en Tout Point 
3.1 Présentation de l’algorithme
3.1.1 Principe de la méthode de Focalisation en Tout Point
3.1.2 Calcul des temps de vol
3.1.2.1 Traducteur au contact
3.1.2.2 Traducteur sans contact pour une interface plane
3.1.3 Interfaces complexes
3.1.3.1 Types d’interfaces
3.1.3.2 Géométries CAO 2D à interfaces multiples
3.2 Recherche de zéros d’un polynôme
3.2.1 Choix de la méthode de résolution d’équations polynomiales
3.2.2 Principe de la méthode itérative de Laguerre
3.3 Analyse algorithmique de FTP
3.3.1 Implémentation de référence et choix d’ordonnancement des calculs
3.3.2 Egalité aller-retour des temps de vol
3.3.3 Algorithme par calcul exhaustif des temps de vol
3.3.4 Algorithme par interpolation des temps de vol
3.3.5 Complexité algorithmique
3.3.6 Description des données
3.3.6.1 Signaux
3.3.6.2 Variables associées au contrôle
3.3.6.3 Dimensionnement des configurations
3.3.7 Approches de parallélisation
3.4 Préparation du benchmark
3.4.1 Architectures et logiciels
3.4.2 Présentation des jeux de données
3.4.3 Type de données et précision des résultats
3.4.3.1 Etude statistique de la méthode de recherche de zéros d’une fonction polynomiale
3.4.3.2 Calcul de l’erreur sur l’accès aux échantillons
3.4.3.3 Exploitation du logiciel CADNA pour évaluer les erreurs d’arrondis
3.4.3.4 Conclusions
3.5 Etude de la parallélisation sur GPU
3.5.1 Implémentations CUDA et OpenCL
3.5.1.1 Base des implémentations GPU
3.5.1.2 Exhaust : implémentation sans interpolation des temps de vol
3.5.1.3 Interp : Implémentation avec interpolation des temps de vol
3.5.2 Analyse des performances des GPU
3.5.2.1 Impact de l’association bloc de threads/nombre de pixels par bloc
3.5.2.2 Impact de la résolution de l’image
3.5.2.3 Impact du nombre d’éléments du traducteur
3.5.2.4 Evolution du temps de calcul en fonction du degré du polynôme
3.5.2.5 Coût du calcul sur des pièces à interfaces multiples
3.5.2.6 Impact de la méthode par interpolation des temps de vol
3.6 Etude de la parallélisation sur GPP multicoeurs
3.6.1 Implémentations OpenCL et OpenMP
3.6.2 Analyse des performances des GPP multicoeurs
3.6.2.1 Paramétrage OpenCL
3.6.2.2 Impact des modes d’ordonnancements d’OpenMP
3.6.2.3 Impact de la résolution de l’image
3.6.2.4 Impact du nombre d’éléments du traducteur
3.6.2.5 Passage à l’échelle OpenMP
3.6.2.6 Comparaison entre OpenMP et OpenCL
3.6.3 Implémentation SIMD de l’algorithme de Laguerre
3.6.3.1 Présentation de l’implémentation SIMD de l’algorithme de Laguerre
3.6.3.2 Micro-benchmark de Laguerre
3.6.3.3 Performances SIMD dans FTP
3.7 Analyse générale GPP multicoeurs et GPU
3.7.1 Comparaison GPP / GPU pour les implémentations basées sur le code scalaire CAO2D
3.7.2 Comparaison GPP / GPU avec les implémentations basées sur le code SIMD
3.7.3 Discussion
3.8 Intégration de l’algorithme FTP dans la plateforme CIVA
3.8.1 Présentation du prototype
3.8.2 Benchmark
3.9 Conclusion
Conclusion générale
Références Bibliographiques 
Publications

Télécharger le rapport complet