In HLSL muss ich Semantik verwenden, um Informationen von einem Vertex-Shader an einen Fragment-Shader weiterzuleiten. In GLSL wird keine Semantik benötigt. Was ist ein objektiver Vorteil der Semantik?
Beispiel: GLSL
Vertex-Shader
%Vor%Fragment-Shader
%Vor%Beispiel: HLSL
Vertex-Shader
%Vor%Pixelshader
%Vor% Ich sehe, wie foo und bar in VS_OUTPUT im Fragment-Shader mit foo und bar in main verbunden werden. Was ich nicht verstehe, ist, warum ich die Semantik manuell auswählen muss, um die Daten zu übertragen. Warum kann DirectX, wie GLSL, nicht herausfinden, wo die Daten gespeichert werden, und es verbinden, wenn die Shader verlinkt werden?
Gibt es einen konkreteren Vorteil für die manuelle Festlegung der Semantik oder ist es nur übrig von Assembler Shadern Tagen? Gibt es einen Geschwindigkeitsvorteil bei der Wahl von TEXCOORD4 über COLOR2 oder BINORMAL1?
Ich verstehe, dass Semantik eine Bedeutung haben kann, es gibt keine Bedeutung für foo oder bar , aber sie können auch Bedeutungen verschleiern, wenn foo kein TEXCOORD ist und bar keine Farbe ist. Wir setzen keine Semantik auf C # - oder C ++ - oder JavaScript-Variablen, warum werden sie für HLSL benötigt?
Einfach, (alt) glsl hat dies für die Benennung von Variablen verwendet (bitte beachten Sie, dass das Variieren nun veraltet ist).
Ein offensichtlicher Vorteil der Semantik: Sie benötigen nicht die gleichen Variablennamen zwischen den Stufen, daher führt die DirectX-Pipeline die Übereinstimmung über Semantik statt Variablennamen durch und ordnet die Daten neu, solange Sie ein kompatibles Layout haben.
Wenn du foo durch foo2 umbenennst, musst du diese Namen in möglicherweise all deinen Shadern (und eventuell nachfolgenden) ersetzen. Mit Semantik brauchen Sie das nicht.
Da Sie auch keine exakte Übereinstimmung benötigen, können Sie die Shader-Stufen leichter trennen.
Zum Beispiel:
Sie können einen Vertex-Shader wie folgt haben:
%Vor%Und ein Pixelshader wie folgt:
%Vor%Da der Vertex-Shader-Ausgang alle Eingänge bereitstellt, die der Pixel-Shader benötigt, ist dies absolut gültig. Normale werden ignoriert und Ihrem Pixelshader nicht zur Verfügung gestellt.
Aber dann können Sie zu einem neuen Pixelshader wechseln, der möglicherweise Normalen benötigt, ohne dass eine andere Vertex Shader-Implementierung erforderlich ist. Sie können auch nur den PixelShader austauschen und somit einige API-Aufrufe speichern ( Separate Shader-Objekte Erweiterung ist die OpenGL-Entsprechung).
In gewisser Weise bietet die Semantik Ihnen also die Möglichkeit, In / Out zwischen Ihren Phasen zu kapseln, und da Sie auf andere Sprachen verweisen, wäre das ein Äquivalent zur Verwendung von Eigenschaften / Setter / Zeigeradressen ...
Schnell gibt es keinen Unterschied in Abhängigkeit von der Benennung (Sie können die Semantik so ziemlich beliebig benennen, außer natürlich für System). Unterschiedliche Layout-Positionen bedeuten einen Treffer tho (die Pipeline wird sich für Sie neu organisieren, wird aber auch eine Warnung ausgeben, zumindest in DirectX).
OpenGL bietet auch einen Layout-Qualifier , der ungefähr gleichwertig ist (technisch ist er etwas anders, folgt aber mehr) oder weniger das gleiche Konzept).
Ich hoffe, das hilft.
Wie Catflier oben erwähnt hat, kann die Verwendung von Semantiken helfen, die Shader zu entkoppeln.
Allerdings gibt es einige Nachteile der Semantik, die ich mir vorstellen kann:
Die Anzahl der Semantiken ist durch die von Ihnen verwendete DirectX-Version begrenzt, sodass sie möglicherweise nicht mehr ausreicht.
Der Name der Semantik ist ein wenig irreführend. Sie werden diese Art von Variablen sehr oft sehen (siehe posWorld-Variable):
struct v2f {
float4 position : POSITION;
float4 posWorld : TEXCOORD0;
}
Sie werden sehen, dass die posWorld-Variable und die TEXCOORD0-Semantik überhaupt nicht relevant sind. Aber es ist in Ordnung, weil wir die Texturkoordinate nicht an TEXCOORD0 übergeben müssen. Dies führt jedoch wahrscheinlich zu Verwirrungen zwischen denjenigen, die nur die Shader-Sprache auswählen.