Icare3D

Une petite analyse écrite il y a quelques mois maintenant sur l’évolution de l’informatique grand public vers des architectures de plus en plus dédiées eu calcul intensif sur les base des architecture de traitement de flux des GPU.
A l’époque, ATI semblait le plus en avance avec le futur R600, le CTM et le rachat par AMD, depuis il y a eu le G80 et CUDA. Les enjeux sont dans tous les cas de plus en plus d’actualité et le GPGPU devenu Stream Computing sort de plus en plus des laboratoires et sera sans contexte la technologie qui va faire parler d’elle dans les mois qui viennent.

J’ai pensé à ressortir ce petit article écrit à l’issue de mon stage de fin d’études pendant lequel j’ai travaillé sur ces problématiques car récemment il y a eu un article de David Strom dans Information Week sur les technologies majeures de 2007 faisant mention du GPGPU (http://www.informationweek.com/). Aujourd’hui le fondateur de PeakStream, une start-up proposant des solution logicielles pour le Stream Computing a également publié un article intéressant:  http://www.hpcwire.com/hpc/1209133.html.

Vision Technologique – Cyril Crassin – 20 Aout 2006

1 L’impasse des processeurs séquentiels

1.1 Le temps de la montée en fréquence

Pendant longtemps, l’augmentation des performances des processeurs centraux a été obtenue par l’augmentation de leur fréquence de fonctionnement. Cette augmentation était rendu possible par la diminution de la finesse de gravure des circuits permettant l’augmentation du nombre de transistors et donc de leur densité d’intégration (entraînant une diminution de la dissipation thermique). Ce processus est connu sous le nom de Loi de Moore. En plus de l’augmentation de la fréquence de traitement, cette réduction de la taille des circuits a permis d’intégrer de plus en plus d’unités de traitement dans les processeurs: Des unités de calcul flottant puis vectoriel (Jeux d’instructions MMX, SSE…), des mécanismes de pipelining et de parallélisation d’instructions, des unités de prédiction de branchements, des systèmes de cache de données évolués etc.

Toutes ces évolutions ont fournies pendant ces dernières décennies une augmentation permanente de la vitesse de traitement des algorithmes séquentiels, sans contrainte particulière imposée au programmeur dans la façon d’écrire les programmes pour profiter de cette augmentation de performances (mis à part pour les jeux instructions vectorielles, qui n’ont d’ailleurs jamais réellement été utilisés dans l’industrie).

Mais de nombreux problèmes commencent à se poser sur ce type d’architectures.

1.2 Limites du parallélisme d’instructions

Les processeurs centraux sont maintenant dotés d’architectures dites super-scalaires, composées d’un ensemble d’unités de calcul (ALU, Arithmetic and Logical Unit) capables de fonctionner en parallèle sur un flux d’instructions. Mais malgré l’augmentation du nombre de transistors disponibles, ces architectures permettent difficilement l’augmentation du nombre de ces unités de calcul. Il est en effet de plus en plus difficile d’extraire suffisamment de parallélisme au niveau des instructions d’un flux séquentiel pour permettre l’utilisation totale de ces unités supplémentaires. C’est pour cette raison qu’on été introduites les technologies dites d’Hyperthreading, permettant la répartition de flux d’instructions issus de différents processus de calcul sur ces unités. Mais ces mécanismes ne permettent pas de régler -et aggravent- un deuxième problème, celui de l’accès aux données.

1.3 Le problème de l’accès mémoire

Il a été observé depuis longtemps que l’architecture classique de Von Neumann sur laquelle sont basés ces processeurs centraux créée des goulots d’étranglement entre le CPU et la mémoire centrale dans laquelle sont stockées les données traitées.

Avec l’augmentation de la fréquence de fonctionnement ce problème est devenu de plus en plus critique et une grande partie des optimisations matérielles mises en oeuvre ces dernières années ont été dédiées au contournement de ce problème. De ce fait, de plus en plus de place a été prise sur le CPU pour de larges caches de données, des mécanismes de “prefetching” (récupération anticipée de données) et de réordonnancement d’instructions. Tout ceci représentant autant de place indisponible pour l’augmentation des ressources de calcul pur.

1.4 La fin de la montée en fréquence

Aujourd’hui, aux deux problèmes cités précédemment vient s’ajouter un troisième problème de difficulté de montée en fréquence des processeurs liée à un problème purement physique: la dissipation thermique. Les fabriquants ont en effet de plus ne plus de mal à réduire la finesse de gravure pour compenser le problème de dégagement de chaleur produit par la montée en fréquence.

Nous arrivons ainsi à un point ou les limites de la technologie actuelle de processeurs séquentiels

super-scalaires sont atteintes. Pour remédier au problème de la montée en fréquence, Intel et AMD commencent à proposer des architectures multi-cores, des processeurs centraux dotés de 2 ou 4 cores de type x86. Ces architectures, bien qu’elles n’offrent qu’un parallélisme très limité en largeur, permettent une exécution parallèle d’algorithmes threadés. Il s’agit ici d’offrir un parallélisme de haut niveau, ou parallélisme de tâches, dédié plutôt à une parallélisation à grosse granularité.

Mais la multiplication de cores génériques au sein d’un processeur va rapidement poser un problème d’efficacité : Une application ne peut se scinder en un nombre illimité de threads, et, passé les 4 ou 8 cores, les gains de performances diminueront pour cette raison. De plus, ce type d’architecture ne résout pas le problème de l’accès aux données.

2 Vers des architectures de calcul intensif

Alors que ces architectures multi-cores conservent toute la lourdeur des architectures CPU classiques, avec une majorité de transistors dédiés à la logique de contrôle et une minorité à la logique d’exécution. Les concepteurs de processeurs commencent à s’intéresser à de nouvelles architectures pour remédier à ce problème de montée en puissance. Ils s’intéressent en particulier aux architectures dites de “streaming” (ou “broadband”) dédiées à l’application d’un traitement relativement court et identique sur une masse très importante de données, sans interdépendance entre les traitements. Il s’agit de l’architecture matérielle introduite de manière radicale par le processeur Cell.

Ces architectures sont composées d’un ensemble d’unités de calcul, ou ALU (Arithmetic and Logical Unit), très simples, dotées de leur propre zone de mémoire réduite à accès très rapide. Ces unités sont spécialisées dans le calcul vectoriel (SIMD) et fonctionnent sur le modèle des DSP programmables, dédiés à la mise en oeuvre ultra rapide d’une tache unique. Elles gèrent elle-mêmes leur espace mémoire et les transferts des données nécessaires à partir de la mémoire centrale via un contrôleur DMA intégré, ce qui permet un recouvrement efficace des accès mémoire. Ces unités sont inter-connectées à un bus de transfert ultra rapide et contrôlées par une unité de traitement plus générique, dédiée au calcul séquentiel.

Avec de telles architectures, privées de l’ensemble des extensions dédiées à l’amélioration de l’efficacité des traitements séquentiels présents dans les processeurs classiques (cf. 1), la majorité des transistors sont dédiées à la logique d’exécution -ou de calcul- et non à la logique de contrôle ou au cache de données. Elles fournissent ainsi une puissance de traitement pur des dizaines de fois plus importante que les architectures classiques, pour les taches dédiées à ce type de parallélisation.

Ce modèle de traitement est déjà utilisée depuis plusieurs années par les GPU. Alors que le Cell fournit un modèle de streaming flexible, les GPU souffrent encore d’un certain nombre de restrictions et de contraintes de programmation. Mais le Cell ne fournit pas de compatibilité avec les applications PC grand public (architectures x86) et il est de ce fait réservé à des marchés de niches: Les consoles de jeux, ce processeur à été développé pour la PlayStation 3, ou les cartes professionnelles de calcul intensif (la carte Cell de Mercury Computer Systems).

3 Les besoins en calculs massifs de l’informatique personnelle

Le traitement massif de gros volumes de données a été longtemps réservé aux applications scientifiques de simulation lourde. On peut penser par exemple aux simulations physiques (Abaqus) ou aux rendus graphiques par lancer de rayons (Renderman). Ces besoins se déplacent de plus en plus vers l’informatique personnelle avec l’apparition de simulations physiques temps réel dans les jeux vidéo, l’encodage/décodage à la volée de flux vidéos, ou encore le besoin en visualisation précise et réaliste temps réel en CAO.

Tous ces calculs ont en commun un très haut potentiel de parallélisation massive au niveau des données ainsi qu’un besoin important en calculs vectoriels flottants. Dans tous les cas qu’il s’agisse de vidéo, de 3D, de calculs physiques il s’agit d’appliquer un même ensemble d’instructions relativement petit (on parle de kernel) à un très large ensemble de données (un flux). Ce code est très facilement parallélisable car il a peu, pour ne pas dire pas, de dépendances. Autrement dit à l’intérieur d’un kernel le résultat du calcul pour un élément donné ne dépend que de ses entrées et pas du résultat des calculs d’un autre élément du flux. De plus contrairement au code des applications bureautiques, il y a peu de branchement : tous les éléments d’un flux sont traités exactement de la même manière.

L’architecture actuelle des processeurs centraux est extrêmement mal adaptée à ces traitements pour lesquels les architectures de traitement de flux présentées précédemment sont dédiés.

4 Des GPU aux co-processeurs de traitement de flux génériques

Les constructeurs de matériel 3D (ATI et NVidia) ont bien perçue cette opportunité d’ouverture à de nouveaux marchés, la guerre actuelle autour de l’accélération physique pour le jeu vidéo contre la PPU d’Ageia en est une bonne illustration.

Vu l’évolution vers de plus en plus de généricité que suivent les processeurs graphiques et vu les nouveaux marchés applicatifs qui pourraient s’ouvrir aux constructeurs de matériel 3D, on peut facilement imaginer qu’a assez court terme, les processeurs que nous connaissons sous le nom de GPU deviennent de véritables co-processeurs de calcul parallèle génériques(stream processors). Ces co-processeurs pouvant ainsi être programmés pour prendre en charge efficacement, aussi bien l’accélération des API 3D temps réel que les API de dynamique ou de traitement vidéo.

La grande limitation à l’heure actuelle pour l’utilisation du processeur graphique comme co-processeur de calcul massif réside dans sa façon de la programmer. Historiquement, ces processeurs ont toujours été dédié à l’accélération matérielle des API 3D que sont OpenGL et Direct 3D. Ces API restent aujourd’hui le seul moyen d’accès à ce matériel. Il s’agit d’API de relativement haut niveau proposant des primitives standards de rendu 3D qui sont implémentées de manières spécifiques, et surtout généralement secrète, par les constructeurs. En effet, les algorithmes et architectures de calcul mises en oeuvre pour l’implémentation de ces fonctionnalités, ont pendant longtemps été déterminants pour la suprématie technologique (dans les jeux vidéos ou benchmarks dédiés) de tel ou tel constructeur.

L’évolution des GPU vers des stream processors va avoir pour principale conséquence de pousser les fabricants à ouvrir leur matériel, en offrant des moyens de programmation directe de ce dernier. Mais il faudra dans tous les cas savoir adapter les algorithmes séquentiels majoritairement utilisés à l’heure actuelle à ces nouvelles architectures. Le problème qui va rapidement se présenter sera la compatibilité entre ces matériels, chaque fabricant proposant sa propre architecture, la portabilité des logiciels développés deviendra alors une question critique.

5 Vers des architectures massivement parallèles au coeur de l’informatique personnelle

Les besoins de plus en plus présents du grands public pour des applications de calcul massif, la montée en puissance et en généricité des GPU et de leur architecture parallèle de traitement de flux, et l’impasse dans laquelle se trouve les processeurs centraux permet de se faire une idée relativement précise de l’informatique massivement parallèle de demain.

Tout d’abord proposés sous la forme de cartes d’extension comme les GPU, ces processeurs de calcul de flux vont devenir un composant incontournable de l’informatique personnelle puis vont se rapprocher progressivement du processeur central (multi-cores).

On peut ainsi imaginer dans un avenir relativement proche, des processeurs dotés d’un coeur de contrôle de type x86, tel que ceux que nous connaissons actuellement, entouré d’un ensemble important de petites unités de traitement du type des ALU présentes dans les GPU, destinées au traitement massivement parallèle pour les les applications graphiques, physiques ou encore le traitement vidéo. Il s’agit ainsi d’une introduction progressive d’une architecture de type Cell dans l’informatique personnelle, permettant comme dans toute l’histoire des PC, de conserver la compatibilité ascendante du jeu d’instructions (x86) dans un ou plusieurs coeurs standards peu puissants, tout en proposant des capacités nouvelles de calcul intensif.

Le rachat il y a quelques jours par AMD d’ATI, l’un des deux principaux fabricants de matériel 3D, conforte encore cette vision d’une implantation en profondeur des technologies de traitement de flux issues des GPU dans l’informatique personnelle (cf. le projet Torrenza). ATI donne de plus des signes d’ouverture de son matériel avec la présentation au Siggraph d’une API permettant l’accès direct à son matériel (le CTM, Close To Metal layer ). Intel donne également des indices de son intérêt pour ces architectures, via des rumeurs de projets de GPU haute performance, entretenues par l’embauche récente d’anciens ingénieurs de chez 3DLabs.

6 Le défi d’un nouveau paradigme de programmation

Ces architectures matérielles représenteront une véritable révolution dans la façon de programmer et le grand défi de ces prochaines années sera de savoir s’adapter et développer les technologies logicielles permettant d’en tirer efficacement parti dans les applications. L’exploitation de ce type d’architectures va en effet nécessiter un changement radical dans notre façon de concevoir des algorithmes. Elles imposent la prise en compte du parallélisme de données et du mode de fonctionnement en flux au coeur même des algorithmes. Alors que pendant longtemps la montée en puissance d’une ressource de calcul générique a permis au programmeur de s’abstraire totalement de ce genre de considérations, la parallélisation massive au coeur des architectures matérielles va pousser à l’adoption de nouveaux paradigmes de programmation ainsi qu’au développement d’algorithmes adaptés.

6.1 Un tournant pour le rendu 3D temps réel

L’évolution des GPU vers ces co-processeurs de calcul de flux génériques pourrait également marquer un tournant dans la programmation 3D temps réelle. Jusqu’a présent, l’utilisation de l’accélération 3D matérielle contraint en effet à l’utilisation de la méthode de rendu basée sur la rasterisation dont le pipeline est implémenté par ce matériel. La montée en puissance d’architectures génériques massivement parallèles va permettre l’ouverture de la visualisation temps réel à d’autres algorithmes de rendu que ceux proposés par les API temps réel que nous connaissons actuellement. On pense ainsi rapidement à la mise en oeuvre temps réel du lancer de rayons.