Discussion :

[bactria]

Bonjour,

ayant appris (un peu dans la douleur ^^) les rudiments d'OpenGL au cours d'un projet informatique dans le cadre de mes études et une fois qu'on a dut le rendre j'ai voulut aller plus loin dans le domaine et recommencer un projet personnel. En essayant notamment de corriger les graves manques d'optimisation du programme.
Et je me suis rendu compte q'on faisait un truc stupide: nous rechargions le buffer à envoyer au shader avant de dessiner chaque objet (même si par la suite on dessinait un objet en utilisant le même mesh, et donc en chargeant les mêmes données dans le buffer). J'ai donc essayer d'envisager divers moyens pour optimiser ça.
On en arrive donc à ma question: vaut-il mieux charger, une seule fois, au début du programme, tous les mesh dans un seul buffer et ainsi éviter de recharger le buffer à chaque fois qu'on change de mesh (et en utilisant les indices de départ - appelés "Base Index" sur le site d'openGL- pour dessiner), où est-ce que ça risque de trop surcharger la mémoire?

Merci d'avance de votre réponse.

PS: en vérité la question posée est plutôt: quel est le coût réel des fonctions OpenGL qui gèrent la transmission de données au shader et leur utilisation? Par exemple, je me suis dis qu'il valait mieux utiliser plusieurs programmes shaders et les charger dans le pipeline avec glUseProgram plutôt que de mettre pleins de conditions et de variables uniformes dans le code GLSL, mais est-ce vraiment le cas?

PS bis: il va sans dire que je parles ici des versions d'OpenGL postérieures à la version 3.0

[LittleWhite]

Bonjour,

L'idée c'est de charger les modèles (création des buffers / transfert données sur le GPU) au chargement d'un niveau (ou d'une scène). Si vous avez qu'une scène vous chargez tout, sans trop réfléchir (sauf si vous essayez d'afficher une très très grande zone avec trop d'objets qui diffèrent).
Si un objet apparait deux fois dans une scène, il ne doit y avoir qu'un seul buffer (qui sera donc utiliser deux fois).

Le second conseil, c'est d'éviter les changements d'états. Plus précisément, c'est faire le moins de bind (shaders / buffer / ...) possible. Pour cela, il faut organiser sa scène dans un arbre hiérarchique et le trier afin d'éviter le plus possible les changements.

Les shaders, je pense qu'il faille tous les charger / compiler au début du programme. Cela n'a pas un gros impact en mémoire.

Pour connaître les différentes parties qui vous ralentisse, il faut utiliser un profiler : gDEBugger ou NVIDIA PerfHUD. On ne peut pas dire quelles fonctions coutent plus ou moins (même si on peut le deviner), sachant que cela dépend en grande partie des pilotes. Toutefois, il arrive souvent que ce soit les transferts CPU -> GPU qui ralentisse tout le pipeline (je dis bien, généralement).

[bactria]

Merci de votre réponse.

Je vais m'intéresser aux profiler de plus prêt.