La nouveauté, c'est que des chercheurs détournent l'utilisation première des GPU et utilisent leur puissance de calcul pour effectuer des calculs scientifiques.
Ainsi les opérations sur les matrices, domaine dans lequel les GPU graphiques excellent, sont considérablement accélérés. Alors qu'un processeur AMD Athlon 1800+ pointe en théorie à 1.5 GFlops, un processeur Quadro FX 2000 à 400 MHz fournira 12.8 GFlops. Le gain de temps est plus qu'appréciable.
Malheureusement, le toolkit nVidia n'est ni Open Source, ni libre. En revanche, la spécification du langage Cg est ouverte. Le tout est disponible sous GNU/Linux, Mac OS X et Windows. Le constructeur de processeurs graphiques ATI propose également un langage de programmation graphique équivalent, le RenderMonkey, mais qui n'est disponible que sur la plateforme de Redmond. Dommage...
À ma connaissance, aucune bibliothèque de mathématique (type GSL, Lapack, ..) ne propose d'utiliser la carte graphique pour externaliser certaines opérations. À cela plusieurs raisons : le fait que chaque fabricant crée son propre langage propriétaire, les problèmes de licence liés au modèle propriétaire autour de ces langages, et un gain de temps certes important, mais qui ne s'applique qu'au cas par cas à certaines opérations.
Aller plus loin
- Calcul scientifique avec GPGPU (36 clics)
- Homepage de GPGPU (9 clics)
- La news précédente sur Linuxfr.org à propos de Cg (12 clics)
- Le toolkit Cg (13 clics)
# Re: Cg et la programmation du GPU
Posté par Christophe Fergeau . Évalué à 2.
Un autre point qui me titille, c'est les communications entre carte graphique et processeur pour envoyer/récupérer les données, a priori via le bus agp actuel, c'est très lent (ça devrait s'améliorer avec le pci express), est-ce qu'on perd pas une grosse partie des gains obtenus lors du calcul à cause de ce transfert ?
[^] # Re: Cg et la programmation du GPU
Posté par Éric (site web personnel) . Évalué à 2.
[^] # Re: Cg et la programmation du GPU
Posté par Christophe Fergeau . Évalué à 1.
Si t'as des résultats super rapidement dans la mémoire de ta carte graphique mais que tu mets des siècles à les récupérer (pour les écrire dans un fichier par ex), c'est dommage.
[^] # Re: Cg et la programmation du GPU
Posté par xilun . Évalué à 2.
[^] # Re: Cg et la programmation du GPU
Posté par renoo . Évalué à 1.
# Re: Cg et la programmation du GPU
Posté par corn . Évalué à 3.
s/nVidia/NVIDIA/
s/AMD Athlon/AMD Athlon/
[^] # Re: Cg et la programmation du GPU
Posté par imr . Évalué à 0.
DTC ?
# Re: Cg et la programmation du GPU
Posté par MsK` . Évalué à 1.
# Re: Cg et la programmation du GPU
Posté par PloufPlouf (site web personnel) . Évalué à 3.
jsuis nul en math, mais j'imagine qu'on a pas besoin d'etre aussi precis dans le rendu d'une frame UT2004 que dans un calcule scientifique...
hein ?
[^] # Re: Cg et la programmation du GPU
Posté par reno . Évalué à 3.
- la precision des calculs flottants qui n'est que de 32bits au mieux sur les cartes NVidia (24 bits sur les Radeon actuels).
Il y a des rumeurs comme quoi les Radeon devraient passer bientot en mode 32bits, mais cela reste des calculs en simple précision alors que les calculs scientifiques se font généralement en mode double précision (au moins).
Les jeux vidéos n'utiliseront probablement pas le mode 32bits au départ, alors avoir des calculs flottant en 64 bits sur les GPU, cela n'est pas pres d'arriver..
- la recuperation des donnees: le bus AGP est asymetrique, tres rapide du CPU vers la carte video mais lent dans l'autre sens.
Ca peut etre tres genant pour les calculs scientifique, mais ce probleme devrait bientot disparaitre avec PCI Express..
Il reste le probleme de precision des calculs flottant, tu as raison..
# Des flops par seconde ?
Posté par Salagnac . Évalué à 7.
http://en.wikipedia.org/wiki/FLOPS(...)
plop !
[^] # Re: Des flops par seconde ?
Posté par Ummon . Évalué à 5.
[^] # Re: Des flops par seconde ?
Posté par tgl . Évalué à 2.
(et je rigole qu'à moitié, cf les posts au dessus.)
[^] # Re: Des flops par seconde ?
Posté par Obsidian . Évalué à 1.
« PLonk OPeration per second ? »
# Re: Cg et la programmation du GPU
Posté par tuan kuranes (site web personnel) . Évalué à 8.
Dans le cas d'utilisation "hors-3d" des capacités du GPU, il faudrait de toute facon créer un language adapté, avec des routines asm spécifiques.
Dans le monde du libre voici le "métalanguage" libre pour les GPU
http://sourceforge.net/projects/libsh/(...)
Sinon, Ogre3d offre un "wrapper" libre qui permets d'utiliser les capacités des GPU sous linux tres facilement ( http://www.ogre3d.org/(...) (qq demos sont incluses))
Quelques démos impressionnantes précompilées avec sources :
http://esprit.campus.luth.se/~humus/3D/index.php(...)
(attention, nécessite drivers proprio et carte 3d solide (min ATI 9600 et Geforce FX))
La spécification opengl 2.0 devrait proposer un language unifié pour les GPU (1.0, 2.0 et 3.0). (oriente image et 3d), mais c'est pas pour aujourd'hui.
Ca me rappelle l'utilisation des DSP programmables des cartes son dans un projet de calcul numérique ou de crypto... mais je ne me souviens plus le nom ni le pourquoi....
[^] # Re: Cg et la programmation du GPU
Posté par Franck Guillaud . Évalué à 1.
Après qu'on s'en serve pour de la 3D ou du calcul scientifique, peu importe. C'est juste que c'est naturel de faire de la 3d sur une carte 3D :-)
[^] # Re: Cg et la programmation du GPU
Posté par tuan kuranes (site web personnel) . Évalué à 1.
Cela dit bcp de maths peuvent être fait en 4x4. dans les démos de libsh, y'a une simlation de particules subissant la gravité utilisant les GPU...
# Re: Cg et la programmation du GPU
Posté par __caffeine__ . Évalué à 6.
Le problème est que pour l'instant on ne dispose d'aucun compilateur libre pour faire ces choses, et sans les specs des puces on ira pas bien loin. C'est dommage parce que le libre propose maintenant des moteurs de jeu 3D qui tiennent bien la route (ogre, crystal space...), suffisament AMHA pour concurrencer des moteurs proprios aux licences horriblement chères, mais si au moment de la sortie d'OpenGL 2.0 on a pas rajouté un backend à gcc pour les shaders languages, on va se retrouver le bec dans l'eau et obligé de se rabattre sur des solutions propriétaires. Ca me gênera pas pour mon projet de clône de nethack en python, mais ça risque d'être dommageable pour la pénétration du libre dans le jeu vidéo...
[^] # Re: Cg et la programmation du GPU
Posté par tuan kuranes (site web personnel) . Évalué à 5.
D'ailleurs, c'est souvent en asm qu'ont ecrits les shaders pour des raisons, y'a pas des masses d'instructions (enfin en shader V1 ). Et on l'upload dans le GPU (arb_fragment_program())
je te remets le lien du dessus, avec le lien vers le schema :
http://libsh.sourceforge.net/about.html(...)
( Dans ce cas on ecrit du c++
qui est compile en asm,
qui est ensuite passe aux GPUs.)
pour eclarcir le cg et le rendermonkey et le sh sont des languages de haut-niveau pour ne pas a avoir a se taper l'assembleur des differents GPU.
[^] # Re: Cg et la programmation du GPU : Un exemple
Posté par tuan kuranes (site web personnel) . Évalué à 3.
# la version du shader
!!ARBfp1.0
PARAM param = { 2.0, -1.0, 0.0, 0.0 };
PARAM offset = program.env[0];
TEMP src, coord0, coord1, old, new, temp;
# texture source
TEX src, fragment.texcoord[0], texture[0], 2D;
# calcule le decalage
ADD coord0, fragment.texcoord[0], offset;
MUL coord0, coord0, 10;
TEX coord0, coord0, texture[2], 2D;
MAD coord0, coord0, param.x, param.y;
TEX coord1, fragment.texcoord[0], texture[1], 2D;
MAD coord1, coord1, param.x, param.y;
MAD coord0, coord0, 0.02, fragment.texcoord[0];
MAD coord1, coord1, 0.02, coord0;
# points voisins
TEX new, coord1, texture[3], 2D;
# point courant
TEX old, fragment.texcoord[0], texture[3], 2D;
# Blur !!!
MAD old, new, 1, old;
MUL new, old, 0.492;
# replace la source
SGE temp, src, 0.3;
MUL src, src, temp;
SUB temp, 1, temp;
MUL new, new, temp;
ADD result.color, new, src;
END
# Re: Cg et la programmation du GPU
Posté par jerome bagattin . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.