Techniques et stratégies d’optimisation

Le kernel OpenCL doit être modifié et adapté au besoin de l’architecture reconfigurable. Pour cela, des optimisations s’avèrent indispensables pour améliorer d’avantage l’efficacité du traitement de données et optimiser les ressources.

Le déroulage de boucle (loop unrolling) Il s’agit d’une technique d’optimisation des boucles visant à augmenter la rapidité d’exécution. On duplique le corps de la boucle de manière à éviter de répéter l’instruction de saut. On utilise cette technique pour permettre aux compilateurs AOC d’optimiser l’exécution des boucles.

Spécification de la taille du groupe de travail La spécification de la taille du groupe de travail à utiliser au sein du kernel est important. Le compilateur AOC repose sur cette spécification pour optimiser d’avantage l’utilisation des ressources matérielles du kernel sans impliquer des éléments logiques en excès. Sans cette spécification, le compilateur assume une valeur par défaut, qui dépend du temps de compilation et des contraintes d’exécution. En spécifiant la taille du groupe de travail, AOC alloue exactement la quantité demandée des ressources matérielles pour bien gérer les sous-groupes de travail dans un groupe.

Spécification du nombre d’opérateurs La possibilité de spécifier le nombre d’opérateurs (unités de calcul) présente un avantage par rapport aux FPGAs. Ceci augmente d’avantage l’efficacité du traitement de données d’un kernel OpenCL. On peut demander au compilateur AOC de générer

4.8 Résultat expérimentaux et comparaison de performance 134 des unités de calcul multi-kernel. Chaque unité de calcul est capable d’exécuter multiple groupes de travail simultanément. Cette spécification doit être utilisée avec une précaution, car la multiplication des unités de calcul accroître le débit de données mais cela au détriment de la bande passante de la mémoire globale (l’accès séquentielle à la mémoire globale entre les différentes unités de calcul diminue l’effet du parallélisme). En spécifiant le nombre des unités de calcul, AOC distribue les groupes de travail sur les différents unités de calcul.

Spécification du nombre des unités SIMD Pour augmenter l’efficacité du traitement d’un kernel OpenCL, on peut spécifier le nombre des sous-groupes de travail dans un groupe de travail que AOC exécute en opérations SIMD. En spécifiant le nombre des unités SIMD, AOC reproduit l’exécution des données par rapport à la valeur spécifiée à chaque fois que cela est possible.

Optimisation des accès mémoire Les accès mémoires sont à optimiser au sein d’un kernel pour améliorer l’effet du parallélisme. On peut minimiser l’espace occupé par les blocs de mémoire locale en spécifiant la taille des pointeurs. Il est souvent souhaitable aussi de spécifier le type de la mémoire globale où le processeur hôte peut allouer un buffer. Si non, le processeur hôte utilisera toujours la mémoire qui lui définie par défaut.

4.8 Résultat expérimentaux et comparaison de performance

Le tableau 4.10 résume le pourcentage d’utilisation des ressources de deux versions d’implémen-tation OpenCL. La colonne “Avant optimisation “ donne les ressources utilisées de l’implémend’implémen-tation OpenCL telle qu’elle a été implanté sur GPU et sans aucune optimisation. Les blocs fonctionnels utilisent 120 des éléments logique, 65 des registres logiques, 87 des blocs mémoire et 48 des blocs DSP. Afin d’accélérer tous les blocs fonctionnels, nous avons implémenté les optimisations discutée dans la section 4.7.4 au sein de chaque kernel OpenCL. Le tableau 4.10 colonne “après optimisation” montre le nouveau pourcentage d’utilisation après avoir implanté des optimisation des traitement de données et de la gestion des accès mémoire. Par conséquence tous les blocs fonctionnel exploite au maximum des ressources et peuvent être accélérés sur le FPGA.

Table 4.10: Pourcentage d’utilisation des ressources FPGA (%)

Avant Optimisation Apres optimisation

Blocs Fonc- tion-nel Utilisation des Element logique Registres Logiques blocs mémoire blocs DSP Utilisation des Elements logique Registres Logiques blocs mémoire blocs DSP FB1 35 19 22 17 34 19 20 17 FB3 40 20 26 19 33 20 26 19 FB4 29 18 20 13 16 18 20 13 FB5 6 3 6 0 6 3 6 0 FB6 11 5 13 0 8 5 13 0 Total (ms) 121 65 87 49 97 65 85 49

Pour évaluer l’implémentation OpenCL sur FPGA, nous avons utilisé la même méthodologie d’éva-luation que précédent. Les résultats sont obtenus un utilisant le jeu de donnée réel. Pour évaluer les performances de l’implémentation de l’agorithme sur FPGA, nous utiliserons différents types du GPU des deux tableau 4.5, 4.6. Quatre GPU embarqués sont utilisés à savoir : le GPU de la XU4, Tegra K1,

Tegra X1 et un GPU haut-de-gamme de la machine bureau. Le tableau 4.11 résume les gains obtenus par l’architecture proposée de l’FPGA comparés à une implantation logicielle sur les GPUs. Les résul-tats sont obtenus avec 5000 particule et pendant 500 itération de l’exécution de l’algorithme. Les gains obtenus de l’accélération matérielle sur FPGA sont considérables par rapport à l’implémentation sur les GPUs. L’implémentation OpenCL sur FPGA donne les meilleurs résultats par rapport aux GPUs. En effet, le gain maximum obtenu sur le FPGA est de 8x fois par rapport au GPU haut-de-gamme, 10x fois par rapport au 256 cœurs CUDA, 12x fois par rapport à 192 cœurs CUDA et 18x fois par rapport à 8 SIMD GPU. En majorité, tous les blocs fonctionnels ayant un degré de parallélisation fort ce qui implique qu’ils bénéficient fortement de leur architecture matérielle. Plus le degré de parallé-lisation est importante, plus le gain lors de l’utiparallé-lisation d’une architecture matérielle est important. Cependant, le nombre d’utilisation des éléments logiques est est assez important pour l’ensemble des blocs de l’algorithme (97%, tableau 4.10).

FBs ARM - GPU SoC XU4 ARM - GPU SoC K1 ARM - GPU SoC X1 Machine bureau Hôte - FPGA Octa-Coeurs ARM GPU Quad-Coeurs ARM GPU Quad-Coeurs ARM

GPU Hôte GPU

Haut- de-gamme Hôte FPGA FB2 4.01 4.83 - 4.62 - 2.33 2.01 FB1 90.06 - 51.66 38.33 31.33 - 3.48 FB3 56.08 - 32.17 23.86 19.50 - 2.16 FB4 33.90 - 19.45 14.43 11.79 - 1.31 FB5 17.30 - 9.65 7.15 7.153 - 0.65 FB6 4.84 - 2.7 2.033 1.743 - 0.18 Total (ms) 172.28 120.46 90.42 73.84 9.79

Table 4.11: Comparaison des temps d’exécution global entre GPUs et FPGA

Nous avons vu dans la section 4.5 que pour augmenter la consistence des résultats de localisation en environnement large, il faut augmenter le nombre de particules. Pour évaluer les performances de l’architecture proposée vis à vis aux contraintes de l’environnement réel, nous donnons dans la figure 4.46 les temps d’exécution global pour différentes architectures en fonction du nombre de particules. Pour un grand nombre de particules, l’accélération matérielle de l’algorithme fournit par le FPGA répond aux contraintes temps réel. Par conséquence, même si un grand nombre de particules est nécessaire pour un environnement plus complexe, l’implémentation FPGA sera toujours efficace et peut opérer en temps réel. En outre, les résultats obtenus sont prometteurs en terme de puissance de calcul, les temps obtenus sur le FPGA sont beaucoups plus améliorés par rapport à un GPU haut-de-gamme et par rapport à la TX1 le GPU embarqué le plus puissant à ces jours.

4.8 Résultat expérimentaux et comparaison de performance 136 16 256 1024 4096 16384 65536 10⁰ 10¹ 10² 10³ 10⁴ Temps, t (ms)

Temps du traitement global FPGA

High−end GPU GPU TX1 GPU TK1 GPU XU4

Figure 4.46: Comparaison des temps d’exécution global entre GPUs et FPGA pour différents nombre de particules

La figure 4.47 montre une comparaison du CPP entre les quatre architectures étudiées. Pour peu de particules, le CPP demandé est grand pour toutes les architectures parallèles. En augmentons le nombre de particules, le CPP du l’architecture dédiée demeure à une valeur minimal par rapport aux GPUs. 0 1 2 3 4 5 6 7 x 10⁴ 10¹ 10² 10³ 10⁴ 10⁵ 10⁶ 10⁷ Nombre de Particules CPP

Cycle Par Particule GPU XU4 GPU TK1 GPU TX1 GPU High−End FPGA

Figure 4.47: Comparaison du cycle par particule entre les GPUs et le FPGA

On étudie dans la figure 4.48, le facteur d’accélération global du FPGA par rapport. aux différents GPUs Le facteur d’accélération est donné en fonction du nombre de particule. Avec un nombre de particules minimal, l’implémentation du FPGA fournit les meilleurs résultats par rapport au GPUs et on obtient les meilleurs facteur d’accélération. Ceci est expliqué par le fait que le FPGA est largement rapide qu’il n’est pas affecté par le temps du transfère. Au contraire, les performances des GPUs sont dégradées avec peu de particules puisque le temps du transfère est suffisamment large par rapport aux temps du traitement au sein du kernel. Le tableau 4.12 synthétise une comparaison du transfère DMA entre les différentes architecture. Le transfère DMA entre le processeur hôte et FPGA via le bus PCIe est beaucoup plus rapide que celui dans les autres architectures ARM-GPU. Plus le nombre de particules augmente, le fatceur d’accélération du FPGA par rapport au GPU décroît. Ceci

par-ce-que le degré de parallélisation du GPU augmente et devient important (plus d’unité de calcul seront utilisées pour traiter les particules) et par conséquence le temps d’exécution global diminue. Toutefois, pour un plus grand nombre de particule, le degré de parallélisation devient limité dans le GPUs. Autrement dit, les GPUs ne dispose pas d’assez d’unité de calcul pour traiter une large quantité de particules. Au contraire, en augmentant le nombre de particule, on peut exploiter au maximum les performances du FPGA et donc les temps d’exécution sur le FPGA diminuent ce qui augmente le facteur d’accélération par rapport aux GPUs.

10⁵¹ 10² 10³ 10⁴ 10⁵ 10 15 20 25 30 35 40 45 Acceleration Globale Nombre de particules Acceleration FPGA/XU4 FPGA/TK1 FPGA/TX1 FPGA/High−end GPU

Figure 4.48: Comparaison du facteur d’accélération entre les GPUs et le FPGA

Architectures Temps de transfère GB/s XU4 ARM-GPU 0.85

TK1 ARM-GPU 1.22 TX1 ARM-GPU 1.53 Machine Bureau Intel-GPU 1.98 Arria 10 Intel-FPGA 2.923

Table 4.12: Comparaison du temps de transfert entre un transfert DMA sur les architectures XU4, TK1, TX1 et un transfert via le bus PCIe sur la station de travail et l’Arria 10

L’architecture proposée sur FPGA par l’OpenCL, dispose de très bonnes performances pour les blocs fonctionnels ayant une forte degré de parallélisation et disposant de plusieurs mémoires. Elle permet de réaliser en parallèle des traitements très importants. Cette architecture est très adaptée dans le cas du FastSLAM2.0 monoculaire à large échelle fonctionnant avec un large nombre de particule et qui nécessite de nombreux calculs indépendants.

4.9 Bilan

L’étude du FastSALM2.0 monoculaire nous a permis de définir un système complet permettant de résoudre la problématique du SLAM. Pour cela, nous avons optimisé son implantation tout d’abord sur une architecture homogène intégrant plusieurs cœurs CPU. Cette première version d’optimisation résulte d’un système de SLAM capable de cartographier une zone très restreinte dans l’environnement. Nous avons dû limiter le nombre de particules utilisées par le filtre pour respecter les contrainte de temps réel et la nature de l’environnement.

4.9 Bilan 138 Pour pouvoir cartographier une plus large zone, nous avons choisi d’étudier, implanter et optimiser l’algorithme FastSLAM2.0 sur une deuxième variante d’architecture. Cela a nécessité tout d’abord des modifications et des réécritures algorithmiques du FastSLAM2.0. Ces modifications ont rendu l’algorithme consistant dans des environnements large à grande échelle. Cependant, cela était au détriment des performances temps réel. Pour résoudre ce problème, nous avons proposé un premier modèle conçu autour d’une architecture hétérogène intégrant un CPU et un GPGPU. Nous avons pu obtenir grâce à ce modèle un facteur d’accélération global de 23x avec le GPU embarqué le plus puissant à ce jour. Notre étude à démontré que l’adéquation algorithme architecture est indispensable pour obtenir des performances satisfaisantes. De plus, nous avons démontré via une comparaison entre OpenCL et OpenGL que la nature du langage utilisé pour le développement en GPU est important, son choix adéquat pourrait dans certain, permettre d’optimiser de plus l’algorithme et de bénéficier de mieux des spécificité de l’architecture du GPU.

Malgré ces optimisations importante sur l’architecture massivement parallèle, la taille de l’envi-ronnement reste relativement restreinte, ceci est dû que pour certain envil’envi-ronnement plus complexe, l’incertitude des particules dépend très fortement sur le nombre de particule utilisée. Ceci nous amène donc à proposer un deuxième modèle conçu autour des architecture reconfigurable dédiées. Pour cela nous avons défini une architecture matérielle intégrant un CPU et un FPGA entièrement dédiée au FastSLAM2.0 monoculaire. L’implémentation a été aboutie en utilisant un langage de synthèse de haut-niveau au lieu des langages traditionnels afin de minimiser le temps développement. Nous avons comparé les résultat d’implémentation sur notre architecture matérielle par rapport à l’implémentation logicielle sur les différent GPUs embraqué grand public existant. Les gains obtenus sont conséquent même par rapport aux GPUs haut-de-gamme qui disposent actuellement d’un nombre énorme de pro-cesseurs de calcul. La multiplication des cœurs du calcul engendrant un fort parallélisme permettrait, dans notre cas, une meilleur répartition de calcul. Par conséquence, cela résulte d’un système de SLAM qui présente un compromis entre la consistance des résultats dans des environnement aussi complexe sans dégradation des performances temps réal.

Finalement, l’utilisation d’une architecture programmable associée à un processeur standard sembre être, à ce jour, la solution adéquate pour des applications de SLAM temps réel. Les parties qui ne demande pas d’un fort parallélisme ni de ressources importantes, peuvent être traités sur le processeur CPU standard. Tandis que ceux demandant un fort parallélisme peuvent être accéléré sur le FPGA. Cela est devenu possible, aujourd’hui, grâce aux développement des interfaçage avec un bus de données suffisamment rapide qui minimise le problème des accès mémoire.

Chapitre 5