Discussion :

[Yno]

Bonjour,

Ayant eu un peu de mal avec le titre, je vais essayer de détailler plus clairement mon problème.

Pour commencer, il me semble savoir que les shaders ASM ne s'utilisent pas de la même façon que les shaders GLSL (appels de fonctions différents), déjà là, corrigez-moi immédiatement si j'ai tors, car toute la suite du problème repose là dessus.

Avec les objets de shaders ASM, il est possible de faire :

glBindProgramARB(VERTEX/FRAGMENT, ...);

Et le type du shader a utiliser est specifié explicitement lors du binding.

Avec les fonctions de manipulation des shaders GLSL, il faut regrouper deux shaders dans un program (glAttachShader) puis utiliser ensuite ce program.

L'avantage des shaders ASM (côté API) est que l'on peut changer de fragment program sans avoir à "débinder" le vertex program, comme cela :

Code :

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

1
2
3
4
5
6
7
8
9
glBindProgram(GL_VERTEX, a);
glBindProgram(GL_FRAGMENT, b);
 
/* utilisation ... */
 
/* changement du fragment program */
glBindProgram(GL_FRAGMENT, c);
 
/* utilisation ... */

(toujours pareil, si j'ai tors dîtes-le moi)

C'est plutôt pratique.
Avec des shaders GLSL, je ne connais aucune méthode pour faire cela aussi "facilement", à part celle-ci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/* creation */
p = glCreateProgram();
 
/* 'attachement' */
glAttachShader(p, vs);
glAttachShader(p, ps);
 
/* liaison */
glLinkProgram(p);
 
glUseProgram(p);
 
/* utilisation ... */
 
/* glDetach ps ? ... */
glAttachShader(p, ps2);
glLinkProgram(p);
 
glUseProgram(p);
 
/* utilisation ... */

Et dans ce cas, je me demandais si les appels à glAttach* et glLink* n'étaient pas un peu trop "gourmands" par rapport au simple glBind pour les shaders ASM ?
De plus, glLink peut retourner une erreur, et il faut donc prendre en compte la gestion de la valeur de retour.

Merci bien

[shenron666]

si j'ai bien compris, tu n'as pas de problème, juste des interrogations au sujet des shaders asm et glsl

perso je te déconseille les shaders asm, toutes les instructions ne sont pas compatibles, il faut une version pour ati, une pour nvidia et voire même pour les différentes générations de puces

si ta carte supporte le glsl, fonce, éventuellement il y a cg
mais l'asm n'a que peu d'intérêt

au sujet des fonctions GLSL, sauf erreur de ma part :
- tu utilises glAttachShader et glLinkProgram au début de ton programme pour compiler tes shaders (équivalent à la création d'une texture)
- glUseProgram pendant le traitement d'image pour sélectionner ton shader (équivalent au bind d'une texture)
- glDetachShader en fin de programme pour déchargement le shader (équivalent à la destruction d'une texture)

tu peux lire le tutorial sur lighthouse (en anglais) :
http://www.lighthouse3d.com/opengl/glsl/index.php
la page suivante parle justement de ce que je t'explique :
http://www.lighthouse3d.com/opengl/g...php?oglprogram

[Laurent Gomila]

Le "problème" avec GLSL c'est que tu peux déclarer des variables globales au vertex shader et au pixel shader. C'est pour ça qu'il faut une phase d'édition de liens.

C'est vrai que c'est emmerdant si tu veux juste changer l'un des deux, je sais pas trop si c'est possible sans refaire l'édition de liens (et je ne sais pas si cette dernière est coûteuse -- enfin je pense que oui).

[shenron666]

en fait en GLSL tu utilises glAttachShader pour attacher un "vertex shader" et un "fragment shader" à un "program shader" que tu link
tu peux attacher le même "vertex shader" avec un autre "fragment shader" à un autre "program shader" et refaire un link pour obtenir donc un second "program shader"
tout ça c'est dans l'initialisation (faut juste faire gaffe à la limite de "program shader" qui peuvent être linkés dans les drivers)

après dans la boucle de rendu, il n'y a "que" des appels à glUseProgram
?que? sauf si tu veux utiliser plus de "program shaders" que la carte n'autorise en mémoire en même temps
d'ailleurs je me demande quelles sont les limites des cartes genre radeon 9500 assez courantes aujourd'hui et qui supportent le GLSL

[Yno]

Merci à vous deux pour vos réponses

Le "problème" avec GLSL c'est que tu peux déclarer des variables globales au vertex shader et au pixel shader. C'est pour ça qu'il faut une phase d'édition de liens.

C'est vrai que c'est emmerdant si tu veux juste changer l'un des deux, je sais pas trop si c'est possible sans refaire l'édition de liens (et je ne sais pas si cette dernière est coûteuse -- enfin je pense que oui).

C'est la réponse que j'attendais (enfin plus ou moins, mais au moins on me confirme que pour changer juste un type de shader GLSL je suis effectivement dans le caca )

J'ai un livre sur OpenGL, et l'utilisation des shaders GLSL n'est pas un problème pour moi (je les utilise couramment sans aucun problème), mais merci quand même pour tes liens shenron666

En revanche les incompatibilités dont tu me fait part à propos des shaders ASM, je n'en étais pas au courant, voilà qui a de quoi diminuer mes intentions de les utiliser.

En fait, pour expliquer pour clairement mon véritable problème, j'essaie de programmer une interface de gestion de shaders quelconques.
Disons qu'il suffira de specifier le type du shader, et ensuite les fonctions d'utilisation seraient les mêmes, quelque soit le type.
Avez-vous des suggestions et/ou des conseils à ce sujet ?

J'ai également une autre question, au sujet des attributs de vertex.
Pour GLSL, c'est simple, on récupère l'ID d'un attribut, puis on le donne à manger à glVertexAttribPointer().
Mais pour les shaders ASM ?
Même question pour Cg, car je compte l'intégrer également.

J'ai d'ailleurs vu sur la doc de ce dernier que Cg proposait à l'utilisateur d'envoyer des tableaux aux shaders, mais son utilisation est différente de celle des glVertexAttribPointer (utilisation de fonctions Cg pour envoyer les donnees), je me demandais donc si on était obligé de passer par les fonctions de Cg pour envoyer des attributs de vertex ? Et si c'est le cas, peut-on bénéficier des VBOs ? (comme c'est le cas avec glVertexAttribPointer())

Encore merci

Bonne soirée.

[Laurent Gomila]

Pourquoi faire un truc générique qui gère Cg, alors que Cg est déjà générique ? C'est juste pour gérer aussi GLSL ?

En tout cas si tu veux tu peux t'inspirer du code de Ogre, il me semblent qu'ils gèrent aussi tout type de shaders.

[Yno]

Bonsoir,

Pourquoi faire un truc générique qui gère Cg, alors que Cg est déjà générique ? C'est juste pour gérer aussi GLSL ?

Disons que je ne sais pas avec exactitude comment fonctionne Cg
Mais si il ne gère pas GLSL, ce que tu laisses sous-entendre et ce que j'ai toujours pensé, alors oui, c'est juste pour gérer GLSL.

En tout cas si tu veux tu peux t'inspirer du code de Ogre, il me semblent qu'ils gèrent aussi tout type de shaders.

J'irai jeter un coup d'oeil

Merci.

[bafman]

le CG gere le GLSL depuis la version 1.5, et les shader ASM sont tout aussi compatible entre eux que les shader GLSL, le tout etant de ne pas utiliser d'extension proprietaires

[Yno]

Merci pour cette réponse

le CG gere le GLSL depuis la version 1.5

Surgissent alors plusieurs questions

Il gère le langage uniquement, ou bien il crée réelement un shader GLSL ? (je sais pas si ma phrase a un sens)
Si il gère le GLSL aussi bien qu'OpenGL, comment se fait-ce que l'on pourrait également à priori, comme je l'ai dit au début, changer de vertex/pixel shader à volonté, sans avoir à changer ou à re-relier tout le program en entier ? Cg fait-il une pseudo-émulation ?
Pour finir, Cg fonctionne-il correctement sur les cartes ATI, ou bien présente-il, comme on me l'a rapporté, quelques incompatibilités ?

Merci.

[bafman]

a priori (je ne suis as un expert du CG), il va te generer un shader GLSL. pour tout ce qui est du link et autre, je n'en sait rien

[shenron666]

Si il gère le GLSL aussi bien qu'OpenGL, comment se fait-ce que l'on pourrait également à priori, comme je l'ai dit au début, changer de vertex/pixel shader à volonté, sans avoir à changer ou à re-relier tout le program en entier ? Cg fait-il une pseudo-émulation ?

Je pense que tu n'a pas compris, changer de shader ne reviens pas à le recompiler où à le relier mais juste à le sélectionner avec glUseProgram

compiler et lier les "programs" se fait à l'initialisation, pas pendant le rendu

[Laurent Gomila]

Je pense que tu n'a pas compris, changer de shader ne reviens pas à le recompiler où à le relier mais juste à le sélectionner avec glUseProgram

Relis les premiers messages : la problèmatique de base c'est de savoir comment changer de vertex / pixel shader dans un même programme

Perso j'ai aucune idée de la manière dont Cg gère ça

[Yno]

Relis les premiers messages : la problèmatique de base c'est de savoir comment changer de vertex / pixel shader dans un même programme

Effectivement

pour tout ce qui est du link et autre, je n'en sait rien

Perso j'ai aucune idée de la manière dont Cg gère ça

Moi non plus, je vois que le fonctionnement de Cg est un mystère.

Et vu qu'apparemment il n'a pas l'air Opensource (d'où les mystères), je ne peux même pas aller jeter un oeil aux sources.
Bah en même temps, le fait qu'il ne soit pas opensource me fait une bonne excuse pour ne pas l'utiliser (+ pas top avec ATI, paraît-il)

Je m'en passerai pour le moment, je découvrirai probablement au fil du temps comment il fonctionne réellement, et alors il me sera aisé de l'implémenter.

Merci à tous pour votre aide
Je passe le sujet en résolu.

Bonne fin de soirée.

[shenron666]

Relis les premiers messages : la problèmatique de base c'est de savoir comment changer de vertex / pixel shader dans un même programme

ah d'accord
mais en GLSL, avec 1 vertex shader et 15 fragment shader, on peut faire 15 programmes qui utilisent tous les même vertex shader et chacun le même fragment shader
ça ne résoud pas le problème ?
bon il est tard et si je suis encore dans le mur je relirai le post depuis le début

[Laurent Gomila]

Ben le problème, c'est qu'on ne connaît pas toujours à l'avance tous les couples de shader que l'on va utiliser.

Et puis ça nécessite de connaître le vertex / pixel shader bindé, pour savoir quel programme utiliser pour garder le même.

Et puis ça peut faire beaucoup de combinaisons...

[shenron666]

c'est vrai qu'il peut arriver qu'un program n'existe pas et qu'il faille le compiler / linker
mais c'est un peu le même problème que les textures et les matériaux, il faut un gestionnaire de shaders

une question en passant, je n'ai pas trouvé comment connaitre le nombre maximum de programmes que la carte peut mémoriser simultanément ?

[Laurent Gomila]

J'imagine que comme n'importe quelle ressource, tu n'es limité que par la mémoire vidéo.

[bafman]

J'imagine que comme n'importe quelle ressource, tu n'es limité que par la mémoire vidéo.

ha bah non alors... ca depend des veleurs que te retourne les glGet(MAX_MACHIN_CHOSE) et c'est donc competement dependant de l'implementation OpenGL et en plus, le driver peut très bien stocker des informations en memoire central sans te le dire...
donc le meilleur moyen de savoir quel get faire, c'est de se tapper le document de definition de l'extension

[Laurent Gomila]

Bah... La limite imposée par le driver doit être suffisamment élevée pour qu'on n'ait pas à s'en soucier, non ? Je veux dire c'est pas comme le nombre d'unités de textures, ou n'importe quoi d'autre qui serait limité par l'architecture du GPU.

[bafman]

justement, sur far cry, ils ont été obligé de mettre en place un système de cache de shaders car ils atteignait la limite des cartes graphiques de l'époque si ils chargeait tout en même temps, c'est donc que la limite n'est pas si élevée que ça