Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1776 connectés 

  FORUM HardWare.fr
  Programmation
  C++

  Un bon bouquin pour faire du GPGPU

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Un bon bouquin pour faire du GPGPU

n°1467735
Gremm
Posté le 30-10-2006 à 18:12:12  profilanswer
 

Bonjour,
 
Je cherche un bon livre d'introduction au GPGPU (General Purpose computing on GPU), il sagit d'utiliser la puissance des GPU pour faire du calcul pas forcement en lien avec la 3D.
 
Ya til des connaisseurs de ce domaine ici ?
Si oui, j'aimerais aussi savoir si vous pensez qu'il est plus interressant d'utiliser une surcouche logicielle comme Brook plutôt que d'attaquer directement le GPU sachant que je ne connais pas grand chose à OpenGL et aux shaders.
 
Merci pour votre aide.

mood
Publicité
Posté le 30-10-2006 à 18:12:12  profilanswer
 

n°1467791
IrmatDen
Posté le 30-10-2006 à 19:48:35  profilanswer
 

Salut,
 
Je n'ai pas encore touché au GPGPU, mais il y a des chapitres qui lui sont consacrés dans les GPU Gems 1 & 2 (le 1er, juste 1 chapitre sur les sort, le 2ème lui réservant toute une section).
S'il n'y a pas d'autre bouquin, n'hésite pas à te le procurer le 2ème. Sinon, mais j'imagine que tu connais aussi, il y a le site gpgpu.org
 
J'espère avoir pu donner une petite partie de réponse :)

n°1467811
Gremm
Posté le 30-10-2006 à 20:44:38  profilanswer
 

Merci pour ton aide, Je connaissais pas GPU Gems c'est déjà un début ;-)
 

n°1467819
IrmatDen
Posté le 30-10-2006 à 21:19:48  profilanswer
 

Voilà les sujets abordés dans le 2nd volume:

Citation :

GENERAL PURPOSE COMPUTATION ON GPUS: A PRIMER
 
Streaming Architectures and Technology Trends
John Owens (University of California, Davis)
 
The GeForce 6 Series GPU Architecture
Emmett Kilgariff and Randima Fernando (NVIDIA Corporation)
 
Mapping Computational Concepts to GPUs
Mark Harris (NVIDIA Corporation)
 
GPU Computation Strategies and Tips
Ian Buck (Stanford University)
 
Implementing Efficient Parallel Data Structures on GPUs
Aaron Lefohn (University of California, Davis), Joe Kniss (University of Utah), John Owens (University of California, Davis)
 
GPU Flow Control Idioms
Mark Harris (NVIDIA Corporation) and Ian Buck (Stanford University)
 
GPU Program Optimization
Cliff Woolley (University of Virginia)
 
Stream Reduction Operations for GPGPU Applications
Daniel Horn (Stanford University)


Les 2ers chapitres de cette section sont dispo en téléchargement, si tu veux y jeter un oeil ;)

n°1467892
tbp
Posté le 31-10-2006 à 00:56:25  profilanswer
 

Celà n'engage que moi même, mais tout ce raffut autour du 'concept' de GPGPU ressemble à une tempête dans un verre d'eau.
 
La dernière fois que j'ai taté le terrain, http://ompf.org/forum/viewtopic.php?t=106 , même si n'était que pour du vulgaire post-proc j'ai encore une fois constaté combien c'était la misère de convaincre ces foutues GPU de faire un calcul à moitié correct. Aucune garantie sur la précision des operations, exit IEEE 754 j'en passe et des meilleurs (entiers?).  
Et encore, c'est quand on a la chance d'avoir la combinaison carte/driver qui va bien et que la lune est dans la bonne phase.
 
Même si à la base c'est d'une simplicité biblique celà dérape systematiquement vers une accumulation d'affreuses bidouilles.
Mais je suppose qu'il faut bien renouveler de temps en temps les arguments de ventes.

n°1467900
bjone
Insert booze to continue
Posté le 31-10-2006 à 02:08:47  profilanswer
 

je pense qu'il va falloir attendre quelque générations de cartes pour avoir une bonne homogénéité calculatoire.
 
D3D 10 semble mettre un peu plus de spec au clair, peut-être qu'avec la GF8 et le R600 commençera une ère un peu moins approximative :??:

n°1467901
LeGreg
Posté le 31-10-2006 à 03:25:48  profilanswer
 

Pour GPGPU il faut savoir dans quoi on se lance.. Et oui ce n'est pas aussi facile que de compiler une app sur un CPU pour plusieurs raisons :
facilité de débogage très réduit, passage par une interface non prévue pour ce genre de calculs et qui nécessite quelques connaissances en dehors du domaine approché (connaissance ogl et/ou d3d), performances très difficile à apprécier à l'avance à cause de nombreuses non orthogonalités du hardware, parfois pour obtenir de bonnes perfs il ne faut pas hésiter à utiliser les features du GPU (filtrage et interpolation "gratuits", early z, queries). Et surtout c'est un domaine extremement mouvant en ce moment donc les connaissances accumulées a l'an N, ne seront plus forcément vraies à l'an N+1.
 
Microsoft propose une interface de programmation qui abstrait le hardware et les API et qui fonctionne à partir de C#
http://research.microsoft.com/rese [...] rt&id=1040
 
Ils disent qu'ils obtiennent de très bons résultats de perfs par rapport au code hand tuned (>> c++) et surtout c'est plus facilement déboguable grace à la surcouche d'abstraction (sauf si bug dans la surcouche en question, le driver ou le runtime bien entendu..). Par contre ils n'utilisent pas du tout les capacités du hardware en dehors de la puissance des pixel shaders et là c'est moins cool, mais bon c'est un compromis comme toujours.
 
Sinon TBP, joli raytracer et depth of field (enfin ça fait un peu strange tout de meme avec le glow..), qu'est-ce qu'il fait sur le GPU exactement ? quel genre de FPS tu obtiens typiquement ?

Message cité 1 fois
Message édité par LeGreg le 31-10-2006 à 04:10:28

---------------
voxel terrain render engine | animation mentor
n°1468083
tbp
Posté le 31-10-2006 à 11:43:20  profilanswer
 

LeGreg a écrit :

Sinon TBP, joli raytracer et depth of field (enfin ça fait un peu strange tout de meme avec le glow..), qu'est-ce qu'il fait sur le GPU exactement ? quel genre de FPS tu obtiens typiquement ?


Une variante de mon sphereflake-tracer-en-100-lignes pond, ~7s pour generer & tracer 5.38M de spheres, une texture en flottants (rgb/depth); high pass+bloom; pseudo DOF (ou plutot un floutage sélectif); tonemapping.  
 
Mais ce machin n'était qu'un proto, et une monstrueuse supercherie, pour voir ce que je pouvais tirer d'une carte semi-récente en matière de post-proc, le but étant in fine de bouturer le tout sur un vrai rtrt, comme radius . C'est une re-écriture, le code publié est à la ramasse, blah blah, mais en gros on obtient une poignée de millions de rayons primaires shadés par coeur/cpu par seconde sur des scènes non triviales. Ou les 150+ fps @ 1024x1024xfp32 en pointant la caméra dans le vide; d'ou un certain traffic sur le bus... vive le PCI-e et les PBO.
 
Les shaders ont été émasculés en conséquence pour ne pas devenir le goulet d'étranglement, mais décidement ma gf7800 peine à la tache, même si dans mon cas il n'y a qu'un flux ascendant. Et c'est effectivement une tannée d'écrire ce genre de truc.
 
edit: J'ai oublié de préciser que tout se fait en flottant de A à Z, partant du principe que si mes cpu se décarcassent à produire ces flottants je ne vois pas pourquoi ma gpu se la coulerait douce.

Message cité 1 fois
Message édité par tbp le 31-10-2006 à 12:14:29
n°1468544
LeGreg
Posté le 01-11-2006 à 02:16:24  profilanswer
 

tbp a écrit :

Mais ce machin n'était qu'un proto, et une monstrueuse supercherie, pour voir ce que je pouvais tirer d'une carte semi-récente en matière de post-proc, le but étant in fine de bouturer le tout sur un vrai rtrt, comme radius . C'est une re-écriture, le code publié est à la ramasse, blah blah, mais en gros on obtient une poignée de millions de rayons primaires shadés par coeur/cpu par seconde sur des scènes non triviales. Ou les 150+ fps @ 1024x1024xfp32 en pointant la caméra dans le vide; d'ou un certain traffic sur le bus... vive le PCI-e et les PBO.


 
j'obtiens 460+ fps avec l'executable donné en lien, c'est 800x600 avec le flocon au centre de la fenetre (je ne pense pas qu'on puisse bouger la vue ?).


---------------
voxel terrain render engine | animation mentor
n°1468548
tbp
Posté le 01-11-2006 à 04:10:47  profilanswer
 

Je plafonne à ~100 fps @ 800x600 sur ma gf7800gt et ses drivers instrumentés, ce qui était à peu près le résultat escompté.
Visiblement votre carte est nettement plus à l'aise avec les flottants, et vu l'écart assez monstrueux il va falloir que je pense à un système à charge variable rapido.
 
Non on ne peut pas changer la vue, seulement les parametres du post-proc (focale etc). Même si on pourrait envisager qques sacrifices sur la qualité du rendu, par exemple en virant le FSAA en RGSS 2x2, ce traceur n'a aucune chance d'accéder au temps-réel; je ne suis pas un fan des slide-shows.
 
Tout de même, 4x plus de puissance de traitement permet d'envisager de nouvelle passes. Hmm.

mood
Publicité
Posté le 01-11-2006 à 04:10:47  profilanswer
 

n°1473197
LeGreg
Posté le 09-11-2006 à 20:00:59  profilanswer
 

On en parlait sur le topic hardware mais il y aussi ça pour les gens motivés :) :
http://developer.nvidia.com/object/cuda.html
(programmer le GPU avec une interface C-like sans avoir à se soucier des APIs).


Message édité par LeGreg le 09-11-2006 à 20:02:04

---------------
voxel terrain render engine | animation mentor
n°1559346
_darkalt3_
Proctopathe
Posté le 12-05-2007 à 11:44:39  profilanswer
 

[:drapal]


---------------
Töp of the plöp
n°1989474
e-v-tooms
Posté le 02-05-2010 à 17:03:58  profilanswer
 

4 ans plus tard, il y a de bons livres qui sont sortis ?


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C++

  Un bon bouquin pour faire du GPGPU

 

Sujets relatifs
que bouquin sur Java ? je m'y perdRecherche bon bouquin "papier"
Un bon bouquin PHP OBJETQuel bouquin pour apprendre le C#/.NET 2.0 venant du C++
Cherche bon bouquin sur l'embarqué[PHP] Quel bouquin pour bien debuter
quel bouquin pour un debutant en C#Bouquin sur PHP/MySQL
Bouquin Langage C (révisions concours)Bouquin PHP 5 à offrir ?
Plus de sujets relatifs à : Un bon bouquin pour faire du GPGPU


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR