Archi GPU et GPGPU

**newbie06** · 25/07/2008, 11h40

Apres avoir lu un post sur le forum Hardware, je poste la "news" originale :

lien

NVIDIA to announce something big in September
Written by Andreas G 24 July 2008 22:31

NVIDIA has something big coming, according to its own estimates something about the same size as SLI when it launched. It's not the introduction of the rumored Radeon HD 4870X2 killer, the 55nm G200b core. That would be a bit too weak. There is a new PhysX driver that will enable PhysX on all CUDA-capable GPUs that will launch soon, but it should arrive sooner than that. Instead, the bang comes from updated CUDA support and improved drivers.

SLI will be updated, connectivity will be updated, CUDA looks like it will go commercial, and better quality and performance overall. The last part may also include improved scaling in various SLI configurations. Whether it will have the same impact as SLI had remains to be seen. More news should follow as we approach the next Big Bang.

J'ai beaucoup de mal a croire que CUDA pourrait devenir payant, ca freinerait beaucoup son adoption et par consequent la lutte contre Larrabee.

**Yasko** · 25/07/2008, 14h40

Trouvé dans les commentaires de la news Matbe sur le driver PhysX4All.
Le triangle ou la droite (RT), c'est has been, vive le cube (voxel) - (apparemment, ca fait un moment que ca existe, mais je découvre, alors...)

Envoyé par tfpsly

Merci Carmack, et merci Cuda et Larrabee :
http://www.pcper.com/article.php?aid=532
http://ompf.org/forum/viewtopic.php?f=6&t=793 (avec exemple de rendu)
http://forum.hardware.fr/hfr/Hardwa...m#t6508706
http://ompf.org/forum/viewtopic.php?f=3&p=8319
http://lefebvre.sylvain.free.fr/oct...he_gpu.pdf

**Møgluglu** · 25/07/2008, 14h53

Envoyé par newbie06

Apres avoir lu un post sur le forum Hardware, je poste la "news" originale :

Chez NVidia ils sont très très forts en marketing. Plutôt que de se fatiguer à annoncer un vaporware à coup de Powerpoint, ils font la même chose mais sans le Powerpoint et sans dire ce que c'est. En plus comme ça on ne pourra même pas leur reprocher de ne pas avoir tenu leurs promesses.

Le modèle économique de Cuda, c'est un toolkit gratuit qui tourne sur tous les GPU pour accélérer son adoption, et des blades Tesla pour supercomputer pour les "vrais" clients. En ça Tesla est commercial, Cuda non.

En plus je trouve que le Cuda actuel est déjà en avance par rapport au GT200. Par exemple ils ont introduit les shared memory atomics et surtout les instructions de réduction dans Cuda 2.0 avec un support matériel minimal et trop lent pour que ce soit réellement utilisable.

Pour moi c'est juste du buzz à la NVidia. Une rumeur partie d'une news sans source pas confirmée officiellement, juste au moment où les GPU AMD sont devant, étrange...

**newbie06** · 25/07/2008, 15h09

En parlant de ca, hors probleme CTM vs CUDA, on sait si les derniers GPU AMD sont meilleurs que ceux de nVidia pour du GPGPU ?

**Møgluglu** · 25/07/2008, 21h11

Sur le papier :
Radeon HD 4870 :
- 115 Go/s
- 240 GFlops double (scalaire)
- 1,2 TFlops simple (VLIW)
- max 4 Go/GPU voire plus (FireStream)

GTX 280 :
- 140 Go/s
- 78 GFlops double (scalaire)
- 622~900 GFlops simple (scalaire)
- max 4 Go/GPU (Tesla)

Mais ça ne veut pas dire grand-chose. Notamment les perfs en scatter et en gather on ne les connaît pas trop. Le GT200 a quelques features en plus comme les scatters atomiques et probablement une arithmétique plus mieux (dénormaux et modes d'arrondi).
Les R600-770 ont par contre leurs registres adressables avec indirection (killer feature inutilisable en CAL).

Pour les perfs en pratique, on peut chercher les stats de Folding@Home par exemple (pas trouvé pour les GPU récents).

**Alice** · 27/07/2008, 15h02

Envoyé par Yasko

Le triangle ou la droite (RT), c'est has been, vive le cube (voxel) - (apparemment, ca fait un moment que ca existe, mais je découvre, alors...)

Hop un peu de hors sujet sur l'archi du GPU.. .(bien qu'a terme il n'est pas dit que la voxelisation ne soit pas accélérer par le GPU). Le voxel c'est la nouvelle direction d'ID pour la techno à venir. Avec l'id-tech 5 ils manipulent des textures "infinies" (Megatexturing) , avec l'id-tech 6 Carmack veut de la géométrie "infinie". En fait si ça n'était pas ID software par l'intermédiare d'un Jon Olick qui parle de voxel, ben je penserai à un buzz énorme qui ne cache en fait qu'un "plein de rien".

Ceci dit le voxel est une primitive puissante qui s'affranchit de pas mal de problème.

c'est une représentation volumique donc on peut représenter pas mal de chose par du voxel. Plus besoin d'expliciter à part les [soft] particules etc. Le voxel peut représenter tout ça sans hack (fumée, feu etc).
ID parle de géométrie infinie au point où le bump-mapping serait remplacer par de la vrai géométrie .
Le voxel est une primitive élégante. Il peut contenir toute les informations nécessaires pour l'afficher (Couleur, normales etc.)... Par exemple plus besoin de paramétriser un objet pour lui plaquer une texture vu que la texture c'est directement les voxels.
La position du voxel est définie implicitement par la structure qui le contient (typiquement un octree) et ça... c'est le bien: cette structure représente à la fois la primitive à intersecter et le partitionnement dans l'espace de ces primitives. Bref contrairement aux triangles qui nécessitent un travail particulier pour être partitionner dans des structures de données particulières (kd-tree, BVH, etc.) le voxel est d'emblée partitionné dans un grille ou un octree (ceci dit, rien n'interdit d'utiliser d'autres structures). Pour le lancer de rayons sur des voxels c'est donc parfait.
le voxel est une primitive très peu coûteuse à intersecter. Bien moins coûteuse qu'un triangle. Le lancer de rayons sur des voxels est donc à priori moins "cher."
Un octree de voxels permet une multi-résolution ultra naturelle. Pas besoin de descendre dans l'octree qd la taille apparente des cellules sous-jacentes est inférieure à la taille d'un pixel. Autrement dit, pas besoin d'afficher du détail là où ce n'est pas utile. C'est grosso modo un mip-mapping de la scène.
niveau effet primaire locaux c'est très puissant. Et c'est justement ce que fait Jon Olick chez ID: ray-casting de voxel. De ce fait, contrairement à la rastérization de triangles, il n'y a ici pas de problème pour la transparence, la refraction... C'est également très puissant d'un point de vue artistique. Vu que le voxel est volumique rien n'interdit de représenter tout les objets sous cette forme. Dès lors en faisant simplement varier "la valeur que l'on veut afficher dans le volume" (l'iso value), on peut simuler le vieillissement d'un matériau, l'érosion, l'usure, ou de façon plus ID software la décomposition d'un cadavre ...
etc...

Par contre les voxels ne sont pas exempts de défaut.

Leur plus gros problème reste la taille astronomique des données à manipuler. Il faut des millions de voxels pour représenter une géométrie fine. Sur une petite grille régulière de voxels qui contiennent une information de couleur sur 4 octets ça fait déjà du 512x512x512x4=512MB en non compressé. Si ID parle de géométrie à l'échelle d'un bump mapping la masse de données à manipuler sera carrément gigantesque! Ils vont certes mettre à contribution leur algo de virtualisation de texture ala megatexturing (un octree de voxel n'est rien de plus qu'une texture 3D) mais ça semble qd même très difficile!
En allant plus loin, ce problème de mémoire devient d'autant plus critique qd on s'éloigne des effets primaires (shading de base)! Ne serais ce que pour les ombres, si on voulait les générer avec du ray-tracing sur des voxels, alors il faut que les voxels qui occultent la lumière soient accessibles et donc en mémoire. Pour les reflets c'est pareil. En poussant à l'extrême pour de l'éclairage global on peut potentiellement avoir besoin d'accéder à *toute* la scène pour une seule frame. Dans ce cas le manager de mémoire qui charge les voxels à de grande chance de s'effondrer brutalement...
Un autre problème est l'animation des voxels. Il faut soit être très efficace pour voxélizer à la volée un objet triangulaire animé, soit animer les voxels directement (ouch!!!). Dans tous les cas ça pose le problème de la mise à jour à la volée de l'octree de voxels.

Bref il me tarde vraiment d'en savoir plus sur leur techno (Jon Olick en parle à SIGGRAPH). En fait je ne sais pas si c'est vraiment un bon choix. Si l'on veut de la géométrie pseudo infinie le rafinement [adaptatif] de triangles est déjà trés puissant. Avec la tesselation hardware bientôt supportée en standard par toute les GPU je reste dans le doute qt à savoir si le voxel est un concurrent sérieux...

**fefe** · 27/07/2008, 15h23

Tiens marrant que les voxels (re)surgissent. La seule application courante que j'en avais vu etait en imagerie medicale et ca ramait serieusement a l'epoque

. C'etait effectivement tres pratique pour permettre une representation 3D a partir de mesures faites en tranches par un scanner ou autre irm.

**Alice** · 27/07/2008, 15h34

Envoyé par fefe

Tiens marrant que les voxels (re)surgissent. La seule application courante que j'en avais vu etait en imagerie medicale et ca ramait serieusement a l'epoque

. C'etait effectivement tres pratique pour permettre une representation 3D a partir de mesures faites en tranches par un scanner ou autre irm.

L'imagerie médicale est son domaine de prédilection. En fait toute donnée volumiques nécessite une représentation volumique (scoop). comme on discrétise souvent ces données en samplant régulièrement l'espace ça donne des petits cubes dans l'espace où les données sont stockées. Paf voilà le voxel. Ceci étant on peut afficher les données volumiques autrement qu'en affichant les voxels eux mêmes (Marching Cube, slicing)... Si on passe par du triangle par exemple qui est accélérer naturellement par le GPU, les performances restent correctes.

Bref pour le volumique le voxel est par nature super naturel. Pour le jeu c'est bien plus casse gueule à mon avis (outcast, commanche, Delta Force etc.)

**fefe** · 27/07/2008, 16h09

Oui je me souviens de la demo du passage d'une appli medicale du voxel au triangle et qui gagnait un facteur 20 (sur Geforce 1)...

**newbie06** · 27/07/2008, 20h03

Il me semble qu'il y avait eu un jeu dans les années 90 qui utilisait du voxel software, un truc genre hélico. Ouai on est HS là

EDIT : Delta Force en 1998, suivi de plein d'autres. cf la page Wikipedia sur les voxels.

**Alexko** · 27/07/2008, 20h33

http://en.wikipedia.org/wiki/Comanche_series

**Alice** · 28/07/2008, 09h59

Envoyé par newbie06

Il me semble qu'il y avait eu un jeu dans les années 90 qui utilisait du voxel software, un truc genre hélico. Ouai on est HS là

EDIT : Delta Force en 1998, suivi de plein d'autres. cf la page Wikipedia sur les voxels.

oui... cf mon dernier post

. On peut citer aussi le projet Voxelstein.

Par contre tout ces jeux utilisaient des voxels gros comme le point (du fait d'un manque de mémoire et de puissance de calcul). ID parle au contraire de voxels pseudo à l'infini, donc apparemment toujours inférieurs à la taille d'un pixel. De ce fait il ne devrait plus y avoir de cube apparents.

**newbie06** · 28/07/2008, 12h51

Envoyé par Alice

oui... cf mon dernier post

. On peut citer aussi le projet Voxelstein.

Desole, trop de Diablo2 me ramollit encore plus le bulbe

**Møgluglu** · 28/07/2008, 19h04

Si j'ai bien suivi le lancer de rayon sur voxels se ramène à faire un bresenham dans un octree. Donc du calcul entier bien plus simple que ce que savent faire les GPU.
Je me demande s'il y a moyen de réutiliser le rasterizer pour ça, quitte à ajouter quelques datapaths dans le GPU.
Vu qu'on a une structure hiérarchique et plus plane, il faut que les shaders lancés en sortie du raster puissent lancer immédiatement une autre rasterization pour descendre dans l'arbre... Et un moyen de recycler les threads et une pile.

[Edit: en fait ça peut se faire avec le hardware actuel, à condition d'avoir des vrais shaders unifiés (pixel shaders qui peuvent émettre des primitives comme des geometry shaders) qui ont accès aux features Cuda (réductions, scatter).
Le problème c'est que vu qu'on explore les cellules de l'octree en parallèle pour un rayon donné, il faut tracer le rayon jusqu'au bout plutôt que de s'arrêter au premier objet opaque. Et même en cas de transparence il faut que le résultat ne dépende pas de l'ordre de parcours. Donc au mieux ça peut servir dans des cas très spécifiques.]

Aussi, Lefebvre utilise déjà le filtrage et le mipmapping des unités de texturage pour ses texture volumétriques, en perdant pas mal de mémoire au passage. Ça ne coûterait peut-être pas si cher d'avoir une gestion native des octrees dans les unités de texturage, en récupérant la logique du mipmapping?

**Alice** · 29/07/2008, 10h29

Utiliser le raster pour afficher des voxels? Pour une projection orthogonal aligné aux voxels ça revient effectivement à ampiler des "rastérization". Dans le cas général ca risque de devenir un monstre tentaculaire. En fait je vois pas vraiment ça comme de la rastérization car la rastérization ce n'est pas de la simu de lancer de rayons mais un process qui rempli du triangle et interpole des paramètres avec une politique "out-of-order" pour le traitement des primitive à afficher (du moins avec un algo de visibilité du type Z-buffer).

L'autre point qu'il faut considérer est le manque de virtualisation pour les accés mémoire. Pour accéder à une texture il faut qu'elle soit chargée sur GPU. Si la texture fait plusieurs Giga on rigole déjà bcp moins. On peut toujours découper la texture en "tile" et faire des requêtes à un texture manager qd le tile n'est pas disponible et on retombe alors sur ce qui se fait actuellement pour l'affichage de masses de voxels avec un lancer de rayon. Avec une approche raster pour savoir ce qu'il faut charger il faut connaitre ce qui est visible dans la scène. C'est le principe des megatexture (une passe de rendu des triangles visibles dans l'espace de la texture). Le problème est qu'avec des voxels définir les voxels visible revient à priori à parcourir la structure qui les contient et donc à interroger le manager de voxels pour les charger! Bref on se mord la queue. Afficher un octree de voxel me semble bien plus naturel/souple avec un ray casting brutal.

Ceci dit je pense sincèrement que la raffinement de géométrie est bien plus efficace pour afficher de la géométrie "infinie". Combiné avec une megatexture de displacement et du rafinement adaptatif, on peut obtenir une multi résolution de la scène très proprement et ce en évitant, comme avec des voxels, le popping des changement de LOD.

**fefe** · 29/07/2008, 15h42

Parcouru l'article de HFR sur Tesla et Cuda. Lecture interressante, maintenant faut que je digere.

**Møgluglu** · 29/07/2008, 18h57

Envoyé par Alice

Utiliser le raster pour afficher des voxels? Pour une projection orthogonal aligné aux voxels ça revient effectivement à ampiler des "rastérization". Dans le cas général ca risque de devenir un monstre tentaculaire.

Dans le cas général ça me parait encore gérable tant que que le plan sur lequel on fait le raster est pas trop orthogonal avec les rayons qu'on lance (sinon ça revient à faire quasiment toute la rasterization en soft).
Ce que je rasterize, ce n'est pas les voxels, ce sont les rayons.
Le raster calcule la projection discrète du rayon sur le plan xy, et dans chaque case lance un shader dans lequel on va itérer sur les z. Et soit émettre de nouvelles primitives (descente dans l'arbre) soit lancer une réduction pour renvoyer l'intersection la plus proche. (les "pixels" en sortie du raster ne correspondent à rien et ne seront jamais écrits.)
Pour l'effet "out-of-order", on pourrait à la limite modifier le thread scheduler du GPU pour qu'il émette les pixels dans le bon ordre... Et reconfigurer les buffer de primitives en piles pour faire un parcours en profondeur et pas en largeur. Euh, tu disais monstre tentaculaire?...

Mais bon de toute façon c'est une solution à un faux problème, le raster/bresenham n'est certainement pas le bottleneck de l'algo. Ce qu'il faut optimiser c'est la localité des accès et la cohérence SIMD.

L'autre point qu'il faut considérer est le manque de virtualisation pour les accés mémoire. Pour accéder à une texture il faut qu'elle soit chargée sur GPU. Si la texture fait plusieurs Giga on rigole déjà bcp moins. On peut toujours découper la texture en "tile" et faire des requêtes à un texture manager qd le tile n'est pas disponible et on retombe alors sur ce qui se fait actuellement pour l'affichage de masses de voxels avec un lancer de rayon.

...Et si la texture ne tient pas non plus dans la mémoire centrale, il faut aller streamer depuis le disque, donc une intervention du CPU et une latence monstrueuse supérieure à 1 frame...
Je suppose qu'il y a aussi plein de façons de générer le contenu à la volée pour les détails, style fractales, modèles spectraux, pyramidaux, etc.

Afficher un octree de voxel me semble bien plus naturel/souple avec un ray casting brutal.

Et pour les rayons secondaires, on peut se permettre de descendre moins loin dans l'octree j'imagine?

Ceci dit je pense sincèrement que la raffinement de géométrie est bien plus efficace pour afficher de la géométrie "infinie". Combiné avec une megatexture de displacement et du rafinement adaptatif, on peut obtenir une multi résolution de la scène très proprement et ce en évitant, comme avec des voxels, le popping des changement de LOD.

Même si on supposait qu'on pourrait avoir du jour au lendemain un GPU spécialisé dans tel ou tel type de rendu?
(Et à quoi ressembleraient ces GPU?...)

**Alice** · 29/07/2008, 19h59

Envoyé par Møgluglu

Dans le cas général ça me parait encore gérable tant que que le plan sur lequel on fait le raster est pas trop orthogonal avec les rayons qu'on lance (sinon ça revient à faire quasiment toute la rasterization en soft).

En fait par projection orthogonale je pensais justement à inverser les axes... le rayon est lancé depuis l'oeil mais le raster regarde le coté

Le raster calcule la projection discrète du rayon sur le plan xy,

D'accord... En fait je pense que tout peut se faire actuellement. Je réfléchis pendant que je tape. Dans la suite je considère que le travail de raster de ligne est fait par le raster fixe du GPU et que les voxels sont rangés dans une grille régulière. Bon les tranches de la grille de voxels ne correspondent en rien aux pixels à afficher. Rien d'affolant, il suffit de décorréler les 2; çad placer la direction du raster de telle sorte qu'elle regarde orthogonalement la face de la grille la plus parallèle à la direction de la caméra. La résolution du raster en x et y correspond à la résolution de la grille de voxel.

et dans chaque case lance un shader dans lequel on va itérer sur les z.

On a pas forcément besoin d'itérer le process en Z... le raster affiche une ligne avec son info de profondeur. Tous les pixels "allumé" ont donc accès à cette info et savent à quelle position en Z la grille est intersectée (c'est dans l'esprit des papiers sur la voxelization sur GPU). On peut donc savoir exactement quelles cellules sont intersectées par le rayon. Une fois qu'on l'a on interroge nos voxels pour savoir si il y en a un dans cette cellule ou non. Si oui on met un 1 sinon on met un 0.Par contre on a tous les voxels visible le long du rayons. On retrouve la propriété du out-of-order de la visibilité du raster. Une réduction en Z le long du rayon peut donner le voxel le plus proche. Cependant on a encore un problème, les rayons dans l'alignement ou presque de la projection de raster. Même avec une rasterization conservative on ratera toujours des voxels (info en Z manquante). Une solution simple consiste à rastérizer 3 fois le rayons selon les 3 faces de la grille les plus orthogonales à la direction de vue de la caméra et enfin combiner le résultat. (on peut ruser en choisissant la direction la face la plus orthogonale et ne rasteriser que dans celle là). Avec des géométrie processors on s'en sort en 1 invocation de rendu et 3 render target.

Maintenant côté mémoire: Sur G80 on peut avoir 8 render target entières RGBA. Donc pour un pixel on a une profondeur de 8*32bits*4 channels = 1024bits. Bon en ne calculant que l'info de visibilité ça nous laisse donc une profondeur de grille de 1024 voxels binaire. On va considérer le cas simple çad une grille carrée donc un frame buffer de 1024x1024 soit une consommation mémoire théorique de 1024x1024x1024 = 1GB pour la visibilité!!! On peut ceci dit découper en bloc. Bon considérons que la mémoire n'est pas un problème ce qui nous reste à faire maintenant c'est trouver le premier voxel visible le long du rayon de la caméra. Une fois qu'on l'a, on accède aux infos des voxels visibles pour les shader. (Pour se faire on interroge le voxel manager style megatexturing qui se charge de pré charger les données en fonction d'heuristique sur le déplacement de la caméra...Etc).

A première vue rasterizer le lancer de rayons semble jouable mais c'est d'une boucherie rare!!! Surtout qu'on ne prend pas en compte la transparence. Dans ce cas il faudrait autre chose qu'une info binaire de visibilité lors du raster des rayons et la mémoire qui va avec! (Mémoire déjà problématique ne serais ce que pour rastérizer la visibilité)

...Et si la texture ne tient pas non plus dans la mémoire centrale, il faut aller streamer depuis le disque, donc une intervention du CPU et une latence monstrueuse supérieure à 1 frame...

C'est justement le problème qu'adresse les megatextures. Donc de ce côté pas """trop""" de problème...

Je suppose qu'il y a aussi plein de façons de générer le contenu à la volée pour les détails, style fractales, modèles spectraux, pyramidaux, etc.

Oui tout à fait... de tout façon le tech report sur le megatexturing couvre ce genre d'applie. Le texture producer peut soit préchager soit générer des textures procédurales...etc

Et pour les rayons secondaires, on peut se permettre de descendre moins loin dans l'octree j'imagine?

Pour les rayons secondaires ça risque de s'affoler côté mémoire... (cf mon premier post sur le sujet). C'est pour ça à mon avis qu'il ne parle que de ray casting.

Même si on supposait qu'on pourrait avoir du jour au lendemain un GPU spécialisé dans tel ou tel type de rendu?

Non bien sur

... On ne peut savoir ce que serait les choix techniques à faire dans un autre contexte. Ceci dit dans le contexte actuel le rafinement de géométrie est déjà bien puissant et totalement exploitable sur tous les GPU depuis le Geforce 4. Deplus depuis les Geforce8 tout peut se faire sur GPU de façon super brutale à l'aide de l'instanciation du pattern de raffinement et du stream out des paramètres à y appliquer dessus. A l'avenir ça sera encore plus bourrin puisque le raffinement sera fait en hard par l'unité de tesselation.

**Møgluglu** · 29/07/2008, 21h56

Envoyé par Alice

Rien d'affolant, il suffit de décorréler les 2; çad placer la direction du raster de telle sorte qu'elle regarde orthogonalement la face de la grille la plus parallèle à la direction de la caméra. La résolution du raster en x et y correspond à la résolution de la grille de voxel.

Oui.

On a pas forcément besoin d'itérer le process en Z... le raster affiche une ligne avec son info de profondeur. Tous les pixels "allumé" ont donc accès à cette info et savent à quelle position en Z la grille est intersectée [...] Cependant on a encore un problème, les rayons dans l'alignement ou presque de la projection de raster. Même avec une rasterization conservative on ratera toujours des voxels (info en Z manquante).

C'est pour ça que je parlais d'itérer sur les Z. On veut parcourir tous les Z entiers entre floor(Z du précédent) et ceil(mon Z). Soit on utilise les instructions de dérivée partielle, soit on passe comme attributs un Zmin et un Zmax au lieu d'un simple Z. (où Zmax - Zmin=C constant="épaisseur" de la droite vue de l'axe Z). Comme c'est une droite tout est linéaire et les Zmin et Zmax sont interpolés comme il faut. Soit on les calcule en fonction de Z et C.

Après je suppose que j'ai accès à toutes les features de CUDA depuis mes shaders (ou bien accès au rasterizer en CUDA). J'ai passé comme attribut de ma ligne les coordonnées X et Y du "vrai" pixel auquel correspond le rayon. Chaque "faux" pixel sait donc où écrire son résultat, et il le fait en utilisant les instructions mémoire atomique (genre atomicMin pour la distance, et atomicCAS pour la couleur ou un pointeur sur le voxel). À titre d'optimisation, on peut commencer par faire une réduction sur le warp (sur le G80, tous les threads d'un warp viennent toujours de la même primitive). Une fois qu'on a écrit le résultat, on kill le pixel, et on réutilise toujours le même render target sur lequel on n'écrit jamais rien.

Après on peut faire éventuellement une deuxième passe sur chaque vrai pixel de l'écran pour récupérer le pointeur sur le voxel et calculer sa couleur, voire relancer tout le bouzin pour tracer des rayons secondaires.

A première vue rasterizer le lancer de rayons semble jouable mais c'est d'une boucherie rare!!! Surtout qu'on ne prend pas en compte la transparence. Dans ce cas il faudrait autre chose qu'une info binaire de visibilité lors du raster des rayons et la mémoire qui va avec! (Mémoire déjà problématique ne serais ce que pour rastérizer la visibilité)

C'est sur que sans les réductions/scatter/atomiques à la CUDA c'est mal barré.
Pour la transparence, on peut gérer ça avec la fonction de réduction et les atomiques qui vont bien, à condition que le fonction de blending ne dépende pas de l'ordre d'évaluation.

N'empêche que le jour ou on aura enfin un environnement qui permette d'utiliser toutes les features d'un GPU moderne, sans avoir à choisir entre Raster et GPGPU, on pourra écrire des vrais algos...

Pour les rayons secondaires ça risque de s'affoler côté mémoire... (cf mon premier post sur le sujet). C'est pour ça à mon avis qu'il ne parle que de ray casting.

Pas sûr, si on lance des rayons secondaires très "épais" (*), ce qui doit être suffisant pour les réflections sur des matériaux diffus, on s'arrêtera dés les premiers niveaux de l'octree.

Vu que ces voxels près de la racine contiennent à la fois du creux et du plein, ils vont être considérés comme partiellement transparents, et le risque est de voir à travers des choses qui auraient dû être occultées. Mais pour des rayons secondaires ça peut être acceptable.

(*) Je vois mieux ça comme du lancer de cônes, où on cherche les voxels de taille comparable à la section du cône à l'endroit de l'intersection, sans descendre plus bas.

Non bien sur

... On ne peut savoir ce que serait les choix techniques à faire dans un autre contexte.

On peut toujours imaginer.
Par exemple, est-ce qu'un GPU actuel qui sache communiquer directement à un SSD sur PCIe sans passer par le CPU serait un monstre pour le traçage de voxels?

**Alice** · 30/07/2008, 10h57

C'est vrai qu'avec du scatter et des opérations atomiques ça serait bien plus gérable. Par contre il reste un point néfaste. La rastérization de ligne c'est le mal ou plus généralement, la rastérization de primitives qui couvrent peu de pixels c'est le mal et ce en raison de "threads SIMD" gérés par bloc. Je pense donc à une autre approche: Ne pas rastériser des rayons (lignes) mais le frustum

.

C'est une approche en 2 passes. On calcule d'abord la visibilité des cellules. Pour se faire, on se place toujours dans la direction la plus // à la direction de projection de la caméra (quoiqu'à première vue ce ne soit pas forcément utile). On rastérize toujours en projection orthogonale mais cette fois on dessine le volume du frustum en désactivant le back face culling. La grille est initialement à 1 pour tous les cellules (<=> toutes les cellules sont visibles). Chaque pixel recouvert par la rastérization calcule alors un masque de bits. Ce masque est mis à 1 pour les cellules du demi espace intérieur au frustum et à 0 pour le demi espace extèrieur. Les ROPS se chargent de faire un ET logique avec la grille initiale. A la fin de cette passe on obtient alors l'ensemble des cellules contenues dans le frustum. Un ET logique avec la visibilité des voxels et on obtient alors les voxels dans le frustum. Hop petit requête au voxel manager et on peut scatteré le shading des voxels dans le plan image. En fait je pense qu'il n'y a du coup plus de problème voxels raté. Il faut qd même s'assurer d'avoir un rastérization conservative.

Le mieux serait de faire tout ça avec une rasterization hiérarchique. On commence sur un grille de 2^3. On rasterise le frustum et on détermine les voxels effectivement contenus dans le frustum. Pour les cellules non visibles on discarde la zone pour la prochaine rasterization. Hop on recommence le raster dans les cellules recouvertes avec un onctree de 4^3 et ainsi desuite. Avec la matos actuel on peut discardé en choisissant des tailles de cellules qui recouvrent le mieux possible le nombre de pixels correspondant à un bloc de "threads SIMD". On perd en place mais on gagne en cohérence. Avec cette approche hiérarchique les premiers niveaux sont peu chers en mémoire et en calcul. La pseudo visibilité des voxels peut donc être cachée en mémoire GPU pour les tout premiers niveaux. Pour faire ça plus proprement on peut écrire une raster soft sur cuda qui se charge de faire la rasterisation
hiérarchique et les requêtes au CPU pour charger la visibilité des niveaux de voxels à tester. Mais bon ca ne sera possible que qd CUDA permettre une vrai communication asynchrone GPU vers CPU.

A noter qu'on peut aussi stopper le raffinement qd on a trouvé un voxel visible de taille inférieure à un pixel. Dans ce cas il se pose toujours le problème de la transparence que l'on ne connaîtra que lorsqu'on aura chargé les donnée de shading (et non plus QUE la visibilité). Dans tous les cas ça me semble qd même bien plus monstrueux qu'un ray casting brutal. Il faudrait voir si le gain en perf serait notable. Sur des petites données peut être mais sur des gros octree de voxels énormes c loin d'être sur car on risque de ne plus pouvoir rasterizer à une profondeur trop grande (style 2^20). Le ray casting fait les requêtes de visibilité uniquement sur les voxels sur le chemin du rayon et non pas sur les voxels potentiellement sur son chemin. Avec une grille et de la rasterization on peut éventuellement se contorsionné pour faire pareil si on a du scatter style cuda mais pour un octree de voxels ça semble bien plus difficile.

Envoyé par Møgluglu

N'empêche que le jour ou on aura enfin un environnement qui permette d'utiliser toutes les features d'un GPU moderne, sans avoir à choisir entre Raster et GPGPU, on pourra écrire des vrais algos...

C'est vrai. En fait il ne manque pas grand chose au prog graphique. Si DX11 et le futur OGL (s'il ne crève pas en route

) propose effectivement des shader dans la philosophie prog graphique pour du calcul général on devrait avoir a peut près tout. Proposer le raster sur Cuda? mouais pourquoi pas mais si c'est le cas on a deux modèles de prog qui diverge sur le fond et qui rentre donc en concurrence. Si on veut du graphique, autant proposer une API graphique qui englobe tout, ou soit la supprimer et proposer une "lib CUDA" qui simplifie la tache pour ce type de prog (par exemple le stream out directement coder plutôt que de se farcir un prefix scan à la paluche) et donner accès au fonctionnalité qui manque à CUDA.

Par exemple, est-ce qu'un GPU actuel qui sache communiquer directement à un SSD sur PCIe sans passer par le CPU serait un monstre pour le traçage de voxels?

Non je crois pas. Autant passer par le CPU. En fait je comprends pas ce qui est génant la dedans. Le CPU se charge de manager le transfert et le pré chargement des données qui sont requises. Il sert à virtualiser l'espace d'adressage. Avec une politique de pré chargement judicieuse (du style de celle mise en oeuvre dans l'ID-tech4/5) on peut s'en sortir. En fait ID à vraiment optimiser son pipe de pré chargement, décompression CPU, recompression pour le GPU etc. L'étage qui le limite est en fait le support de stockage (DVD). Avec les CPU qui vont de plus en plus vite ça sera toujours le cas en fait et le CPU sera à mon avis très rarement l'étage qui limite les perfs de ce type d'approche (même avec du SSD).

Ceci dit le pipe d'ID est efficace pour du megatexturing. D'accord ça on le sait mais des voxels infinis c'est qd même autre chose que des textures infinies. Ca rajoute un peu une dimension!!! Ca risque de sacrément bourriner les ressources mémoires! Dès lors le raffinement géométrique (bien bien bien bien bien bien bien etc. cher en mémoire) est bien plus intéressant/efficace selon moi.

**Yasko** · 30/07/2008, 15h21

Envoyé par fefe

Parcouru l'article de HFR sur Tesla et Cuda. Lecture interressante, maintenant faut que je digere.

CUDA et le x86 multicore
C'est selon nous l'information la plus intéressante dévoilée par Nvidia : l'ajout dans le compilateur CUDA d'un profil optimisé pour les CPUs x86 multicores !

Actuellement, le code CUDA est séparé en 2 parties : une partie traitée par le CPU et redirigée vers un compilateur classique (du choix du développeur) et une autre partie spécifique au GPU, dont s'occupe le compilateur CUDA. La nouveauté est qu'il sera dorénavant possible de compiler cette partie spécifique au GPU pour le CPU, de manière à ce que la totalité du code CUDA tourne sur ce dernier. L'exploitation automatique du multicore sera réalisée via, grossièrement, la transformation d'un bloc de threads GPU en un thread CPU.

En gros, le compilateur Cuda se comporte comme le TBB d'Intel si il n'y a pas de GPU compatible Cuda ?

**newbie06** · 30/07/2008, 17h15

Apparemment CUDA n'est pas profitable : http://www.theinquirer.net/gb/inquir...uts-half-staff

Ouai, je sais c'est pas une info technique

**fefe** · 30/07/2008, 17h20

Envoyé par Yasko

CUDA et le x86 multicore
C'est selon nous l'information la plus intéressante dévoilée par Nvidia : l'ajout dans le compilateur CUDA d'un profil optimisé pour les CPUs x86 multicores !

Actuellement, le code CUDA est séparé en 2 parties : une partie traitée par le CPU et redirigée vers un compilateur classique (du choix du développeur) et une autre partie spécifique au GPU, dont s'occupe le compilateur CUDA. La nouveauté est qu'il sera dorénavant possible de compiler cette partie spécifique au GPU pour le CPU, de manière à ce que la totalité du code CUDA tourne sur ce dernier. L'exploitation automatique du multicore sera réalisée via, grossièrement, la transformation d'un bloc de threads GPU en un thread CPU.

En gros, le compilateur Cuda se comporte comme le TBB d'Intel si il n'y a pas de GPU compatible Cuda ?

Ce qui serait interressant est que si il y a un multicore et un GPU qui supporte CUDA, la charge soit repartie de maniere ad hoc sur l'ensemble des ressources de calcul (heterogenes).

**Møgluglu** · 30/07/2008, 19h08

Envoyé par Alice

C'est une approche en 2 passes. [...] En fait je pense qu'il n'y a du coup plus de problème voxels raté. Il faut qd même s'assurer d'avoir un rastérization conservative.

J'avais pensé à rasterizer des pyramides au lieu de lignes aussi...
Mais effectivement comme ça ça peut bien marcher. Il faut juste élargir le frustum de la largeur d'un voxel dans chaque direction pour être sûr de ne pas en rater au bord, et penser qu'un voxel peut contribuer à plusieurs pixels du plan image.
Par contre du coup on n'utilise quasiment plus le raster...

Mais bon ca ne sera possible que qd CUDA permettre une vrai communication asynchrone GPU vers CPU.

Oui c'est le vrai problème, et pas que pour les octrees de voxels.

Et les solutions techniques ne sont pas trop élégantes : soit le GPU envoit une interruption au CPU, et on se prend tout le coût d'un handling d'interruption, soit on fait du polling sur une zone de mémoire partagée ou un truc du genre...

Proposer le raster sur Cuda? mouais pourquoi pas mais si c'est le cas on a deux modèles de prog qui diverge sur le fond et qui rentre donc en concurrence. Si on veut du graphique, autant proposer une API graphique qui englobe tout, ou soit la supprimer et proposer une "lib CUDA" qui simplifie la tache pour ce type de prog (par exemple le stream out directement coder plutôt que de se farcir un prefix scan à la paluche) et donner accès au fonctionnalité qui manque à CUDA.

Je ne pense pas que les 2 approches entrent en concurrence. L'API graphique part d'un modèle théorique et offre des features qui sont implantées plus ou moins bien en matériel et des façons de dévier du modèle. CUDA part d'une archi, le G80, et y donne un accès direct avec quelques abstractions.

Par exemple j'ai une appli de transfert radiatif où je calcule un spectre en faisant la somme de plein de gaussiennes plus ou moins disjointes. Rien à voir avec le graphisme, pourtant le raster se prête bien à ce calcul. En CUDA actuel il faudra que je fasse le raster et les interpolations à la main ; en GL/DX je suis coincé dans un modèle qui ne correspond pas du tout à ce que je veux faire. C'est un accès au raster depuis CUDA qui me conviendrait le mieux.

Inversement il y a certainement tout plein d'applis graphiques qui bénéficieraient du scatter, de la double, etc., et on ne veut pas réinventer la roue en les passant en CUDA avec ou sans raster. Ou à la limite avec une bonne bibliothèque, oui...

Le CPU se charge de manager le transfert et le pré chargement des données qui sont requises. Il sert à virtualiser l'espace d'adressage. Avec une politique de pré chargement judicieuse (du style de celle mise en oeuvre dans l'ID-tech4/5) on peut s'en sortir.

Avec du prefetch côté CPU et la mise en attente des rayons bloqués par une requête en cours coté GPU, oui on doit pouvoir s'en sortir. Mais il y a quand-même beaucoup de latence à absorber.

Envoyé par newbie06

Apparemment CUDA n'est pas profitable : http://www.theinquirer.net/gb/inquir...uts-half-staff

Ouai, je sais c'est pas une info technique

En voyant le lien je me suis dit : si c'est Charlie, c'est même probablement pas une info du tout, juste de l'anti-nvidiaisme primaire

Envoyé par fefe

Ce qui serait interressant est que si il y a un multicore et un GPU qui supporte CUDA, la charge soit repartie de maniere ad hoc sur l'ensemble des ressources de calcul (heterogenes).

À condition d'arriver à avoir un seul code qui soit aussi efficace avec 16K de shared memory pour 16x32 threads qu'avec 3Mo de cache pour 4x4 threads...

**fefe** · 30/07/2008, 19h28

Envoyé par Møgluglu

À condition d'arriver à avoir un seul code qui soit aussi efficace avec 16K de shared memory pour 16x32 threads qu'avec 3Mo de cache pour 4x4 threads...

Pourquoi ne pas mettre 2n threads par core ? En partant du principe que ca n'arrivera pas avant des cores comme "Nehalem", tu as 2 threads par core (qui partagent 32k puis 256k, et 8M avec les autres cores.
Si tu pars du principe que tu as 16k par thread, tu peux essayer d'optimiser pour le L2 soit, 16 threads par cpu.. Ca te fait 128 threads avec 16k par thread... 128 threads, avec 8 seulement en simultane mais tu fais tourner.

Sachant que chaque thread mettra moins de temps a finir ses calculs sur le cpu, (latences generalement nettement inferieures), rien ne t'empeche d'en envoyer nettement plus et de les alterner dans le temps.
Ca doit etre possible de se debrouiller pour precharger un thread pendant qu'un autre tourne.

**Møgluglu** · 30/07/2008, 20h20

Envoyé par fefe

Pourquoi ne pas mettre 2n threads par core ?

Mon calcul, ça serait (pour Nehalem)
warp/blocks =
4 threads/warp (SSE)
* 2 warps (SMT réel)
* n (SMT virtuel ~= facteur de déroulage de boucle)

Comme sur GPU, on à m blocks/core exécutés séquentiellement, ou avec des threads au sens thread CPU à gros grain.

(En passant je ne suis pas sûr que ce soit une bonne idée d'intégrer le SMT réel à l'intérieur d'un block.)

Dans CUDA m et n sont fixés par l'utilisateur.
m n'influe quasiment pas sur les perfs (séquentialisation).

Sur un GPU plus n est grand mieux c'est (tant qu'on reste dans les limites du banc de registres, mémoire partagée et du scheduler).

Sur un CPU, c'est nettement moins évident. Si on déroule trop les boucles, on peut sortir du cache d'instruction. Alors que si on ne déroule pas du tout, on peut faire tenir toute la boucle dans les instruction buffers et potentiellement gagner beaucoup.

À moins que plutôt que dupliquer les instructions le compilateur ajoute des boucles internes...

Mais en tout cas le problème est bien plus compliqué que juste regarder la taille du working set/thread et choisir un nombre de threads pour que ça tienne dans le cache.

[Edit: j'ai rien dit, c'est le nb de threads/warp qui correspond au facteur de déroulage de boucle, donc valeur fixée par CUDA. Pour le nb de warps/block il faut bien utiliser des vrais gros threads CPU (et les synchoniser). Donc je vois encore moins l'intérêt d'augmenter n... On n'augmente pas le parallélisme et on rajoute des basculements de contexte.]

[Re-edit: en fait tout se ramène à des déplacements de boucles, voilà le papier qui explique ça]

**fefe** · 30/07/2008, 21h05

Je suggerais d'augmenter n pour laisser le temps de precharger (a la main) les donnees d'un thread qui n'est pas en train de tourner. Sinon cela n'a effectivement pas d'interet en terme d'amelioration du debit. La latence de la memoire sur le CPU est 1 ordre de grandeur plus faible, donc nettement moins de threads sont necessaires que sur le GPU, mais tout de meme...
SMT reste probablement une bonne idee, les meileures boucles de calcul numerique tunees aux petits oignons depassent rarement les 80% d'occupation des unites flottantes, sur du code "juste" compile tu descends rapidement a 60-70%, donc avoir un 2 eme thread augmente le throughput (et recouvre les latences memoire).
Le nombre de thread que je suggerais est probablement trop eleve pour permettre de recouvrir les latences memoires, 4/core serait amplement suffisant(2x2smt).

Je lis le papier demain, la c'est trop tard.

**fefe** · 31/07/2008, 14h39

Parcouru le papier, j'avais en effet occulte completement la partie fusion de threads pour generer du code SIMD, mais je partais du principe que le code etait deja SIMD (sinon je l'aurais compte dans le nombre de thread).

Sinon la methode qu'ils propose ne prend pas en compte les connaissances globales sur les patterns d'acces qui peuvent etre exploitees pour precharger les donnees pour d'autres threads a l'avance. Je pense que c'est probablement une bonne partie de la difference qui les oppose a la MKL qui fait tout ce qui est necessaire pour masquer les acces memoire.

Pour les threads, je dois avouer que lorsque je proposais de partager le travail entre CPU/GPU, je voyais une librairie de thread non preemptifs ecrite pour l'occasion tournant en mode kernel... Vouloir utiliser des threads lourds de base pour ce genre d'appli est tres certainement couteux en perf.

**Møgluglu** · 01/08/2008, 21h22

Envoyé par fefe

Parcouru le papier, j'avais en effet occulte completement la partie fusion de threads pour generer du code SIMD, mais je partais du principe que le code etait deja SIMD (sinon je l'aurais compte dans le nombre de thread).

J'utilisais la terminologie NVidia : thread SIMD = "warp", voie SIMD = "thread".

Sinon la methode qu'ils propose ne prend pas en compte les connaissances globales sur les patterns d'acces qui peuvent etre exploitees pour precharger les donnees pour d'autres threads a l'avance.

Dans le cas général ça me semble très compliqué, et Cuda n'aide pas du tout ici (ça reste du C avec plein de pointeurs qui obfusquent les patterns d'accès). Mieux vaut du Fortran pour ça...

Pour les threads, je dois avouer que lorsque je proposais de partager le travail entre CPU/GPU, je voyais une librairie de thread non preemptifs ecrite pour l'occasion tournant en mode kernel...

Plutôt en mode user, parce qu'une transition user<->kernel ça reste un surcoût monstrueux, même sur Penryn.
Et même en mode user, il faut de toute façon sauvegarder et restaurer les contextes.
Sur Northwood un FXSAVE/FXRSTOR c'était 100/150 cycles. Pas de chiffre plus récent, mais le nombre de registres à doublé depuis. Je ne pense pas que ce soit beaucoup moins qu'une latence mémoire.
[Edit: en non préemptif, pas besoin de sauvegarder tous les registres, et il faudra les spiller en cache de toute façon vu qu'il y en a pas assez pour tous les threads. Donc si ça peut le faire.]

La transformation de code semble donc une solution raisonnable.

Vouloir utiliser des threads lourds de base pour ce genre d'appli est tres certainement couteux en perf.

Disons qu'ici, la notion de block en Cuda correspond bien à celle de thread lourd : datasets disjoints, très peu voire pas du tout de synchronisation/communication.
Par contre à l'intérieur d'un block, les threads sont très étroitement liés.

L'autre chose qui étonne dans le papier, c'est qu'ils remplacent le code Cuda vectoriel par des boucles bien séquentielles, puis ils lancent derrière un compilo avec auto-vectorisation pour les re-paralléliser...
D'un point de vue pragmatique ce n'est pas si bête que ça, vu qu'ICC est déjà optimisé et ça évite de réinventer la roue.
Mais ça veut dire aussi que leur programme Cuda n'ira pas plus vite sur CPU qu'un programme C écrit proprement (pas forcément optimisé).

**Alice** · 05/08/2008, 16h16

petite parenthèse, en fait il semblerait qu'ID software ne fasse pas de la voxelization tel qu'on l'entend. Ils réutilisent la techno du megatexturing (ça on le sait) pour représenter une heightmap infinie qui encode "l'élévation" de la surface. C'est cette élévation qu'ils ray-castent. Franck avait linké un ray caster de ce type il me semble.

Olick souligne que la finesse du ray casting est telle qu'il faudrait énormément de triangles pour arriver au même résultat. Pour l'ID tech 6 la qualité visée demanderait l'équivalent de 32Millions de triangles par frame soit grosso modo 2Millards de triangles par secondes à 60fps! C'est tout simplement monstrueux. Ceci dit son estimation me semble démesurée. Il me semble qu'un rafinement adaptatif basé sur leur megamap d'élévation fournirait des résultats très fins sans pour autant demander autant de triangles et le tout serait dynamique... Ceci dit Jon Olick est un sauvage qui sait de quoi il parle. Vivement les slides de son talk de SIGGRAPH

EDIT:

Envoyé par Zelex alias Jon Olick

I apologize if I misspoke. The stamping technology currently only exists for infinite texturing. The plan is to extend the technology to pop geometry out from surfaces, where the popping out comes from the heightmaps on the stamps. If the modification of the oct-trees can be made fast enough, the stamping could be something similar to z-brush or mudbox. I think making it fast enough for this is possible, but maybe only with a 64-bit system with tons of ram (which hopefully will be much more commonplace in the future).

source: http://ompf.org/forum/viewtopic.php?f=3&t=904&start=50

Discussion: Archi GPU et GPGPU

Outils de la discussion

Règles de messages