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

61

Quels sont les avantages / inconvénients des trois?

Z_guy
la source
2
Il semble que vous deviez d’abord choisir l’API que vous recherchiez (OGL ou DX) et les plates-formes avant de décider du langage shader.
Tetrad
1
Je pense que cette question est brillante. Que diriez-vous d'un wiki de la communauté? Je suis nouveau dans tout cela et une question de différences par rapport aux shaders est exactement ce que je dois savoir.
Mladen Mihajlovic
3
Correction: "fermé comme non constructif" devrait dire "fermé comme constituant une violation de la politique du témoin", parce que CELA est constructif.
Lennart Rolland

Réponses:

42

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.

Klaim
la source
2
Oui . NVIDIA ne semble pas se soucier des problèmes avec les cartes ATI.
bobobobo
4
"OpenGL semble être un peu plus lent que DirectX sur les plates-formes Windows." Dans la plupart des cas, cela est généralement dû au fait que le support des constructeurs pour les pilotes avec OpenGL n’est pas aussi performant sous Windows que sous DirectX.
ChrisC
1
Remarque: J'ai finalement choisi OpenGL / GLSL en raison d'améliorations récentes et de la nécessité de m'assurer que mon jeu fonctionne sur des tablettes non-MS.
Klaim
2
@Community: Avez-vous des liens pour l’interruption du soutien au Cg?
Nicol Bolas
15

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.

bobobobo
la source
10

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).

coderanger
la source
+1 C'est ce que je comprends aussi. Personnellement, j'aime utiliser cg chaque fois que je peux, mais cela ajoute une dépendance supplémentaire au-delà du système de rendu lui-même; et je semble me souvenir d’avoir eu quelques problèmes étranges avec les pilotes OpenGL, cg et ATI avec des effets plus complexes ...
Riley Adams
J'utilise Ogre et j'ai donc les trois à ma disposition, mais si je veux avoir à la fois DirectX et OpenGL, je dois écrire les shaders à la fois en HLSL et GLSL ou tout simplement en cg? Est-ce correct?
Z_guy
14
-1. C'est une réponse extrêmement rudimentaire et on espère trouver des informations plus complètes sur ce site.
Bobobobo
2
-1: Je suis d'accord avec bobobobo.
Nicol Bolas
1
Malheureusement, je dois -1 pour les mêmes raisons que bobobobo.
Jonathan Dickinson
8

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.

Maximus Minimus
la source
1
Pour être juste, le compilateur GLSL de NVIDIA est devenu un peu plus strict sur ce qu’il accepte et n’accepte plus depuis ces jours. Mais même aujourd’hui, il existe ce que j’appelle des "pièges NVIDIA" qui facilitent la réalisation de tâches qui, à votre avis, devraient fonctionner, mais qui ne sont pas conformes aux spécifications et aux pilotes AMD.
Nicol Bolas
J'irais même jusqu'à dire que le développement d'ATI / AMD, ou à tout le moins le recoupement avec ATI / AMD, est toujours une nécessité absolue. Vous obtenez deux victimes pour le prix d'une, car vous attraperez également des bogues dans leur pilote OpenGL.
Maximus Minimus
Lorsque vous ciblez des implémentations Vulkan ou OpenGL prenant en charge SPIR-V, les shaders GLSL peuvent être précompilés dans SPIR-V.
Andrea
@Andrea - oui, c'est correct; De toute évidence, ni Vulkan ni SPIR-V n'existaient au moment où la question a été posée (et la réponse a été écrite).
Maximus Minimus
1

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.

utilisateur24721
la source
1

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.

Aidan Knight
la source