[actu] Le GPU devient copro

[falou]

Que faire du GPU dans une station de travail quand on en fait pas de 3D ? Apple a déjà présenté sa solution logicièle Quartz Extreme, Core Video et Core Image. Windows Vista avec Avalon et Aero emboîtera le pas. Il s'agit en effet d'accélérer l'affichage et de permettre l'application d'effets temps réel sur des images fixes ou de la vidéo, et d'afficher le bureau tel une texture 3D.

ATI pousse le concept avec sa puissante série X1900 et le pilote Catalyst 6.5. il s'agit ici d'utiliser le GPU de la carte pour exécuter toutes sortes de calculs. On peut imaginer que la carte puisse être utilisée en fonctions graphiques pour la partie modelage, puis en renfort du (des) CPU pour les calculs de rendu dans Cinema 4D par exemple. De quoi rentabiliser ces circuits toujours plus puissants, coûteux et sous-exploités.

Reste des inconnues : le principe va-t-il s'étendre à d'autres séries (ou marque) de GPU ? Et les Mac auront-ils accès à cette technologie ?

Source

[beankylla]

ben ouiich.. mais cha on le sait depuis que world community grid a dit qu'ils se serviraient du gpu pour faire les calculs et que tout serai plus puissant et plus beau et tout et tout

mais bon

c'est pas encore au point ... en tout cas ca va encore simplifier la comparaison de la puissance des ordis ca

[falou]

ben ouiich.. mais cha on le sait depuis que world community grid a dit qu'ils se serviraient du gpu pour faire les calculs et que tout serai plus puissant et plus beau et tout et tout

mais bon

c'est pas encore au point ... en tout cas ca va encore simplifier la comparaison de la puissance des ordis ca

un projet de grid computing veut utiliser le GPU ça c'est bien, mais ATI fournit la solution. C'est ça qui est intéressant. Et si Catalyst intègre déjà la possibilité d'utiliser les unités shaders, c'est que c'est au point. Ce sont les applications qui l'utiliseront qui ne le sont pas encore. Y'a celui qui veut aller sur la lune, et y'a celui qui construit la fusée

[PoSKaY]

Aparement la version de folding@home qu'ils ont sortit pour les X1950 (c'est peut-être pas celle là mais c'est pas loin ) est archi bugguée et ne marche pas en fin de compte : cartonjaune:

Sinon le principe est pas mal du tout !

[weepdoo]

Pour info, il me semble bien que Nvidia propose aussi une solution équivalente.

Le problème quand on fait du GridComputing, c'est que les machines sont hétérogènes et ont des disponibilités incertaines (ex: on ne connait pas la quantité de ram, ni la vitesse du proc et on ne sait pas ce que fais l'utilisateur..) bref c'est déjà un vrai bordel à gérer.

Pour les projets comme folding / seti et autres, l'avantage c'est qu'on peut sectionner les problèmes en petits calculs indépendants (pas de communications inter process) moralité c'est assez "simple" comme grid computing.

Utiliser les Carte Graphique c'est une bonne idée, car en effet, la plupart des calculs scientifiques sont des opérations matriciels, et comme le hasard fait bien les choses, c'est ce pour quoi les cartes graphiques sont spécialisées et avec les chaders ont peut vraiment faire des opérations très complexe et de façon efficace.

Toutefois, il n'est vraiment pas simple (via l'OS) de connaitre l'occupation de la carte graphique (libre ou pas ??) et donc d'occuper ou de libérer les ressources suivant l'occupation.

De plus chaque carte graphique est vraiment particulière et est pas complètement compatible avec celles des concurents (ATI != Nvidia). Donc il faudrait programmer pour un constructeur puis pour l'autre. Sachant que suivant le modèle et la génération on aura accès ou non à certaines fonction ou pas... bref un beau bordel !

Moralité, que ce soit faisable, et que ça marche c'est une chose, que les constructeurs aident et/ou facilitent tout ça, en offrant une interface c'est une chose, mais de là à ce que ce soit massivement utilisé... j'ai quand même de bon doutes (du moins à court et à moyen terme).

Wait & See

[falou]

Mais ui Weepdoo, mais ces problèmes existent déjà depuis longtemps. Entre AMD, les PPC, les intel, les optimisaitons se sont toujours fait attendre. Et on connaît bien l'avantage que procurent les unités SIMD comme l'altivec ou le SSE sur les calculs matriciels (ces unités sont en effet capables de faire les étapes d'un calcul complexe en une seule passe plutôt qu'exécuter les instructions les unes après les autres). Les G5 avaient de loin la meilleur unité de calcul vectoriel mais étant inutilisé, nos PPC se trouvaient à la bourre dans leurs benches.

Alors ce "réveil" des consciences sur l'inutilisation du GPU ça me fait doucement rigoler, puisque même nos CPU ne sont pas exploités de manière nominale (les benches de la Nasa ont démontré un x3,5 sur la vitesse de calculs des G4 avec l'utilisation de l'Altivec par rapport à une utilisation basique du processeur sur les calculs scientifiques, alors avec les G5, j'en parle pas).

[weepdoo]

C'est vrai, mais il ne faut pas oublier que les programmeurs de manière général ne se préocupent pas de ce qu'ils ont en dessous de l'API qu'on leur fourni.

Donc plutôt que d'écrire la fonction qui va bien en assembleur, ben en général ils recodent étape par étape.

Or, cette dernière solution le compilo ne peut pas l'identifier (c'est pas magique non plus un compilo) et encore moins l'optimiser... moralité ça ram.

Bref, les instructions vectorielles c'est TRES bien (utilisé sur les Cray depuis le début entre autre), mais cela demande une certaine rigeur de programation ainsi qu'une connaissance du matériel que la pluspart des dev n'ont pas (car ils n'ont en général pas le temps !)

[falou]

C'est vrai, mais il ne faut pas oublier que les programmeurs de manière général ne se préocupent pas de ce qu'ils ont en dessous de l'API qu'on leur fourni.

Donc plutôt que d'écrire la fonction qui va bien en assembleur, ben en général ils recodent étape par étape.

Or, cette dernière solution le compilo ne peut pas l'identifier (c'est pas magique non plus un compilo) et encore moins l'optimiser... moralité ça ram.

Bref, les instructions vectorielles c'est TRES bien (utilisé sur les Cray depuis le début entre autre), mais cela demande une certaine rigeur de programation ainsi qu'une connaissance du matériel que la pluspart des dev n'ont pas (car ils n'ont en général pas le temps !)

Depuis xcode2 les optimisations pour altivec sont automatiques (comme sur Cray) à la compil. C'est peut-être pas super optimisé, mais ça ne peut être que mieux. Le problemo, c'est que les développeurs ils prennent le truc en C, le compilent avec un vieux GCC et le truc il marche c'est sûr... mais bon... comme un truc pensé en CISC sur un RISC quoi (en ce qui concerne les G5).