Discussion :

[wax78]

Je ne sais pas si c'est le bon forum mais c'est surement mieux que dans certains autres je pense.

Voila mon problème est le suivant. J'ai un shader GLSL extrêmement gourmand (en gros un screen-sized quad pour faire du calcul de raytracing).

Bref, tellement gourmand que la fonction display() (je suis en jogl) n'as pas le temps de se terminer dans un temps impartis et donc j'obtiens un ecran noire suivi d'un warning de mon driver (nvidia dans mon cas) me disant qu'il a dut arrêter le process suite a une erreur...

Je me suis donc renseigné et il existe apparement un watchdog (logiciel ou hardware aucune idée) ou je ne sais quoi qui vérifie que la fonction display ou le shader (je sais pas) ne puissent pas etre executé plus de X millisecondes afin d'éviter un eventuel plantage...

Cf : forum de gpgpu ou j'ai put lire

The driver has a watchdog timer that is used to avoid deadlock kinds of scenarios. Unfortunately, this useful feature has the side effect that shaders can only take up to a certain amount of time to execute a single pass before the timer assumes they're misbehaving.

J'ai évidement contourner le problème en divisant mon screen-sized quad en plusieurs petit carré, j'appele display autant de fois qu'il y'a de petit carré sans vider le framebuffer (mes resultat etant la) et j'obtient le même résultat qu'avant, mais sans plantage MAIS avec bcp plus de lenteur. (Solution du "multi passe" en qlq sortes).

Connaitriez vous un moyen d'eviter cette espèce de timer qui m'interdit d'exécuter ma boucle display() (meme si ca mets 2 minutes) sans devoir faire la magouille décrite ci dessus ?

[Mat.M]

Salut,je ne suis pas spécialiste de la programmation GPU mais quelques remarques..

Voila mon problème est le suivant. J'ai un shader GLSL extrêmement gourmand (en gros un screen-sized quad pour faire du calcul de raytracing).

Qu'appelles-tu un "screen-size quad" ?
Un polygone avec 4 sommets donc 2 triangles liés par une arrête pour faire un quadrilatère de la taille de l'écran ?
Si tu veux faire du ray-tracing il n'est peut-être pas forcément pertinent d'utiliser l'accélération de la carte graphique...
est-ce que 3ds Max par exemple fait des rendus temps-réel ?

Connaitriez vous un moyen d'eviter cette espèce de timer qui m'interdit d'exécuter ma boucle display() (meme si ca mets 2 minutes) sans devoir faire la magouille décrite ci dessus ?

Le bon sens dit s'il y a des protections "hardware" c'est pas pour être décoratif c'est pour éviter que le matériel plante justement.
Et si tu veux contourner les protections hardware tu risques d'endommager ta carte graphique..

D'ailleurs si tu as un delta de temps de 2 minutes faire de la programmation GPU et programmer un shader en GLSL ne te sera d'aucune utilité !
Je ne suis pas trop spécialiste mais je vois les choses ainsi..

Voila mon problème est le suivant. J'ai un shader GLSL extrêmement gourmand (en gros un screen-sized quad pour faire du calcul de raytracing).

Bref, tellement gourmand que la fonction display() (je suis en jogl) n'as pas le temps de se terminer dans un temps impartis et donc j'obtiens un ecran noire suivi d'un warning de mon driver (nvidia dans mon cas) me disant qu'il a dut arrêter le process suite a une erreur...

tu expliques parfaitement le problème : si tu sollicites trop le GPU à faire de longs calculs et que tu rappelles la fonction Display() trop souvent le GPU n'a pas terminé ses calculs d'ou risque de plantage vidéo.
Donc une solution serait de limiter la cadence de la fonction Display() mais l'affichage sera plus lent..
il faut se rendre à l'évidence que malgré la performance des cartes graphiques récentes tu ne peux pas faire et des calculs d'illumination et des calculs de radiosité etc...bref toutes les caractéristiques d'un raytracer en même temps.

Si tu veux calculer une scène avec 3ds Max par exemple cela prend quelques secondes ne serait-ce que pour une scène toute simple.
Hors quelques secondes c'est bcp trop pour le processeur d'une carte graphique qui doit rafraichir l'écran avec une fréquence de 60/75 Hz par exemple.

Je me suis donc renseigné et il existe apparement un watchdog (logiciel ou hardware aucune idée) ou je ne sais quoi qui vérifie que la fonction display ou le shader (je sais pas) ne puissent pas etre executé plus de X millisecondes afin d'éviter un eventuel plantage...

eh oui mais c'est normal ! En tout logique si tu as un shader qui va s'exécuter plus de X millisecondes tu vas verrouiller et bloquer la carte graphique !

[LeGreg]

J'ai évidement contourner le problème en divisant mon screen-sized quad en plusieurs petit carré, j'appele display autant de fois qu'il y'a de petit carré sans vider le framebuffer (mes resultat etant la) et j'obtient le même résultat qu'avant, mais sans plantage MAIS avec bcp plus de lenteur. (Solution du "multi passe" en qlq sortes).

Essaie de voir pourquoi ça ralentit.
Si tu es largement GPU limited (ce qui semble être le cas), diviser l'écran en tranches ne va pas faire exploser le temps de calcul (la synchronisation supplémentaire n'étant pas le facteur limitant du temps de calcul). C'est en supposant que la division en tranche n'entraine pas trop de calcul redondants bien sur..

La raison d'être du time out c'est que le GPU n'est pas une bête coopérative, donc si tu bloques le GPU pour 2 min, l'affichage s'il doit faire appel à des fonctions du GPU va se geler pendant 2 min. C'est peut-être bon pour ton application mais attention aux attentes des utilisateurs qui ne veulent pas forcément perdre la main sur leur machine sur un temps aussi long.
Dans tous les cas il y a intérêt à diviser les tâches, c'est ce que fait Folding@home sur GPU par exemple : le calcul du repli des protéines peut être long, mais il est divisé en tâches de taille raisonnable pour pouvoir garantir l'interactivité du PC qui le fait tourner.

Bref divise ton travail (de manière optimale, ni trop gros ni trop petit), utilises des méthodes de synchro non bloquantes (event queries par ex), fait des present() d'un backbuffer bidon entre plusieurs "jobs" pour s'assurer que le tampon de commande progresse un petit peu à chaque fois.

[wax78]

Qu'appelles-tu un "screen-size quad" ?
Un polygone avec 4 sommets donc 2 triangles liés par une arrête pour faire un quadrilatère de la taille de l'écran ?
Si tu veux faire du ray-tracing il n'est peut-être pas forcément pertinent d'utiliser l'accélération de la carte graphique...
est-ce que 3ds Max par exemple fait des rendus temps-réel ?

Oui c'est un polygone avec 4 sommets

Ce n'est pas l'avis de certains developpeur de LuxRender, OctaneRender, etc ... eux semblent penser que c'est assez pertinant.

This typically involves the following steps:
Setting up the viewport for a 1:1 pixel-to-texel mapping.
Creating and binding textures containing the input data, downloading some data into these textures.
Binding a fragment program that serves as the “computational kernel”.
Rendering some geometry (usually a screen-sized quad to make sure the “kernel” gets executed once per pixel aka texel).

(selon la FAQ de gpgpu)

Le bon sens dit s'il y a des protections "hardware" c'est pas pour être décoratif c'est pour éviter que le matériel plante justement.
Et si tu veux contourner les protections hardware tu risques d'endommager ta carte graphique..

Ce n'est pas Hardware, ca se situerait dans le driver comme je l'ai dit précédemment. ("The driver has a watchdog timer that is used to avoid deadlock kinds of scenarios"). Dans mon cas le GPU est a température < 60° donc je ne pense pas qu'il s'agisse de chaleur ou de protection. Et non j'ai pas envie qu'il crâme bêtement

tu expliques parfaitement le problème : si tu sollicites trop le GPU à faire de longs calculs et que tu rappelles la fonction Display() trop souvent le GPU n'a pas terminé ses calculs d'ou risque de plantage vidéo.
Donc une solution serait de limiter la cadence de la fonction Display() mais l'affichage sera plus lent..
il faut se rendre à l'évidence que malgré la performance des cartes graphiques récentes tu ne peux pas faire et des calculs d'illumination et des calculs de radiosité etc...bref toutes les caractéristiques d'un raytracer en même temps.

Je ne rapelle pas la fonction display().

Et je n'espere pas non plus avoir un raytracer temps réel de la qualité de la qualité d'Avatar

Hors quelques secondes c'est bcp trop pour le processeur d'une carte graphique qui doit rafraichir l'écran avec une fréquence de 60/75 Hz par exemple.

Oui ca je ne dis pas, mais bon ca n'empeche rien. L'affichage ca me derange pas qu'il freeze 2 heures.

Essaie de voir pourquoi ça ralentit.
Si tu es largement GPU limited (ce qui semble être le cas), diviser l'écran en tranches ne va pas faire exploser le temps de calcul (la synchronisation supplémentaire n'étant pas le facteur limitant du temps de calcul). C'est en supposant que la division en tranche n'entraine pas trop de calcul redondants bien sur..

Bah quand je divise j'ai l'impression que le simple fait de repasser les uniform etc au shader réduit déjà pas mal les choses (je les repasse pour chaque "tranche" et il y en a 20 - 30). Mais bon je devrais repasser au profiler j'aurai peut être un indice.

La raison d'être du time out c'est que le GPU n'est pas une bête coopérative, donc si tu bloques le GPU pour 2 min, l'affichage s'il doit faire appel à des fonctions du GPU va se geler pendant 2 min. C'est peut-être bon pour ton application mais attention aux attentes des utilisateurs qui ne veulent pas forcément perdre la main sur leur machine sur un temps aussi long.

Oui mais comme je disais ca pour le moment ca me dérange pas je code pour moi

Dans tous les cas il y a intérêt à diviser les tâches, c'est ce que fait Folding@home sur GPU par exemple : le calcul du repli des protéines peut être long, mais il est divisé en tâches de taille raisonnable pour pouvoir garantir l'interactivité du PC qui le fait tourner.

C'est la seule alternative que j'ai trouvée.

Merci pour ces premières idées avec vous deux en tout cas.

[wax78]

Je suis un jour tombé sur un readme dans un logiciel de rendus 3D GPU qui mentionnait le même genre de problème.

Voici un fichier une modification de registre pour windows vista afin d'eviter de devoir faire du ping pong, mais cela peut engendrer des problemes, donc ne pas faire n'importe quoi avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Windows Registry Editor Version 5.00 
 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Watchdog\Display] 
"TdrDebugMode"=dword:00000001 
"TdrDelay"=dword:00000000

[LeGreg]

Je suis un jour tombé sur un readme dans un logiciel de rendus 3D GPU qui mentionnait le même genre de problème.

Voici un fichier une modification de registre pour windows vista afin d'eviter de devoir faire du ping pong, mais cela peut engendrer des problemes, donc ne pas faire n'importe quoi avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Windows Registry Editor Version 5.00 
 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Watchdog\Display] 
"TdrDebugMode"=dword:00000001 
"TdrDelay"=dword:00000000

Ce n'est vraiment pas le bon message à faire passer.. Affecter un paramètre global du système pour sa propre petite application n'est pas une bonne pratique.

Le fait est que le GPU n'est pas préemptif et il faut vous y faire.

Voici les recommendations "officielles" :

Graphics software vendors:
•

Ensure that the DirectX graphics application does not run at a low frames per second (FPS) rate. As the FPS decreases, the likelihood of the GPU getting reset increases. If the application is running at 10 FPS or lower and a complex graphics operation is about to start, then a flush can be inserted.
•

For running benchmark tests on low-end GPUs, use the aforementioned registry keys that control the TDR timeout. Remember that they should not be used in production systems because it would affect overall system stability and robustness. Use these keys only as a final solution.

[wax78]

D'ou ma phrase "mais cela peut engendrer des problemes"

Ce n'etait pas très explicite je l'avoue.

[gbdivers]

Bonjour wax78

Mon point de vue (très personnel) : même si on dit souvent que la programmation de shader est du calcul sur processeurs graphiques, ce n'est pas totalement vrai : il y a certaine limitation avec les shaders (comme tu as pu le constater) et les shaders restent avant tout une des étapes de l'affichage (et non un programme indépendant)

C'est pour cela que les constructeurs de carte ont mis en place des outils pour faire du "vrai" calcul sur processeurs graphiques. Et je te conseille d'utiliser cela !

Perso, je fais des calculs qui sont relativement long (plusieurs minutes à plusieurs heures) sur processeurs graphiques sans que ça plante : tu alloues en fait une partie des cores de la carte pour tes calculs et la carte reste disponible pour afficher l'écran (mais il vaut mieux éviter de faire des calculs et lancer de la 3D complexe en même temps )

Je te conseille OpenCL 1.1 pour la portabilité ATI/nvidia, le support C++ et l'interface OpenGL/OpenCL

[wax78]

Je suis bien d'accord avec toi. Mais il y'a un hic, opencl et cuda tourne-t-il sur de vieilles cartes graphiques ?

Mais sinon c'est certains que je ne vais plus m'acharner de cette maniere et opter pour une technologie plus récente. Il faut juste que je m'y mette

[gbdivers]

C'est quoi "vieille" ? CUDA date de 2006 je crois.
Tu as la liste des cartes nvidia compatibles ici : http://www.nvidia.fr/object/cuda_gpus_fr.html

D'un autre côté, si ta carte graphique est trop vieilles, est-ce vraiment intéressant d'utiliser l'accélération matérielle ? Si ta carte ne possède qu'un seul processeur de shader...

[wax78]

Lol n'exagerons rien, j'ai quand meme une 8800 qui fonctionne bien avec cuda ^^.

Mais il m'arrive de devoir coder sur des poubelles au travail ... mais bon je ne vais plus me casser la tête, ils n'ont qu'a racheter du matos

[gbdivers]

Ah oui. Une 8800 n'est pas une "vieille" carte (comparé à ma vieille 7500 )
Tu as entre 96 et 128 processeurs CUDA dessus, en fonction du modèle. Le gain de temps peut être très important par rapport à faire les calculs sur CPU (en fonction des algorithmes que tu utilises : tous les algorithmes ne se prêtent pas forcement à la parallélisation. Je connais pas assez le ray-tracing pour savoir)

Par contre, je ne sais pas si les performances permettront de faire du temps réel. Mais tu peux par exemple afficher progressivement l'image en cours de traitement.

Pour contre, tu citais plusieurs logiciels. Ils n'utilisent pas le GPGPU pour cela ?

[wax78]

Le raytracing est ultraparallelisable (chaque pixel de l'image final pouvant etre calculé en //).

Tout depend de la complexite de l'algorithme de rendus. Si c'est du simple raytracing de 10 spheres et 3 niveau de reflection je l'ai deja fait en pure fragment shaders sans soucis.

Le logiciel que je citais ici c'etait Arion de chez randomcontrol (pour l'histoire de la clé de registre), mais il y'en a d'autres.
Arion utilise CUDA.
D'autres developpeurs (Thea render par exemple) aussi (dans un avenir tres proche), bien qu'il fut un moment question d'Opencl, mais pas assez mature a leur gouts. Y'a Octane render aussi, CUDA.

Evidement ces logiciels ne font pas du BETE raytracing comme moi je m'amuse à en faire Et il font ca de maniere "progressive" comme tu le decris.

[gbdivers]

Ayant un peu tester CUDA et OpenCL, je n'ai pas trouvé que le second était immature (mais il est vrai que je ne suis pas non plus un expert et que je ne les ai pas poussé à l'extrême)
J'ai opté pour OpenCL (après avoir commencé par CUDA) dans l'idée de pouvoir comparer les performances nvidia/ATI (à prix égal)

Par contre, si tu connais bien le ray-tracing et que tu débutes avec le GPGPU (et que ton code n'est pas protégé), ça serait typiquement le genre de tutoriel qui pourrait être intéressant à rédiger : pour toi pour avoir des retours sur ton code ; pour les autres lecteurs pour avoir un exemple intéressant de ce qu'on peut faire avec le GPGPU et comment le faire.
Si ça t'intéresse, je pourrais t'aider à rédiger.

[wax78]

Ca pourrait etre une bonne idée. Il faudrait juste que j'arrive a adapter mon petit raytracer que j'avais fait en GLSL en opencl (ou en jocl car j'aime bien le java... mais bon la partie affichage n'etant pas trop complexe, le but etant de se focaliser sur le raytracing). Les vacances arrivent, peut etre aurais-je le temps/motivation, mais c'est un truc que je veux faire un jour c'est sure.

[gbdivers]

En fait, la partie en GLSL est intéressante aussi

Il y a déjà un tutoriel sur le raytracing (http://matthieu-brucher.developpez.c.../3D/raytracer/)
Si ton approche du raytracing est très différentes, tu peux faire un tutoriel sur le raytracing avec différentes implémentations (CPU, GLSL, GPU) et faire des benchmarks pour comparer les performances.

Pour le langage, perso, je suis plus Qt/C++ mais ce n'est pas grave : le code GLSL et OpenCL sera le même, c'est juste les appels qui sont différents.

Si le code de ton raytracing n'est pas protégé, tu peux me l'envoyer ? Je vais essayer de le comprendre et le convertir en C++

[wax78]

Non elle n'est pas vraiment differente, le lien que tu me donnes est vraiment la base de chez base (sans critique, c'est un bon tutorial, qui d'ailleurs n'est qu'une traduction d'un auteur anglophone si je ne me trompe...).

Si ce n'est qu'une question de benchmark, il est possible de faire quelque chose en glsl et en c pour comparer en effet.

L'algo de raytracing n'etant rien d'autre qu'un test d'intersection DemiLigne<->Sphere et un petit calcul de lumiere en fct de la normal au point d'impact.

Je vais tacher de ressortir mon code glsl du grenier et je te le donnes si tu veux (mais laisse moi du temps mais pas contre il n'y a aucune "optimisation" donc l'octree ou les bouding box faut oublier.

[LeGreg]

il y a certaine limitation avec les shaders (comme tu as pu le constater)

Son problème n'a strictement rien à voir avec l'utilisation de GLSL plutôt que Cuda. Le même shader executé en environnement Cuda aura les mêmes problèmes de temps d'exécution (TDR). Il faut donc savoir de quoi tu parles quand tu parles de limitation des shaders..

[gbdivers]

Bonjour LeGreg

A aucun moment je n'ai parlé que passer au GPGPU aller changer le temps d'exécution. J'ai juste dis que je n'avais pas de contrainte de temps maximum avec le GPGPU.
Cela ne veut pas dire non plus que c'est irréalisable avec le GLSL et qu'il n'était pas possible de faire sauter cette contrainte.

Quand a savoir si le GPGPU offre des fonctionnalités supplémentaires par rapport au GLSL, c'est un peu le but aussi, non ? Dans le forum indiqué en dessous, ils parlent par exemple de la mémoire partagée ou de la synchronisation des threads.


Pour wax78, j'ai trouvé des choses intéressantes sur le raytracing en GPGPU :
http://forums.nvidia.com/index.php?showtopic=171634
http://www.clockworkcoders.com/oglsl/rt/index.html
http://gpurt.sourceforge.net/DA07_04..._GPU-1.0.5.pdf
Ça peut peut être t'intéresser

[wax78]

Merci pour les liens j'y jetterais un oeil attentif.

Edit : Ha ben je les ais deja vu ^^ mais c'est pas grave ca peut toujours aidé moi ou quelqu'un d'autres.