Articles précédents : Développeur
- [9] La communauté Cobalt open source s'organise
- [59] Comparatif des systèmes de contrôle de version
- [188] En quoi la mise en page par tableaux est-elle stupide
- [15] Les documentations de l'OpenGroup bientôt dans votre pingouin
- [78] GTK-Qt-OpenOffice.org: un pas de plus vers une meilleure intégration
- [22] UML2PHP5 version 0.3
- [2] Résumé GNOME 13-12-2003
- [11] "Débats virtuels" autour des *BSD
- [13] Les coulisses du développement de Python
- [20] Résumé GNOME 06-112-2003
Liens connexes
- Calcul scientifique avec GPGPU (1052 hits)
- Homepage de GPGPU (536 hits)
- La news précédente sur Linuxfr.org à propos de Cg (591 hits)
- Le toolkit Cg (560 hits)
Dépêche modérée par
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.
![[en]](../../../images/en.png)
Calcul scientifique avec GPGPU (1052 hits)-
Homepage de GPGPU (536 hits)
![[fr]](../../../images/fr.png)
La news précédente sur Linuxfr.org à propos de Cg (591 hits)-
Le toolkit Cg (560 hits)
> Lire la dépêche (21 commentaires, moyenne: 2,8).
À 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.
Re: Cg et la programmation du GPU
Le problème avec ces chiffres de GFlop, c'est que les cartes graphiques fonctionnent essentiellement en mode simd, ie pour atteindre les 12GFlops il faut appliquer la même opération sur plusieurs entiers en même temps, beaucoup d'algos ne se prêtent pas à ce traitement.
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 (Jabber id, page perso, ) le 19/03/2004 à 14:06. (lien). Évalué à 2."très lent" ... AGP 8x ça veut tout de même dire 2.13 Go /s .... ça laisse tout de même de quoi faire trainer quelques données.
-
[^]Re: Cg et la programmation du GPU
Posté par Christophe Fergeau () le 19/03/2004 à 14:31. (lien). Évalué à 1.Je faisais allusion à http://slashdot.org/article.pl?sid=02/08/19/1310216&mode=thread(...)
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 () le 19/03/2004 à 16:27. (lien). Évalué à 2.Le truc c'est que auparavant l'AGP servait a foutre les texture en RAM principale (entre autre) et a les echanger, a faire mumuse avec, donc a cette epoque le debit etait correct. J'ai des souvenir de jeux magnifique (textures détaillées et tout, mais résolution basse 800*600 vu la vitesse du chip) sur une ATI RAGE PRO 8 mo. Aujourd'hui, les nouvelles CG ont 128 mo embarqué, voire 256 ? et donc l'AGP n'a absolument plus aucune utilitée, et donc les fabriquant developpent cette aspect de la carte avec leur pieds.
-
-
-
[^]Re: Cg et la programmation du GPU
Re: Cg et la programmation du GPU
Puisqu'on veut jouer avec les TM et autres, autant les mettre là où il faut (en s'inspirant de nvidia.com et amd.com) :
s/nVidia/NVIDIA/
s/AMD Athlon/AMD Athlon/
-
[^]Re: Cg et la programmation du GPU
Re: Cg et la programmation du GPU
est ce que cela ne pose pas des problemes de precisison ?
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 () le 19/03/2004 à 15:40. (lien). Évalué à 3.Il y a deux problemes:
- 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 ?
un "flops" c'est deja une unite "par seconde" : floating-point operations per second
http://en.wikipedia.org/wiki/FLOPS(...)
plop !
-
[^]Re: Des flops par seconde ?
Posté par Ummon () le 19/03/2004 à 13:27. (lien). Évalué à 5.En fait des flops/s est une unité d'accéleration de puissance.. c'est marrant mais peut-être pas très utile ^_^''
-
[^]Re: Des flops par seconde ?
-
-
[^]Re: Des flops par seconde ?
Re: Cg et la programmation du GPU
A la base, programmer les GPU se fait en assembleur dedié... CG et rendermonkey offrent des fonctions surtout orientées vers la 3d et le traitement d'image. (Vertex et Pixels)
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 () le 19/03/2004 à 14:58. (lien). Évalué à 1.Les langages assembleurs des GPU offrent avant tout des opérations sur les vecteurs et matrices.
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 (page perso, ) le 19/03/2004 à 15:10. (lien). Évalué à 1.En 3d, on utilise un sous-ensemble des operations possibles sur les matrices. Le plus genant etant la taille des matrices, au-dela de 4x4, pas d'espoir dans les langages de haut-niveau cites. Par contre, ca doit etre possible de se debrouiller en asm (mais ca doit etre tout de meme assez complexe) et de fournir au final un langage qui permettent autre chose...
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
Là, on a un truc qui risque de poser problème dans quelques années. Je m'explique: la création de jeux vidéos et d'applis graphiques commence à reposer de plus en plus sur l'utilisation de "shader programs", écrits par exemple en Cg pour les cartes nvidia (ou directement en assembleur) et compilés avec les outils dédiés pour que ça aille vite (et pas appelés par des fonctions genre glVertexProgramARB).
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 (page perso, ) le 19/03/2004 à 14:53. (lien). Évalué à 5.on a les specifications de l'assembleur des differents GPU.
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 (page perso, ) le 19/03/2004 à 14:58. (lien). Évalué à 3.Par exemple, un shader pour blurrer une texture (ati 9600 ou geforce fx) a charger avec (GL_FRAGMENT_PROGRAM_ARB) :
# 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
Ca peu etre interessant sur un cluster de Xbox :-)
Cette page a été générée par Templeet en 0.0973s (dont 0.0183 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.