Soutenance mémoire
Architecture multi-cœurs OMAP de Texas Intruments
L’architecture OMAP 4430 de Texas Instruments . vise les applications multimédia. Elle se base sur deux processeurs ARM Cortex A9 qui permettent de supporter les applications généralistes. Ces deux processeurs sont secondés par un Digital Signal Processor (DSP) de type C64x qui permet de supporter les nouvelles applications multimédia. Afin d’accélérer les applications multimédia et graphiques, l’architecture possède en particulier trois accélérateurs dédiés :
— un processeur graphique (GPU),
— un processeur de traitement d’images,
— un processeur d’encodage/décodage audio et vidéo.
D’autres accélérateurs permettent l’accélération du chiffrement par exemple. On peut assimiler cette architecture à un ensemble d’accélérateurs dédiés (Application-Specific Integrated Circuits (ASICs)) contrôlés par les processeurs généralistes. Le système est articulé autour d’un bus car le nombre de ressources reste modéré. La mémoire est cohérente, permettant ainsi de supporter un grand nombre de modèles de programmation.
Architecture many-cœurs hiérarchique P2012
L’architecture P2012 de ST/CEA se présente sous la forme d’une structure hiérarchique. Un premier niveau est constitué d’un réseau en grille 2D qui relie les différents clusters entre eux. Ensuite, chaque cluster contient jusqu’à 16 processeurs ainsi que des mémoires caches et des accélérateurs. Ces différentes ressources d’un même cluster sont reliées entre elles grâce à un réseau de type crossbar, ce qui permet des débits de communications importants entre les processeurs et les mémoires. Un processeur dédié à la gestion des tâches est inclus dans chaque cluster. L’architecture permet de faire fonctionner les clusters à des fréquences différentes (Globalement Asynchrone, Localement Synchrone), ce qui permet d’optimiser la consommation énergétique en réduisant la fréquence ou en éteignant les clusters non-utilisés. L’avantage de cette approche est qu’elle inclut un grand nombre de processeurs, supportant les modèles de programmation classiques à mi-chemin entre le multi-cœur et le GPU.
Architecture many-cœurs Tilera TilePro 64
L’architecture Tilera TilePro 64 vise les applications réseau. Elle doit donc être capable de traiter rapidement un grand nombre de données en parallèle. Elle est ainsi composée de 64 processeurs VLIW 3 voies. Ceux-ci sont interconnectés par un réseau sur puce de type grille 2D de 8 × 8 processeurs. Ce réseau est constitué de plusieurs réseaux, chacun dédié à un type de données (instructions, cohérence des caches, etc.). Chaque tuile est composée d’un processeur ainsi que de deux niveaux de mémoires caches. Les mémoires caches peuvent être utilisées selon un mode totalement cohérent. Celui-ci se base sur une méthode de cohérence hiérarchique. Chaque tuile est en charge de la cohérence d’une zone mémoire. Les mémoires caches peuvent aussi être utilisées selon un mode non-cohérent, offrant ainsi au programmeur la possibilité de gérer lui-même les transferts de données.
Synthèse des architectures multi-cœurs embarquées
A travers la présentation de ces architectures multi-cœurs, on peut remarquer qu’elles supportent une grande variété d’applications : le multimédia, le réseau, etc. Cependant, on peut extraire trois types de modèles :
— les architectures multi-cœurs,
— les architectures many-cœurs,
— les architectures many-cœurs hiérarchiques.
Le modèle multi-cœur permet d’obtenir de bonnes performances sur tous les types d’applications en utilisant des processeurs très performants et peu nombreux. Une mémoire partagée ainsi qu’une cohérence des mémoires caches permet de supporter tous les types de modèles de programmation et ainsi de porter facilement les applications sur ces architectures. Le modèle many-cœurs permet quant-à-lui d’accroître les performances brutes en augmentant le nombre de processeurs sur l’architecture. Ce modèle est devenu possible grâce à l’augmentation de la surface silicium disponible. Cependant, ce grand nombre de cœurs entraîne des contraintes en termes de communications entre les processeurs dont les latences augmentent. De plus, le modèle de mémoire partagée classique n’est plus tenable, car le coût des transferts de données nécessaires pour maintenir la cohérence devient prohibitif.
Pour palier ces problèmes, le modèle many-cœurs hiérarchique permet de conserver les avantages du multi-cœurs au sein d’un cluster, tout en autorisant un passage à l’échelle en intégrant un grand nombre de clusters de calcul.
Processeurs graphiques
Les appareils mobiles tels que les smartphones sont de plus en plus répandus. L’affichage est un élément très important pour ces appareils, car il est l’interface entre l’utilisateur et le téléphone. La concurrence dans le domaine des smartphones étant considérable, l’interface utilisateur est devenue un point essentiel pour démarquer un appareil d’un autre. Les constructeurs s’efforcent donc de rendre l’interface graphique de l’appareil la plus performante possible. Par ailleurs, les smartphones supportent de plus en plus d’applications graphiques complexes, tels que les jeux. Cependant, la consommation énergétique de ce type d’appareil reste un facteur très important à prendre en compte.
Évolution des processeurs graphiques
Les premiers accélérateurs
Les prémices des processeurs graphiques sont apparus dans les années 80. La carte iSBX 275 d’Intel prenait en charge la gestion de l’affichage à l’écran. De plus, elle permettait d’accélérer l’affichage de primitives 2D comme par exemple les lignes, les rectangles ou les bitmaps. Le premier processeur graphique est apparu avec le premier Commodore Amiga qui disposait d’un processeur dédié à la manipulation de bitmaps (déplacement, combinaison…), mais uniquement en deux dimensions. D’autres processeurs graphiques permettant d’accélérer le rendu d’éléments en deux dimensions sont ensuite apparus, par exemple le TMS34010 de Texas Instruments [40] avait un jeu d’instructions 32 bits classique avec des instructions spéciales pour le rendu des primitives en deux dimensions. L’IBM 8514 [41] était le système présenté comme le premier accélérateur à fonction fixe. Il était capable de supporter une résolution de 1024 × 768 pixels avec 256 couleurs. Cependant, il était encore limité à deux dimensions.
L’arrivée de l’accélération 3D
La première génération de GPU prenant en compte la 3D est arrivée avec les Vodoo Graphics de 3dfx Interactive en 1996, la TNT2 de NVidia et les ATI Rage. Le premier GPU était équipé de 4 Méga-octets de mémoire RAM qui fonctionnait à 50 MHz. Il prenait en charge les opérations sur le framebuffer et l’application des textures. La carte TNT2 [42] de NVidia était équipée de 32 MB de mémoire RAM qui fonctionnait de 90 MHz à 150 MHz. La carte disposait de deux pipelines de textures. Ensuite, les GeForce 256 de NVidia [43] et les ATI Radeon 7500 [44] sont apparus vers 1999. Ce sont les premières cartes à offrir une accélération complète du pipeline graphique. Les différentes parties du pipeline graphique n’étaient alors que paramétrables, ce qui limitait les possibilités d’utilisation.
Les premiers GPU programmables
Les premières cartes graphiques permettant la programmation du traitement des pixels (étage pixel shading) sont apparues avec l’ATI Radeon 9700 [45] et la carte NVidia GeForce FX [46]. La carte ATI Radeon 9700 était équipée de 8 unités de traitement des pixels et de 4 unités pour les sommets. Cette carte est la première à utiliser avantageusement un bus mémoire de 256 bits ainsi que 4 contrôleurs mémoire. La carte NVidia GeForce FX fut la première à disposer d’un bus mémoire de 256 bits chez NVidia. Elle était équipée de quatre unités de traitement des pixels, chacune étant constituée de deux unités arithmétiques pour les nombres entiers et d’une pour les nombres flottants. Le calcul General-Purpose Graphics Processing Unit (GPGPU) apparaît concrètement avec l’arrivée des cartes GeForce 6 [47] de NVidia ainsi que les Radeon X800 de ATI [48] courant 2004. Les cartes de la série NVidia GeForce 6 comportaient jusqu’à 6 unités de traitement des pixels ainsi que 6 unités de traitement des sommets et un bus mémoire de 256 bits. Les cartes ATI Radeon X800 possédaient 12 pipelines de traitements des pixels ainsi que 6 unités de traitement des sommets et un bus mémoire de 256 bits. Cependant, les GPU étaient encore composés de différents types de processeurs en fonction de leur utilisation dans le rendu graphique. Ces processeurs offraient alors des instructions spécifiques et des accès à des mémoires différentes, rendant ainsi leur utilisation complexe.
|
Table des matières
1 Introduction
2 État de l’art
2.1 Introduction
2.2 Architectures multi-cœurs embarquées
2.2.1 Choix architecturaux
2.2.1.1 Les processeurs
2.2.1.2 Modèles d’exécution
2.2.1.3 Modèle mémoire
2.2.1.4 Réseau d’interconnexion
2.2.1.5 Modèles de programmation
2.2.1.6 Architectures symétriques et asymétriques
2.2.2 Synthèse et comparaison des architectures multi-cœurs
2.2.3 Architecture multi-cœurs OMAP de Texas Intruments
2.2.4 Architecture many-cœurs hiérarchique P2012
2.2.5 Architecture many-cœurs Tilera TilePro 64
2.2.6 Synthèse des architectures multi-cœurs embarquées
2.3 Processeurs graphiques
2.3.1 Évolution des processeurs graphiques
2.3.1.1 Les premiers accélérateurs
2.3.1.2 L’arrivée de l’accélération 3D
2.3.1.3 Les premiers GPU programmables
2.3.1.4 Les architectures unifiées
2.3.1.5 Comparaison des architectures graphiques
2.3.2 Présentation du PowerVR MBX, un processeur graphique à architecture paramétrable
2.3.3 Présentation du ARM Mali 200, un processeur graphique à architecture programmable
2.3.4 Présentation de quelques processeurs graphiques à architecture unifiée
2.3.4.1 Imagination Technologies PowerVR SGX
2.3.4.2 Nvidia Geforce GTX680
2.3.4.3 AMD Radeon 7970
2.3.5 Synthèse des architectures des accélérateurs graphiques
2.4 Conclusions
3 Étude d’un pipeline graphique
3.1 Introduction
3.2 Description du rendu graphique
3.2.1 Partie sommets (Vertex)
3.2.2 Partie primitives (Triangle)
3.2.3 Partie fragments (Fragment)
3.2.4 Partie liée à la mémoire vidéo (framebuffer )
3.3 Implémentation séquentielle
3.3.1 Étude de l’implémentation séquentielle
3.3.2 Profilage du pipeline graphique
3.4 Implémentation parallèle
3.4.1 Découpage de l’application
3.4.2 Environnement de simulation
3.4.3 Parallélisation du rendu graphique
3.4.4 Résultats de profilage
3.4.5 Mesures par image
3.4.6 Parallélisation au niveau des données
3.5 Analyse des besoins d’un pipeline graphique
3.6 Vers une adaptation dynamique du pipeline graphique
4 Support de la dynamicité
4.1 Introduction
4.2 État de l’art des méthodes d’équilibrage de charge
4.2.1 Méthodes d’équilibrage de charge dans la littérature
4.2.1.1 Équilibrage de charge dans les grilles de calcul
4.2.1.2 Équilibrage de charge dans les architectures embarquées
4.2.1.3 Équilibrage de charge dans les processeurs graphiques
4.2.2 Comparaison des méthodes
4.2.2.1 Méthodes statiques
4.2.2.2 Méthodes dynamiques
4.2.2.3 Fonctionnement centralisé ou distribué
4.2.2.4 Concentration de la charge
4.2.3 Conclusion
4.3 Approche proposée pour l’équilibrage de charge
4.3.1 Modèle applicatif
4.3.2 Méthode de Load Balancing proposée
4.3.2.1 Surveillance de l’application
4.3.2.2 Calcul de charge
4.3.2.3 Prédiction de l’évolution de la charge
4.3.2.4 Adaptation du parallélisme
4.4 Conclusion
5 Architecture multi-cœurs supportant le rendu graphique
6 Conclusion
