ZFX + Developia

Hi,

so langsam komme ich in den Bereich, dass die ganzen lustigen Shader immer komplexer werden. Jeden freut das.

Jedoch frage ich mich ein wenig wie ich den Code managen soll. Wenn ich für unterschiedliche Materialien unterschiedliche Dateien nutze, dann gibt es immer Mal wieder Funktionen, die eben von mehreren gebraucht werden. Wenn ich den Code nicht doppelt und dreifach schreiben will, muss ich alles in eine einzige Datei kloppen. Kann man in Shadersprachen andere Dateien inkludieren? include-Schlüsselwort scheint es nicht zu geben.

Wie macht ihr das?

In gwX haben wir einen Shadermanager, der automatisch anhand der Materialeigenschaften einen Shader generiert.
Das ganze ist keine Zauberei, sondern einfach eine Funktion, die ein paar Strings konkateniert. Es werden einfach bloß Codezeilen an- und abgeschalten, je nach aktivierter Eigenschaft.

Stimmt, das wäre wohl die einfachste Möglichkeit. :) Man muss ja nicht jeden Shader in eine Shaderdatei stecken. Dann werde ich das wohl auch so umsetzen, danke :)

Es gibt auch noch die Möglichkeit des Über-Shaders. Wenn ich mich recht erinnere macht das HalfLife2 so.
Dazu packst du einfach allen Shadercode in einen einzigen Shader und schaltest gewisse Zeilen per Konstanten ein und aus.
Wie gut das letztendlich funktioniert kann ich dir allerdings nicht sagen.
Großer Nachteil: Die Übersichtlichkeit wird katastrophal.
Vorteil: Keine Shaderwechsel mehr.

Specialist hat geschrieben:Es gibt auch noch die Möglichkeit des Über-Shaders. Wenn ich mich recht erinnere macht das HalfLife2 so.
Dazu packst du einfach allen Shadercode in einen einzigen Shader und schaltest gewisse Zeilen per Konstanten ein und aus.
Wie gut das letztendlich funktioniert kann ich dir allerdings nicht sagen.
Großer Nachteil: Die Übersichtlichkeit wird katastrophal.
Vorteil: Keine Shaderwechsel mehr.

Wann genau werden die Konstanten ausgewertet? Zur Laufzeit wäre dämlich schlecht, weil mein Shader-Code für volumetrische Texturen extrem unperformant ist, aber in einem Über-Shader jedes mal mit ausgeschalteter Execution Mask ausgeführt werden würde.

Ich finde die Idee auch seltsam. Wenn es nicht zur Laufzeit ausgewertet wird, dann muss es zur Compilezeit geschehen und dann sind es ja wieder mehrere Shader. Aber ich verstehe auch nicht, warum der Wechsel von Shadern so schlimm ist. Wenn man vorsortiert, kann man doch die Shaderwechsel minimieren. Man spart sich halt die Sortierung mit dem Über-Shader, aber performant auf GPU-Seite klingt das für mich auch nicht.

Doch, die Performance geht schon. Sprünge sind nur da ein Problem, wo Threads der selben Gruppe verschiedene Pfade nehmen. Bei einem Übershader, der nach Material- und Lichtbedingungen schaltet, nehmen aber eigentlich alle Fragmente die selben Wege. Das Branching müsste sich also quasi wie die gelungene Sprungvorhersage auf der CPU verhalten und nur noch die Taktzyklen von ein paar Mathe-Ops kosten.

Was anderes wäre es, wenn man per Textur die Materialeigenschaften ändern würde - so ne Art Material Map wär ja auch denkbar. Dann kann es aber je nach Granularität schon dazu kommen, dass viele Fragmentgruppen unterschiedliche Wege nehmen (und damit effektiv beide ausführen).

Schrompf hat geschrieben:Doch, die Performance geht schon. Sprünge sind nur da ein Problem, wo Threads der selben Gruppe verschiedene Pfade nehmen. Bei einem Übershader, der nach Material- und Lichtbedingungen schaltet, nehmen aber eigentlich alle Fragmente die selben Wege. Das Branching müsste sich also quasi wie die gelungene Sprungvorhersage auf der CPU verhalten und nur noch die Taktzyklen von ein paar Mathe-Ops kosten.

Wenn der Treiber den JUMP-Befehl benutzt und nicht PUSH/ELSE/POP

antisteo hat geschrieben:Wenn der Treiber den JUMP-Befehl benutzt und nicht PUSH/ELSE/POP

Worauf beziehst du dich?

Im übrigen wurde zumindest eine Zeit lang von GPUs/Treibern sog. Static Branching unterstützt. Damit führten Verzweigungen aufgrund einzelner Boolean-Konstanten dazu, dass Shaders noch vor der eigentlichen Ausführung an die aktuellen Werte der entsprechenden Boolean-Konstanten angepasst wurden. Auf dieses Branching mit Draw-Call-Granularität bezieht sich wohl auch Specialist. Aber wie Schrompf schon sagte, selbst Dynamic Branching funktioniert auf heutigen GPUs gut, solange es einigermaßen lokal kohärent ist.

Viel wichtiger als der Ausführungsoverhead ist in diesem Fall wohl die mit vielen Zweigen unabhängig von deren Ausführung steigende Komplexität und der Registerdruck. Die Optimierung durch den Compiler wird allgemein schwieriger, weswegen bei sehr unterschiedlicher Funktionalität mehrere unabhängige Shader wohl nach wie vor eine gute Wahl sind.

Neu in DirectX 11 ist die sog. Dynamic Shader Linkage. Habe ich selbst noch nicht ausprobiert, und kann deshalb leider nichts über die Laufzeiteigenschaften sagen.