Apple met les pieds dans la guerre du GPGPU

Arnaud de la Grandière |
Les cartes graphiques qui équipent nos machines sont des monstres de puissance brute : un processeur comme le RV770 d'ATI déploie un téraflops (voir Du cinéma 2.0 dans Mac OS X 10.5.5?) alors qu'un Core 2 Duo moyen ne grimpe qu'au quart de ce chiffre.

Toute cette puissance dédiée au seul rendu de modèles 3D, si beaux soient-ils, c'est un peu du gâchis. D'où l'idée de faire plus ample usage de ces processeurs pour toutes les tâches du quotidien, un peu comme un super co-processeur (d'ailleurs à ce stade on pourrait se demander qui est le co-processeur de qui…).

Une réserve de puissance
La technique promet de donner un sacré coup de fouet à nos machines, d'autant qu'elle pourra théoriquement être mise en œuvre sur n'importe quel ordinateur équipé d'une carte graphique.

Ces processeurs sont cependant archi-spécialisés dans des tâches spécifiques, propres au broyage de coordonnées 3D à tirelarigot : calcul trigonométrique, interpolation linéaire, calcul décimal et structure parallèle, voilà les maîtres mots.

Le GPU n'est pas à même de suppléer totalement au CPU, seuls certains calculs s'y prêteront particulièrement, notamment ceux qui se plieront facilement au parallélisme. Par opposition au calcul séquentiel, le calcul parallèle consiste à parceller une tâche pour en exécuter plusieurs composants simultanément. L'avènement des machines multiprocesseurs et multicores d'une part, et l'implémentation des vertex shaders de l'autre, ont d'ailleurs constitué une première étape qui a rapproché la nature de certaines tâches exécutées par les CPU et les GPU.

Pour les calculs qui s'y prêtent en revanche, le gain devrait être substantiel, puisque le GPU est à même de faire un calcul donné jusqu'à 40 fois plus vite que le CPU. De quoi rendre nos machines actuelles méconnaissables !

Une nouvelle jungle
Si l'idée d'exploiter ces processeurs graphiques pour des tâches moins spécifiques n'est pas née d'hier, puisqu'on en faisait les premières applications dans le domaine scientifique, ça n'est pourtant que ces derniers mois que les initiatives s'accélèrent. Et les constructeurs de retomber dans leurs vieux travers, avec chacun leur propre langage permettant d'exploiter leurs cartes maison.

La logique économique n'est pas toujours frappée au coin du bon sens : ainsi, le premier constructeur à mettre une telle fonction à disposition des développeurs a-t-il plus de chances de voir l'initiative se transformer en un surcroît de ventes de ses cartes auprès des utilisateurs finaux.

Pour les plus anciens utilisateurs d'ordinateurs, cela rappellera sans doute des souvenirs, comme les différents standards de cartes sonores sur PC avant que SoundBlaster ne s'impose, ou encore la guerre des cartes 3D en l'absence d'API génériques.

On prend les mêmes, et on recommence : premier à ouvrir le feu, NVidia avec Cuda, suivi mollement par ATI avec Stream Computing, et même Intel s'y met dans une certaine mesure avec son processeur Larabee, alors que Microsoft promet de quoi gérer la chose dans DirectX 11, et RapidMind propose de son côté RMDP.

En outre, NVidia a également annoncé l'accélération matérielle de PhysX, le modèle physique d'Ageia, dont elle a fait récemment l'acquisition et qui nécessitait autrefois une carte spécifique. Son accélération matérielle pourra désormais se faire directement à l'aide des GPU de NVidia. Adobe de son côté a fait une impressionnante démonstration d'une version prototype de Photoshop tirant parti de Cuda.

S'il s'agit d'un calcul à court terme qui peut payer, en revanche une fois que tous les constructeurs ont sorti leur SDK, on en arrive à un véritable casse-tête pour les développeurs qui doivent supporter toutes les plate-formes, et donc tous les langages !

Et c'est là que l'on constate les limites structurelles du marché : le bateau n'a pas de capitaine. Les fabricants de matériel fabriquent, les éditeurs de logiciels éditent, mais toute l'industrie ignore royalement les contraintes qu'elle se génère elle-même. Toute ? Non ! Quelques fabricants portent également la casquette d'éditeur, et il est tout dans leur intérêt de faire en sorte de concilier ces différents aspects.

Apple place ses pions
Ainsi, Silicon Graphics, une des dernières sociétés avec Apple à produire à la fois ses machines et son OS, a-t-elle été à l'initiative d'OpenGL en 1992. De même aujourd'hui, c'est Apple qui remet bon ordre à cette nouvelle cacophonie, en mettant au point OpenCL, et en le proposant comme standard ouvert, dont elle a confié la gestion à Khronos Group (le même consortium qui gère OpenGL depuis 2006).

L'intérêt pour Apple est limpide : en tant que constructeur, la firme de Cupertino fait appel à tous les fournisseurs sur toute sa gamme d'ordinateurs, que ce soit ATI, Nvidia, ou Intel. Elle a donc tout intérêt à ce que les développeurs puissent exploiter facilement toutes les cartes embarquées dans les différents modèles de Mac. Et en tant que développeur de son propre OS, Apple a toute l'expertise et la légitimité requise pour mettre au point ce nouveau standard, qui est appelé à dépasser les frontières de ses machines.

L'atout d'une solution unique
Les rumeurs avaient bruissé quelques jours avant l'annonce d'OpenCL au sein de Mac OS X Snow Leopard durant la dernière WWDC. Le PDG de NVidia lui-même, Jen-Hsung Huang, avait annoncé une semaine avant l'évènement qu'Apple en savait long sur Cuda et s'apprêtait à faire une annonce dans ce domaine, bien que l'appellation retenue aurait été différente.

Et de fait, les différences ne se sont pas arrêtées au simple nom. En proposant un standard qui fonctionne avec toutes les cartes, Apple frappe un grand coup et risque bien de s'octroyer les faveurs des développeurs : pourquoi programmer plusieurs fois la même chose pour chaque carte en utilisant chaque kit, quand on peut s'adresser à toutes avec une seule et même commande ?

Mieux encore, pourquoi se cantonner à DirectX 11, qui proposera la même technologie, mais uniquement sur Windows, quand OpenCL fonctionnera aussi bien sur Mac OS X, que Linux ou Windows?

Khronos Group était présent au Siggraph qui vient de s'achever à Los Angeles et le groupe de travail dédié à OpenCL démontrait bien que les langages propriétaires sont en la matière un combat d'arrière garde, puisque parmi les acteurs industriels qui ont décidé de s'investir dans le projet, on trouve notamment AMD (qui a racheté ATI il y a deux ans).

En outre, n'oublions pas qu'Apple travaille également à une autre technologie multiprocesseur pour Snow Leopard, du nom de Grand Central : cette gare de triage permet d'optimiser la répartition des opérations multithread sur différents processeurs.

Plus que jamais donc, le parallélisme sera le maître mot des logiciels de demain, et pour peu que Grand Central se charge également de dispatcher les calculs vers OpenCL, en traitant ainsi le GPU comme un simple processeur supplémentaire, Snow Leopard risque de donner un sacré coup d'accélérateur aux Macs d'aujourd'hui et de demain.

Ajoutez à l'équation le nouveau compilateur LLVM (voir Apple tire le jus des processeurs), et vous comprendrez que Mac OS X 10.6 n'a rien d'une simple mise à jour de maintenance et d'optimisation classique. Avec de telles cartes en main, Apple a une chance de marquer une sacrée différence avec Windows… sur des machines pourtant identiques d'un point de vue architectural.

avatar josephsardin | 
Bien bien bien tout ça...
avatar Anonyme (non vérifié) | 
"Avec de telles cartes en main, Apple a une chance de marquer une sacrée différence avec Windows… sur des machines pourtant identiques d'un point de vue architectural." Cette phrase résume tout : le Mac n'est pas un PC comme les autres : il possède OS X -- et les optimisations et nouvelles technologies de Mac OS X Snow Leopard feront des Macs des machines qui tirent parti de la puissance mise à disposition par le matériel. Enfin, il faut espérer...
avatar bigmac2 | 
Exellent article!!
avatar Anonyme (non vérifié) | 
Résumé de l'article "de nos jours, il ne fait pas bon être programmeur !!"
avatar nicolas | 
euh...j'ai un iBook G4 1,2 GHz avec une ATI9200 32Mo ah ben, on dirait que SnowLeopard n'est pas pour moi....snif...obligé d'acheter un MacBookPro... la vie est dure :/
avatar deftones | 
@ Nicolas Lol... Cela dépend des programmes que tu utilises ou que tu développes. Si tu fais à fond de la puissance de calcul, je pense que ton G4 doit être limite depuis quelques temps, non? Je fais du dév d'applicatifs ne faisant guère de calculs de grande puissance ;) Je pense donc que mon MacBook (pas pro :P) me servira encore longtemps :D Tout comme iMac 20" d'il y a 3 ans :) Après, tu n'auras pas SnowLeopard .... mais en auras tu besoin ? :?
avatar YAZombie | 
En fait, je trouve qu'il manque une pièce maîtresse à votre article cher Arnaud, qui m'empêche de prendre toute la mesure de cette avancée indéniable: je crois comprendre que les cartes graphiques elles-mêmes doivent supporter lesdits langages (Cuda, OpenCL, DirectX 11, etc.) pour que les logiciels puissent tirer partie du GPGPU. Est-ce ainsi, ou OpenCL n'a-t-il besoin que d'être inscrit dans l'OS pour fonctionner sur n'importe quelle carte graphique supportée? Cela me surprendrait au vue du secret qui semble souvent entourer les specs des cartes graphiques (voir les difficultés que rencontrent les développeurs Linux avec certaines d'entre elles, notamment pour permettre à X11 de tirer partie de toutes leurs caractéristiques).
avatar Halx | 
Snow Leopard va être très intéressant. Après l'inflation des OS provoquée par une surenchère de fonctions et d'effets graphiques plus ou moins utiles, on peut s'attendre à une guerre de l'optimisation. Pour l'instant, avantage Apple qui a déjà beaucoup d'avance par rapport à Windows. Les développeurs ne peuvent plus se reposer exclusivement sur l'accroissement de puissance des CPU pour s'affranchir du travail d'optimisation de leurs applications. Apple prend un nouveau virage au bon moment. J'ai hâte de voir le résultat de ce travail d'optimisation que j'attendais depuis des siècles. Cela permettra à OSX de fonctionner très confortablement sur des machines portables aux caractéristiques modestes, c'est le but non avoué, mais cela aura aussi des effets sensibles sur les configurations plus puissantes.
avatar oomu | 
yazombie : opencl est une extension au langage C pour permettre de programmer des traitement sur la carte vidéo. au compilateur adéquat de se débrouiller.
avatar Pleinpopossum | 
Excellent article ! Il me donne envie de faire un bon dans le futur pour voir comment tout ceci va se passer. J'ai juste une appréhension sur la question "pourquoi programmer plusieurs fois la même chose pour chaque carte en utilisant chaque kit, quand on peut s'adresser à toutes avec une seule et même commande ?" Il me semble que c'est le cas avec OpenGL. OpenGL est supporté sous OSX, Windows et Linux. Si je ne m'abuse ATI et NVidia supportent les instructions OpenGL. Et malgré cela la majorité des jeux sont des jeux directX. Il suffirait que Microsoft sorte un outil propriétaire qui amène une facilité ou gain de productivité par rapport à OpenCL et une partie des devs et des décideurs pressés choisiront cette voie. S'ils peuvent gagner presque autant (windows reste archi dominant dans le monde) plus rapidement, quitte à se couper d'une partie de leur clientèle ils le feront... Pour Snow Leopard ça sent bon. Prendre un chemin différent au lieu de jouer les monsieur plus me semble emprunt de sagesse... en attendant les OS réellement orientés Web.
avatar pvmstg | 
Oui mais est-ce que le standard sera suivi ou pas.... il y a bien des standards pour le web mais, avec le poids de micro... il faut toujours faire des passes passes. Alors avec directx de micro et son poids... pour 80% du marché.... Comme même apple offre des kits pour autre chose que open cl.... voir l'annonce du kit pour cuda que vient de sortir apple. L'avenir nous le dira....
avatar Feroce | 
"il possède OS X -- et les optimisations et nouvelles technologies de Mac OS X Snow Leopard feront des Macs des machines qui tirent parti de la puissance mise à disposition par le matériel." Drôle de conception de l'optimisation. Il y a presque 20 ans, sur ST, Amiga etc... le développeur mettait les bouchées double pour que ses programmes / OS tournent à fond de balle sur du matériel plutôt basique (et quand Steinberg annonçait qu'il fallait passer de 512ko à 1Mo de Ram pour Cubase, en voyant le soft, on savait que c'était justifié). Aujourd'hui, exploiter à fond des machins monstrueux (comme les cartes graphiques actuelles) est un signe d'optimisation ? Tout ça pour que l'OS ne se traîne pas trop lamentablement... C'est beau la programmation de haut niveau :-/
avatar melaure | 
Et dans ma boite de dev, j'ai toujours les mêmes abrutis dans notre agence du sud qui affirment encore et encore qu'Apple est ce qu'il y a de plus propriétaire ... C'est pas gagné pour Apple.
avatar Scypher | 
@Halx " Cela permettra à OSX de fonctionner très confortablement sur des machines portables aux caractéristiques modestes, c'est le but non avoué, mais cela aura aussi des effets sensibles sur les configurations plus puissantes. " C'est un troll sa ? Où on à pas la même vision de: machine à faible puissance... Je crois pas qu'un Core 2 Duo 45nm avec 3mb de L2 Cache soit vraiment un processeur à faible puissance. Je considère plutôt sa comme un monstre de calcul. Si je prend exemple sur mon ancien iMac Core 2 Duo, il fonctionnait beaucoup mieux sous XP que sous OS X en terme de performances. Alors là si on vient parler de calcul assisté par la CG on est plus du tout dans le bas de gamme... Donc bon, OS X léger on en reparlera hein... Alors que je peine à utiliser 512mb de ma Ram sous Ubuntu Hardy Heron avec les effets 3d activés et une carte graphiques intégré, mon Imac sous OS X prend presque 512mb en idle. Par comparaison, mes versions optimisées de windows XP en prennent 180mb en idle souvent même....
avatar Tequilaforce | 
Il ya 20 ans, le mec était tout seul sur ça planète. De nos jours avec internet...
avatar biniou | 
Ca va être comme pour openML : hardware compatible ? Cuda ne fonctionne pas avec toutes les cartes NVIDIA. "Plus que jamais donc, le parallélisme sera le maître mot des logiciels de demain, et pour peu que Grand Central se charge également de dispatcher les calculs vers OpenCL, en traitant ainsi le GPU comme un simple processeur supplémentaire, Snow Leopard risque de donner un sacré coup d'accélérateur aux Macs d'aujourd'hui et de demain." L'architecture du GPU est bien différent de celui du processeur. Massivement parallèle, peut de mémoire pour les données par bloc, ... Si j'ai bien compris tout ce que m'a expliqué une collège sur Cuda. Grand central ne pourra donc pas utiliser le GPU comme CPU. La question que je me pose pour bien découper un problème en bloc pour utiliser l'aspect parallèle des GPU, il faut connaître le nombre de blocs pouvant être exécutés en même temps et éviter le sous-dimensionnement. Comment est-il alors possible de faire une implémentation d'OpenCL générique ?
avatar PowerGlove | 
Au lieu de faire des annonces pour faire rêvé les fans de la marque, apple ferais déjà mieux de me permettre d'exploité ma 8800 GT sur mon MacPro à la même vitesse qu'elle ne tourne sous windows. Parce que l'open GL sous mac OSX ... Ne parlons pas de Core Image parce que ça énerve encore plus. L'open CL c'est bien mais L'open GL c'est bien aussi et le Core Image et sa existe depuis 92 alors un petit effort... C'est sur que la carte graphique a plein de puissance qui sert a rien sur Mac, et c'est bien ca le problème... PS: Je precise que je fais de la 3D et de la video.
avatar Groumpff | 
et à part compter les Mo de RAM, tu fais quoi avec ton ordinateur ?
avatar YAZombie | 
Merci oomu. Du coup, j'ai une question incidente: les MacBook, c'est out, c'est ça? Ou les circuits graphiques d'Intel sont-ils aussi des monstres de puissance? (je ne sais plus de quoi douter :-D)
avatar lemail2mi | 
@YAZombie C'est un peut plus compliqué que ça, ce n'est pas seulement le compilateur qui est à l'oeuvre. Qquand on regarde le fonctionnement de llvm, le compilateur génère un code intermédiaire qui au moment du fonctionnement, est converti à la volé en code adapté au processeur ciblé. Donc pour le macbook ca fonctionnera quand même mais moins vite que sur un mac pro. Et en fonction de la carte vidéo utilisée, on peut avoir des optimisation spécifiques. Je m'avance peut être un peu mais ça me semble cohérent. Sinon je reprocherais à l'article des phrases du genre "...a-t-elle été à l'initiative d'OpenGL en 1992..." sans références. C'est le genre de phrases qui donne des arguments aux trolls et qui font passer MacG pour un site de fanatiques voués entièrement à leur secte.
avatar Pleinpopossum | 
@Feroce C'est vrai qu'il suffit de regarder les démos des époques amiga 500,600 des atari ST... Quand on voit ce que les devs faisaient en temps réel, sur deux disquettes avec un proc à 8 ou 16 MHz et très peu de RAM ! J'invite les pt'its jeunes à chercher Spaceball 9 fingers et State of the art. De même il y avait des concours de démo 64k ! Musique sur 4 ou 8 voix, graphismes, code le tout assemblé dans 64ko ! De même je me souviens de mon passage de Workbench à Win 95. Je ne comprenais pas niveau OS où était l'innovation par rapport à mon A600. Le workbench avait le concept de bureau, de dossier (tiroirs), le plug 'n play n'était pas qu'une illusion; pour installer un driver il fallait juste placer un fichier dans le tiroir ad hoc. Le double click, les menus contextuels, tout y était. Pourquoi l'OS de Microsoft demandait-il autant de ressource sur mon Pentium 120 !!?? Nostalgie, nostalgie ! A la décharge des devs actuels puisque j'en suis un... les contraintes ne sont plus les mêmes qu'à l'époque. L'informatique s'est professionalisée et sa propagation accélérée. Si on met sur la table temps de développement (donc coût) contre propreté et orthodoxie du code, ce dernier ne pèse plus lourd. Ca justifie l'utilisation de frameworks et autres API qui sont par définition plus génériques et moins optimisées. Bref on arrive plus vite à un résultat mais ça bouffe plus de ressources... Fin de parenthèse, on regarde à nouveau devant et espère que Snow Leopard sera à la hauteur des annonces !
avatar Hurrican | 
Avoir des routines système utilisant les capacités des co-processeurs ? L'Amiga, son OS, et ses multiples co-processeurs spécialisés, le faisait il y a plus de 15 ans déjà ! Bref, rien de neuf dans l'idée, on a juste des puces plus puissantes aujourd'hui.
avatar DrFatalis | 
"Plus que jamais donc, le parallélisme sera le maître mot des logiciels de demain," Certes, mais quid des capacités de l'esprit humain à programmer des taches en parallèle alors qu'il fonctionne, de façon consciente, en mode séquentiel ?
avatar Halx | 
Scypher > Par machines à faible puissance, je pense surtoût à des ultraportables, de nouveaux iPhones et a ses déclinaisons, des Tablet Macs qui semblent bien sur le point de voir le jour. Le résultat de cette optimisation ne sera bien sûr pas idéal, il y aura encore des bugs, mais au moins ce chantier va dans la bonne direction.
avatar spleen | 
Une belle annonce. Une belle pub (pour les trois pelés que ça intéresse). Les clients continueront à acheter du PC, et Apple à vendre de l'iphone. Et à part ça, quoi d'autre ?

Pages

CONNEXION UTILISATEUR