Quels sont les avantages et les inconvénients de HLSL vs GLSL vs cg? [fermé]

Quels sont les avantages / inconvénients des trois?

coderanger a raison de dire que HLSL cible DirectX, GLSL OpenGL et CG sont disponibles avec les deux interfaces.

Cependant, il y a d'autres choses à considérer (appris sur le forum OGRE):

• CG ne vous permettra pas d'utiliser les dernières fonctionnalités de GLSL (je ne suis pas sûr de HLSL). C'est un terrain d'entente, vous ne pourrez donc pas exploiter pleinement les fonctionnalités du GLSL, seulement les plus communes jusqu'à ce que Shader Model 3.0 (AFAI compris).
• Les images générées par NVidia sont optimisées pour la carte, mais ne semblent pas beaucoup fonctionner pour les cartes ATI. Certaines personnes signalent qu'il pourrait y avoir des problèmes avec les cartes ATI utilisant la CG.
• OpenGL semble être un peu plus lent que DirectX sur les plates-formes Windows. Cela dépend vraiment de ce que vous faites et de la raison pour laquelle il trouve son source dans les implémentations des pilotes, mais il est bon de le savoir avant de choisir l'API et le langage de shader associé. Cependant, OpenGL est la seule interface disponible sur toutes les plateformes (Win / Mac / Unix / certaines consoles). Donc, sachant que l’utilisation exclusive de GLSL pourrait être le meilleur choix pour un jeu multiplateforme non centré sur Microsft.
• Les pilotes NVidia sous Linux semblent être plus stables que les pilotes ATI, ce qui rend le CG plus intéressant si vous voulez être sûr que tout fonctionne correctement sur Linux (c'est toutes les informations rapportées, vous devrez vérifier les détails).

Ainsi, si vous n'utilisez pas les dernières fonctionnalités de shader, la CG semble être un bon choix. GLSL semble un meilleur choix si vous allez à plein OpenGL. HLSL si vous allez exclusivement sur les plates-formes Microsoft.

Développer d’abord en HLSL pour Windows pour utiliser DirectX puis pour convertir en GLSL pour Linux et mac pourrait être la meilleure solution pour être sûr des performances et disposer du plus grand ensemble de fonctionnalités de shader. Cela pourrait cependant être beaucoup de travail (je ne l’ai pas fait moi-même, donc je ne peux pas le dire). Le moteur graphique OGRE (et d’autres moteurs) permet d’utiliser toutes les API (DirectX, OpenGL ou autres), donc cela aide, mais il reste du code shader à convertir si vous procédez ainsi.

C’est toute l’information que j’ai recueillie en choisissant ma langue de shader (je n’ai pas encore pris ma décision).

Mise à jour: Valve a converti l'un de ses jeux en OpenGL et n'a trouvé aucun moyen de rendre la version DirectX plus rapide que la version OGL . Gardez donc à l'esprit que l'état de mise en œuvre du pilote, la qualité de l'API, etc., changent trop chaque année pour que vous puissiez totalement compter sur les performances brutes comme argument pour choisir l'un ou l'autre. Dans cet esprit, choisissez OpenGL / GLSL pour vous simplifier la vie lorsque vous travaillez (ou avez des projets ou espère travailler) avec d’autres plates-formes que Windows, utilisez DirectX / HLSL si vous voulez vraiment utiliser uniquement les plates-formes Microsoft et concentrez-vous et possédez peut-être de bonnes API plus rapide qu'OpenGL (c'est en train de s'inverser, alors ne comptez pas dessus); utilisez CG si vous voulez offrir les deux possibilités à l'utilisateur, mais si vous avez la main-d'œuvre (et les outils) pour le faire, utiliser à la fois GLSL et HLSL pourrait également être une solution viable.

Mise à jour (2012): Il est important de noter que la synthèse d'images a été arrêtée et que Nvidia ne prend plus en charge ni ne travaille activement à cette tâche. Nvidia recommande à tous les utilisateurs d’utiliser une combinaison de GLSL et HLSL, ou une bibliothèque plus récente telle que nvFX (sur github). En effet, il était trop difficile de maintenir la compatibilité des fonctionnalités entre GLSL et HLSL.

Je ne peux parler que de CG vs HLSL parce que ce sont les 2 que j'ai utilisés jusqu'à présent.

Cg n'est pas la même chose que HLSL.

En Cg, NVIDIA a fait un excellent travail en créant une syntaxe de shader très claire. C'est très similaire à HLSL.

Cependant , la liaison avec D3D9 / D3D11 (code d’initialisation, code de compilation de shader) est beaucoup plus propre sur HLSL que sur Cg. -1 Cg. Cg a un peu de code de démarrage que vous n’avez même pas besoin d’avoir pour HLSL sur D3D.

En Cg, vous devez "cgGetNamedParameter" pour chaque uniform variable de shader que vous souhaitez définir / modifier. Et vous devez maintenir une CGparameterréférence dans votre code pour cette variable

// C++ code to interact with Cg shader variable (shader language independent)
CGparameter mvp = cgGetNamedParameter( vs, "modelViewProj" ); 
CG::getLastError("Getting modelViewProj parameter");  // check for errors
cgSetMatrixParameterdr( mvp, &modelViewProj._11 ) ;   // setting the matrix values

En HLSL, cela finit par être beaucoup plus propre - une seule ligne, et vous n'avez pas à conserver cette CGparametervariable.

// D3D9 C++ code to interact with HLSL shader variable
DX_CHECK( id3dxEffect->SetMatrix("modelViewProj", &mvp._11 ), "Set matrix" ) ;

Dans ce qui précède, DX_CHECKn’est qu’une simple fonction qui vérifie le HRESULT renvoyé par l’ SetMatrixappel. Le code ci-dessus est d3d9 . Les versions D3D10 et 11 sont bien sûr beaucoup plus pénibles (car il n’existe pas d’objet ID3DX11Effect).

Avant de commencer à utiliser HLSL, je regardais ce code et devenais jaloux .

Bien que NVIDIA fait de leur mieux pour faire une interface commune pour Seizième entre OpenGL / D3D, en pratique son pas de cette façon, et vous avez cgGL*, cgD3D9, cgD3D10,cgD3D11 groupes de fonctions à combattre. Donc tout cela fonctionne pour OpenGL et D3D !! revendication ne va que jusqu'à présent. Vous devez encore tout regrouper dans des #ifdefgroupes de type OpenGL / D3D pour le faire fonctionner sur différentes plates-formes. -2 Cg.

De plus, j'ai récemment eu une mauvaise expérience avec les cartes Cg / ATI, ce qui, j'en suis sûr, n'est pas ma mauvaise. (Quelqu'un d'autre l'essayer?). Je pense que c'est peut-être vrai que NVIDIA ne teste pas complètement les cartes ATI, comme le prétend Klaim. Ou qu'ATI ne teste pas sur Cg. D'une manière ou d'une autre, il y a une inadéquation et une sorte de conflit d'intérêts. -3 Cg.

Dans l'ensemble, j'ai préféré le Cg. La syntaxe et la dénomination de son code de shader sont propres, simples et ordonnées. C'est dommage que ces problèmes soient résolus.

Ma compréhension fondamentale est que HLSL est uniquement pour DirectX et GLSL est uniquement pour OpenGL. Cg est fondamentalement le même langage que HLSL, mais peut être utilisé avec DirectX ou OpenGL (via un code d'exécution différent).

Une autre différence cruciale entre HLSL et GLSL (je ne connais pas le CG, donc je ne peux pas en parler) réside dans le fait qu’avec HLSL, Microsoft fournit le compilateur de shader dans le cadre de l’exécution D3D, tandis que dans GLSL, votre fournisseur de matériel le fournit dans le même chauffeur.

Cela présente des avantages et des inconvénients des deux côtés.

Avec la méthode GLSL, le fournisseur peut adapter le compilateur aux capacités de son matériel. Ils connaissent mieux leur propre matériel, ils savent quoi faire et ne pas faire. D'un autre côté, l'inconvénient est que, dans un monde où il y a plusieurs fournisseurs de matériel, il peut y avoir des incohérences entre les compilateurs de shader, et que le fournisseur a également tout loisir de tout gâcher.

Avec la méthode HLSL, Microsoft contrôle le compilateur. Tout le monde est sur une base technologique cohérente, et si un shader compile avec succès à un endroit donné, il peut raisonnablement être supposé compiler partout. Le même shader produira le même résultat compilé, quel que soit le fournisseur (toutes choses égales par ailleurs). D'autre part, le compilateur HLSL doit être un outil "fonctionne de manière cohérente pour tout", de sorte qu'il ne peut pas tirer d'astuces spéciales propres au fournisseur pour extraire les dernières gouttes de jus du réservoir.

Si cela me semble avoir une préférence pour la vision du monde HLSL, c'est parce que je le fais. Un comportement extrêmement incohérent sur différentes plates-formes m'a mordu dans le passé. Dans un cas, il a même fallu renvoyer une charge de GLSL dans ARB ASM uniquement pour obtenir une base de référence qui fonctionne. Le compilateur GLSL de NVIDIA peut être considéré comme particulièrement notoire ici - il acceptera même la syntaxe et les mots-clés HLSL, ce qui signifie que si vous ne faites pas attention, vous pouvez produire des shaders qui ne fonctionneront que sur NVIDIA. C'est une jungle là-bas.

J'ai utilisé les deux, j'ai commencé avec glsl et je suis passé à hlsl uniquement parce que le projet l'exige. Étant donné le choix, c'est glsl tout le chemin. glsl est très lisse et a l’air d’être sorti du banc de passe-temps d’un ingénieur.

Vous voudrez peut-être aussi regarder dans le RTSS (Run Time Shader System) fourni avec Ogre. C'est assez nouveau, mais vous écrivez essentiellement des shaders dans le code plutôt que dans des fichiers externes. Je ne l’ai pas encore implémenté, mais j’ai l’intention de l’utiliser le moment venu.

Voici une énorme série de tutoriels sur le wiki Ogre, ainsi que pour l’écriture de shaders. http://www.ogre3d.org/tikiwiki/JaJDoo+Shader+Guide

En ce qui concerne votre question initiale, comme Praetor l'a dit, ce n'est pas vraiment une question de pour / contre, c'est une question de savoir quel système de rendu vous allez utiliser. Comme utiliser DX / OpenGL avec Ogre est juste une question de chargement du plugin, vous voudrez probablement utiliser le format .cg.