Présentation du prototype

L’intégration de l’algorithme TCV a nécessité une phase d’ingénierie en amont pour inté- grer à la plateforme les accélérateurs OpenCL. Un ensemble de classes a été développé pour gérer la partie hôte de manière objet. Etant donné que les API de lecture des données sont dé- veloppées en JAVA, il nous a paru plus pertinent de placer l’intelligence dans la même partie du logiciel. Nous avons utilisé un wrapper JAVA à OpenCL : JOCL [Hutter, 2012].

Par rapport à l’étude réalisée dans ce chapitre, les besoins de l’algorithme ont évolué au niveau du remplissage de l’image. En effet, le remplissage existant auparavant pouvait être amélioré en utilisant des informations supplémentaires : l’angle du trajet dont l’amplitude a été projeté, la profondeur de cette amplitude dans la pièce, le temps de vol et la direction du segment de trajet depuis lequel l’amplitude a été projetée. L’implémentation OpenCL (GPU et GPP) fait appel à un atomic_max exécutant un verrou sur une seule instruction. Le problème ici est qu’en plus de l’amplitude, on voudrait récupérer les informations citées ci-dessus. Il n’est pas possible d’effectuer plusieurs opérations atomiques de manière atomique.

Pour rappel, nous ne prendrons pas en compte la problématique des transferts de données. En effet, le choix a été fait d’effectuer un transfert total des données pour ensuite exécuter de multiples reconstructions sur ce jeu de données (cf. section 2.3.2). Le transfert est effectué manuellement par l’utilisateur qui spécifie quel jeu de données il va vouloir traiter grâce à l’accélérateur.

2.8.1.1 Contournement de la limitation de l’instruction atomique

Nous avons la possibilité d’utiliser l’opération atomique pour passer plusieurs informa- tions. Celle-ci est effectuée sur 32 bits puisque les opérations atomiques en 64 bits ne sont disponibles qu’avec OpenCL 1.2 et que l’implémentation Nvidia est encore en 1.1. En l’oc- currence, le facteur commun permettant de retrouver les informations citées ci-dessus étant les trajets, nous allons sortir en plus de l’amplitude, l’indice de trajet.

Pour se faire, on va réduire la précision des amplitudes à 12 bits et utiliser les 20 bits res- tants pour coder l’indice du trajet (cf. figure 2.14). De cette manière, un pixel contiendra bien l’amplitude maximum avec en plus l’information d’indice. En revanche, cette méthode pose

plusieurs problèmes :

• L’amplitude dispose d’un codage restreint : cela n’est pas un problème étant donné que les vues sont visualisées en niveaux de gris (ou en utilisant une palette de couleur spéci- fique) codée sur 256 valeurs.

• Le nombre de trajets va être limité à 220_{soit environ un million. Une grande majorité des} jeux de données ayant un nombre de trajets inférieur, ce choix ne devrait pas être trop limitant.

• Pour un même trajet, il est possible d’avoir deux amplitudes identiques provenant de trajets différents. Dans ce cas, l’indice ne remontera que le trajet d’indice maximum. Une fois de plus, ce ne devrait pas être problématique dans la mesure où un trajet n’a pas plus d’importance qu’un autre.

• La précision réduite au niveau des amplitudes peut modifier le résultat de l’algorithme en cas d’amplitude identique au même pixel. Ce problème peut-être gênant car on ne sélectionne plus l’amplitude maximum de l’acquisition. Le passage de l’instruction ato- mique en 64 bits atténuera ce problème.

Codage de l'amplitude Codage de l'indice de trajet

12 bits 20 bits

Bit de poids fort Bit de poids faible

FIGURE2.14 – Extension de l’utilisation de l’instruction atomique pour récupérer une seconde information.

Ces limitations devraient être assouplies une fois que les instructions atomiques double pré- cision seront prises en charge par Nvidia dans leur implémentation OpenCL. Pour ce qui est des jeux de données de plus d’un million de trajets, il serait possible d’appliquer l’algorithmes en plusieurs passes contenant au maximum 220_trajets.

Une fois cet indice récupéré, il est nécessaire d’effectuer un nouveau calcul pour récupé- rer le temps de vol et la profondeur de l’amplitude. En effet, il va être nécessaire de remonter au trajet utilisé pour récupérer les informations de temps de vol, profondeur et angle. Pour se faire, il est nécessaire de retrouver l’indice de l’amplitude utilisé dans le signal et la profondeur de projection sur le trajet.

2.8.1.2 Extraction des informations supplémentaires

Un nouveau kernel a donc été développé pour extraire les informations de temps de vol et d’amplitude. Un simple parcours du signal qui correspond à l’indice n’est pas suffisant dans la mesure où plusieurs amplitudes d’un signal peuvent être égales. Il est donc nécessaire d’obte- nir une information de localité.

Pour chaque pixel, on effectue une projection du segment de trajet dont provient l’ampli- tude, puis on parcourt cet intervalle à la recherche de cette amplitude. Si plusieurs valeurs

d’amplitudes sont égales à la valeur recherchée, nous prenons arbitrairement la première. La résolution des images utilisées étant suffisamment élevée, l’erreur est considérée comme suffi- samment faible. Pour effectuer l’intersection entre la boite correspondent au pixel et le segment de trajet, on utilise un algorithme d’intersection optimisé [Williams et al., 2005]. Cette étape d’extraction est très peu coûteuse et ne dépasse par 1% du calcul de projection effectué au préalable. Une fois les informations récupérées, elles sont reportées dans l’interface de CIVA.

Le filtrage par dilatation n’est plus directement utilisable avec la notion d’angle. Le principe d’utilisation en post-traitement est, en revanche, conservé. Etant donné son faible coût, ce filtre n’a pas été reporté en OpenCL et c’est en Java côté host qu’il est effectué. Finalement, il va être possible d’obtenir une image plus lisse qu’avec le filtre initial. La figure2.15 présente la différence visuelle entre ces deux méthodes.

(a) Filtrage sans angle (b) Filtrage avec angle FIGURE2.15