On nous l’avait vendu comme la grande annonce, l’événement de cet Intel Developer Forum, la bonne raison de se faire vacciner pour aller en chine… Nous parlons bien sur de Larrabee, le projet graphique d’Intel que nous avions déjà évoqué dans cet article. On attendait un tas de détails croustillants, voir même l’annonce d’un produit pour un peu plus tôt que prévu (on parlait jusqu’ici de fin 2008, date qui selon nos informations était avancée). Nous avions même profité des longues heures sans sommeil dans l’avion nous menant à Pékin pour chercher des jeux de mots vaseux (« Larrabee : cas », « Larrabee c’est où, dites ? »…). Et puis rien.

Dans sa keynote, Pat Gelsinger n’aura passé que deux minutes sur le « cas » Larrabee. Il a bel et bien confirmé l’existence du projet et sa filiation avec le projet de recherche Tera-Scale. Le Senior Vice President d’Intel s’est cependant refusé à classer Larrabee dans une catégorie particulière, voire même d’évoquer à quoi il pourrait servir. Nos tentatives insistantes nous aurons juste valu l’évocation de scénarios financiers. Le message étant que Larrabee est l’ennemi du GPGPU, une affirmation supportée par une citation d’un employé de Microsoft Research qui nous explique que le projet Larrabee "mettra fin au débat sur l’utilité du GPGPU par la supériorité de son offre".


Pour comprendre cette présentation trop courte et quelque peu capillotractée, quelques explications sur le contexte peuvent être nécessaires. Depuis quelque temps, le sentiment chez les joueurs est qu’il est plus utile de remplacer sa carte graphique que son processeur. Un sentiment sur lequel jouaient ATI et Nvidia et qui va forcément à l’encontre du marketing d’un fabricant de processeur. La chose peut sembler ennuyeuse en termes d’image, mais il faut relativiser : le marché des joueurs, s’il n’est pas négligeable, reste relativement petit à l’échelle des revenus d’Intel. S’en est suivie une série de chiffres plus ou moins représentatifs pour mettre en avant la capacité de calcul brute des GPU. On parle alors de centaines de Gigaflops voir de Teraflops pour les plus audacieux. Une puissance brute disponible dans une machine mais qui n’est utilisée que dans le cadre des jeux. De cette constatation ont découlé deux projets bien réels, chez Nvidia on parle de CUDA et de CTM (Close To Metal) chez ATI/AMD. Les méthodes diffèrent dans la pratique mais l’idée globale est la même : offrir une interface de programmation qui permette d’accéder à la puissance brute des GPU pour réaliser d’autres tâches.

Des solutions embarrassantes…

Conceptuellement, les GPU sont des puces ultra spécialisées, taillées uniquement pour le rendu graphique. Il aura d’ailleurs fallu attendre les Radeon X1900 chez ATI et les GeForce 8800 chez Nvidia pour que la simple possibilité de récupérer des données de calculs à divers endroits du pipeline graphique soit effective. Si nous étions mauvaise langue, nous pourrions parler de bidouillage. S’ajoute par-dessus la difficulté de programmation de ces choses. Pour Nvidia, on utilise un langage proche du C, la difficulté principale se situant au niveau de l’encapsulation des données. Pour le CTM d’AMD, nous n’avons pas honte d’avouer que nous nous sommes endormis à la lecture du white paper décrivant son langage de programmation. Bien entendu, il faut que les traitements répondent à des règles très précises afin de pouvoir être calculés par un GPU. Ultra spécifique, donc.

Pour Nvidia et AMD, le marché cible est assez clair puisqu’ils visent en priorité des solutions spécialisées dans les traitements financiers. Des problèmes que l’on qualifie d’ «embarrassingly parrallel» : ils sont faits pour être découpés en morceaux et traités par une multitude de cores (ici, les unités de calcul du GPU). Vous commencez peut-être à comprendre l’embarras d’Intel vis-à-vis de ces solutions qui viennent concurrencer leurs processeurs plus spécialisés, l’Itanium en tête. Que cette concurrence soit réelle ou fictive, elle fait de toute façon parler dans les médias, une réaction était donc nécessaire.


Initié à l’époque où Pat Gelsinger était encore Chief Technology Officer d’Intel, le projet Tera-Scale visait à répondre à une question fondamentale : comment passer effectivement d’une poignée de cœurs à plusieurs dizaines. Une augmentation qui demande que l’on résolve un certain nombre de problèmes comme l’intercommunication entre les cœurs, les stratégies de gestion mémoire et d’autres subtilités. Pour mettre en avant ces problèmes, Intel avait développé une puce portant le nom de code Polaris. Un « test chip » utilisant pas moins de quatre-vingt cœurs. Ceux-ci n’avaient cependant rien à voir avec les cœurs que l’on connaît dans nos processeurs plus classiques, chacun d’entre eux n’utilisant que 2 millions de transistors (un Core 2 Duo en compte 291 millions). Il s’agit de mini cores réduits à leur plus simple expression : des unités de calcul « brutes » et rien d’autre. Pas de gestion de logique ou de quoique ce soit d’autre (cache, prefetchers et autres choses qui font la complexité actuelle de nos puces), Polaris sert surtout de démonstration technologique. Justin Ratner et Pat Gelsinger ont d’ailleurs fait la démonstration du Polaris à plus de 6 GHz (6.26). Consommant 191 watts dans cette configuration, la puce a dépassé les 2 Teraflops de puissance brute. Une première accueillie sur scène par un pseudo feu d’artifice qui ne restera pas dans les annales de la pyrotechnie…

Ce qu’Intel ne nous a pas dit…

Alors, qu’est ce que Larrabee en pratique ? Il s’agit ni plus ni moins d’une autre puce issue du programme de recherche Tera Scale. Contrairement à Polaris, il s’agit cette fois ci d’un (futur) produit, bien réel, utilisant pour sa déclinaison la plus haut de gamme seize cœurs dans sa version actuelle de développement, chacun d’entre eux étant une grosse machine à calculer, basée sur une unité vectorielle. Elle hérite d’une autre avancée du projet Tera Scale, un ring bus bidirectionnel (à l’intérieur de la puce) d’une largeur de 1024 bits afin de résoudre les problèmes d’interconnections. Le concept de « die stacking » qui consiste à superposer une couche de mémoire sous le die du CPU n’est pour l’instant pas encore utilisé. Au-delà de ces caractéristiques, c’est clairement la manière de programmer la puce qui reste la chose la plus intéressante.



Larrabee est une puce x86 (où IA-32 si l’on veut faire plaisir à Intel). Elle en réutilise le jeu d’instructions, ce qui n’est pas sans conséquences. Sur le plan technique, ce choix est justifié par le fait que la programmation x86 est connue et maîtrisée par les développeurs et les divers fabricants d’outils (contrairement aux choix techniques de CUDA et de CTM). Reste que si x86 est un jeu d’instructions relativement complet grâce aux ajouts des diverses versions de SSE, il lui manque un certain nombre d’équivalence pour faire tourner des programmes graphiques actuels du type HLSL (le langage utilisé par les shaders). Nous évoquions dans cet article la présence dans SSE4 d’un certain nombre d’instructions qu’Intel qualifiait de lui-même comme servant à exécuter du code HLSL. La boucle serait donc bouclée. Avec une architecture ouverte, Larrabee dépasse le cadre d’un simple GPU lié à une version de DirectX. Il s’agit d’une puce à part entière, spécialisée dans les calculs «embarrassingly parrallel» et qui pourra aussi faire office de GPU. Pour en revenir au SSE4, nous avons remarqué un petit détail lors d’une présentation de Penryn cette après-midi : il intègre des instructions permettant de contrôler un « accelerator ».

Un quoi ?

Il est temps de faire le lien avec un projet que l’on avait entrevu dans un IDF précédent, Geneseo. Il s’agit d’une extension de la norme PCI Express 2.0 développée par Intel et IBM qui apporte quelques nouveautés comme des services de translation d’adresse mémoire ou la capacité de partager un périphérique. De ces choses naît le concept d’ «accelerator», sorte de version glorifiée de ce que l’on appelait jusque-là une carte d’extension. Avec Geneseo, les interactions entre un processeur et un coprocesseur (accelerator) deviennent à la fois plus profondes et plus simples. De là à penser que Larrabee reposera sur Geneseo, il n’y a qu’un pas…

Nous évoquions un peu plus tôt l’intérêt technique du choix de x86, il nous faut pour finir cette présentation parler des autres conséquences de ce choix. Il n’est pas anodin sur le plan du marketing : x86 est avant tout le fond de commerce d’Intel. S’en servir permet de montrer qu’il n’est pas obsolète et qu’il peut encore s’adapter au parallélisme massif. C’est également un pari sur le long terme puisque si l’on peut supposer que Larrabee fera ses débuts sur une carte PCI Express, le but final est l’assimilation par le CPU. A la manière du 387 et du 486 DX pour les plus anciens d’entre nous. Reste la question de l’universalité de la méthode. Une nouvelle extension du x86 accompagnera Larrabee, et il est fort probable que celle-ci soit ouverte à la manière des différentes versions de SSE. Si Larrabee venait à remplir ses promesses (proposer un « tueur » de GPU), on pourrait imaginer que des constructeurs concurrents se jettent dans la brèche en proposant leur propre «accelerator» x86 massivement parallèle… pour peu qu’ils disposent d’une licence x86. Pour AMD, la question ne se pose même pas. La situation serait par contre beaucoup plus compliquée pour Nvidia. Reste que pour l’instant la question est totalement hypothétique. On ne sait rien des performances réelles de la puce ou de la manière dont elle sera acceptée. Et il faudra de toute façon attendre fin 2008 ou début 2009 avant de voir ces produits arriver, c’est en tout cas le son de cloche que l’on pouvait tirer de cet IDF. Une affaire qu’on ne manquera pas de suivre. Nous ne sommes plus à une surprise près dans l'affaire Larrabee…