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.

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

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

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

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

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.

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

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 ?

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.

 
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 ?).

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.

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).

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