Version imprimable
Bonjour,
Cg génère du code en assembleur qui est ensuite envoyé à l'API (openGL ou DirectX).
DirectX utilise D3DX pour créer un code assembleur binaire qui est envoyé au driver.
1. Je ne comprends pas, par contre, comment openGL gère ce code assembleur.
2. GLSL est-il compilé à l'execution ou offline?
Je ne suis pas du tout sur de ce que j'avance mais j'essaye de bien comprendre les différents langages de shaders. Merci beaucoup pour votre aide.
1. Il faut te taper l'implémentation des différents profils OpenGL à la main. Et ce n'est pas du gâteau... Tu peux consulter les sources du moteur 3D OGRE, ils font ce genre de chose.
2. A l'execution.
Tu peux aussi aller lire ce tutoriel :
http://loulou.developpez.com/tutorie...eur3d/partie8/
2. Si la compilation ne s'effectue qu'à l'execution avec GLSL alors que avec HLSL elle peut être fait soit à l'execution soit offline, cela signifie que tous les shaders GLSL doivent avoir leurs sources dispo, c'est un énorme inconvénients , non? HLSL permet de cacher ces sources et dans l'industrie c'est primodial.
Cg génère un code assembleur et fonctionne donc comme une couche supplémentaire un peu comme un compilateur GLSL qui compile et qui envoie au "vertex/fragment program" le code compilé alors que GLSL c'est du code haut niveau que les drivers de la carte vont compiler
Je pense que comme GLSL, ce sont les drivers spécifiques à la carte/constructeur qui se chargent de la compilationCitation:
DirectX utilise D3DX pour créer un code assembleur binaire qui est envoyé au driver
lol, tu les cache pas tant que cela, il y a toujours moyen de les retrouverCitation:
Envoyé par chonos
tu peux aussi cacher tes sources GLSL, tu peux très bien les compresser et/ou crypter dans une grosse archive si tu veux, au final et comme HLSL il y aura toujours moyen de les récupérer à l'exécution par exemple
pour GLSL je suis d'accord mais HLSL la compilation ne s'effectue pas dans le driver mais au niveau de la bibliothèque D3DX et c'est le code assembleur binaire qui est envoyé au driver.Citation:
Je pense que comme GLSL, ce sont les drivers spécifiques à la carte/constructeur qui se chargent de la compilation
J'ai toutefois une autre question. Apparement il est possible de désassembler un code grace au compilateur en ligne fxc pour une cible de compilation choisie.
Cela signifie t-il que à partir du code assembleur binaire on peut retrouver le code source??
on peut toujours retrouver le code source, que ce soit pour un exe standard ou pour un shader... le tout c'est de le comprendre apres... avoir un shader sans savoir quelle texture sert a quoi, quel sont les parametres envoyé et autre, ca n'avance pas a grand chose... chouette ici il fait un produit scalaire... vraiment interessant :wink:
Je me suis mal exprimé. Je voudrais savoir qu'est ce qu'il faut mettre en entrée au compilateur fxc ( de l'assembleur binaire? )Citation:
J'ai toutefois une autre question. Apparement il est possible de désassembler un code grace au compilateur en ligne fxc pour une cible de compilation choisie.
Cela signifie t-il que à partir du code assembleur binaire on peut retrouver le code source??
et qu'est ce qu'on obtient en sortie (le code source HLSL? de l'assembleur?)
Et la bibliothèque D3DX ne fait pas appel au driver pour la compilation ?Citation:
Envoyé par chonos
J'en doute fortement, rien que Ati et nVidia n'ont pas à 100% les mêmes instructions pour les shaders, et d'une carte à l'autre l'instruction peut être gérée en hardware ou en software
pourquoi le compilateur GLSL est-il justement intégré aux drivers à ton avis ?
Attention, je ne dis pas que tu as tords, c'est peut-etre moi qui ne connais pas le processus HLSL mais si tu as une source sure pour appuyer ce que tu dis, cela m'intéresse, au moins pour améliorer ma culture DirectX :wink:
De ce que j'ai compris, deux moyen de compiler:
-à l'execution : par la bibliothèque D3DX qui va examiner la machine cliente dans quel cas je suppose que effectivement elle va regarder le driver de la carte ( si quelqu'un peut confirmer ceci !!) et déduire un compile target approprié
-offline : au développer de choisir un compile target et là on ne regarde pas la machine cliente. d'où ma question pour le désassemblage.
Je ne comprends rien à ce desassemblage alors si quelqu'un peut m'aider.
Ce que j'avance n'est que le fruit de mes lectures et peut tres bien etre faux. en tout cas merci a toi pour ton aide et tes questions qui me font reflechir et progresser
a priori, pour Dx, c'est uniquement la lib qui effectue la compilation, c'est pour cela qu'il sont obligé de sortir une nouvelle version a chaque ajout d'instruction pour les shaders (par exemple pour la sortie des gforce6, ils on ajouté un profile SM3.0 avec Dx9c)
c'est d'ailleurs pour cela que la solution openGL est potentiellement plus interessante, car c'est uniquement le driver qui prend cela en charge. Mais par contre on rencontre des problemes entre les differents constructeurs (nombre d'indirection de textures limitée sur ATI... oui c'est naze :lol: )
bref chaque solution a ses aventages et ses inconvenient dans ce domain :
- Dx a l'aventage d'etre unifiée : ca marche pareil sur toutes les cartes mais c'est plus difficilement optimisable
- openGL a l'aventage d'etre potentiellement plus optimal, mais du coup la compatibilitée entre carte n'est pas garantie...
Ok!! merci pour l'info :wink:Citation:
Envoyé par bafman
Que de problème avec Ati, rien qu'à l'installation de nouveaux drivers, mise à jour donc, il faut que j'allume la télé (sur laquelle la carte est branchée en permanence) pour pouvoir réactiver mon affichage -__-Citation:
Envoyé par bafman
Plus en rapport avec OpenGL : J'avais développé une petite GUI qui dessinait des LINE_LOOP et il manquait un pixel dans le coin sur ati...
pas grand chose des fois mais pleins de petits problèmes plus ou moins importants qui s'accumulent et qui font que j'ai bien envie de changer de carte :evil:
Ne pas hésiter à leur envoyer un mail dans ce cas, plus on sera à leur dire qu'on a des problèmes plus de chance on aura de les faire bouger