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.
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.
