Cg et la programmation du GPU

Posté par Bruno le 19 mars 2004 à 13:47. Modéré par Nÿco.

Étiquettes :

mar.

2004

La version 1.2 du kit de développement en Cg (C Graphique) proposé par nVidia a été mis en ligne en février 2004. Le langage Cg se présente comme un langage de haut niveau type OpenGL, ajoutant une couche d'abstraction entre l'utilisateur et le code machine de la puce graphique. Il permet de programmer directement des shaders dans le GPU (Graphics Processing Unit).

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 (12 clics)

# Re: Cg et la programmation du GPU

Posté par Christophe Fergeau le 19 mars 2004 à 14:02. Évalué à 2.

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 (site web personnel) le 19 mars 2004 à 15:06. É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 mars 2004 à 15:31. É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 mars 2004 à 17:27. É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
  
  Posté par renoo le 19 mars 2004 à 15:27. Évalué à 1.
  
  Pas genant les cartes graphiques embarquant pas mal de mémoire (souvent 128 ou 256mo) et cette mémoire est tres rapide (bus 256bits, DDR, 400mhz) des caracteristiques à faire palir la mémoire centrale de vos pc.
# Re: Cg et la programmation du GPU

Posté par corn le 19 mars 2004 à 14:03. Évalué à 3.

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
  
  Posté par imr le 20 mars 2004 à 05:36. Évalué à 0.
  
  Puisqu'on veut jouer avec les TM et autres, autant les mettre là où il faut :
  DTC ?
# Re: Cg et la programmation du GPU

Posté par MsK` le 19 mars 2004 à 14:03. Évalué à 1.

Y'a pas de toolkit Cg libre ? ( ie fait par la communauté opensource, un peu comme avec java. C'EST PAS UN TROLL :p )
# Re: Cg et la programmation du GPU

Posté par PloufPlouf (site web personnel) le 19 mars 2004 à 14:06. Évalué à 3.

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 mars 2004 à 16:40. É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 ?

Posté par Salagnac le 19 mars 2004 à 14:09. Évalué à 7.

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 mars 2004 à 14:27. É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 ?
    
    Posté par tgl le 19 mars 2004 à 18:16. Évalué à 2.
    
    Ah non, pas de puissance, il faudrait pour ça multiplier par le nombre de bits des flottants traités. :)
    (et je rigole qu'à moitié, cf les posts au dessus.)
- [^] # Re: Des flops par seconde ?
  
  Posté par Obsidian le 19 mars 2004 à 20:59. Évalué à 1.
  
  Et un plop alors, c'est quoi ?
  
  « PLonk OPeration per second ? »
# Re: Cg et la programmation du GPU

Posté par tuan kuranes (site web personnel) le 19 mars 2004 à 14:37. Évalué à 8.

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 mars 2004 à 15:58. É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 (site web personnel) le 19 mars 2004 à 16:10. É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

Posté par __caffeine__ le 19 mars 2004 à 15:02. Évalué à 6.

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 (site web personnel) le 19 mars 2004 à 15:53. É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 (site web personnel) le 19 mars 2004 à 15:58. É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

Posté par jerome bagattin le 20 mars 2004 à 03:25. Évalué à 1.

Ca peu etre interessant sur un cluster de Xbox :-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.