Shader-Management?

Für Fragen zu Grafik APIs wie DirectX und OpenGL sowie Shaderprogrammierung.
Antworten
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Shader-Management?

Beitrag von Eisflamme »

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?
antisteo
Establishment
Beiträge: 854
Registriert: 15.10.2010, 09:26
Wohnort: Dresdem

Re: Shader-Management?

Beitrag von antisteo »

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.
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: Shader-Management?

Beitrag von Eisflamme »

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 :)
Specialist
Establishment
Beiträge: 135
Registriert: 29.08.2003, 14:22
Kontaktdaten:

Re: Shader-Management?

Beitrag von Specialist »

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.
antisteo
Establishment
Beiträge: 854
Registriert: 15.10.2010, 09:26
Wohnort: Dresdem

Re: Shader-Management?

Beitrag von antisteo »

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.
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
Eisflamme
Establishment
Beiträge: 412
Registriert: 26.05.2002, 17:42
Wohnort: Köln

Re: Shader-Management?

Beitrag von Eisflamme »

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.
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Shader-Management?

Beitrag von Schrompf »

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).
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
antisteo
Establishment
Beiträge: 854
Registriert: 15.10.2010, 09:26
Wohnort: Dresdem

Re: Shader-Management?

Beitrag von antisteo »

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
http://fedoraproject.org/ <-- freies Betriebssystem
http://launix.de <-- kompetente Firma
In allen Posts ist das imo und das afaik inbegriffen.
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Shader-Management?

Beitrag von CodingCat »

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.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Antworten