Conditionals im (Cg-) Shader

Hallo liebe Experten,

ich habe mal eine Frage zu Shadern im allgemeinen, die mir schon länger auf der Zunge brennt:

Ich möchte gerne in meinem Shader "Flags" setzen, welche Features eingeschaltet sind und welche nicht.
z.B. möchte ich über die Anwendung steuern, ob er die Lightmap auswerten soll oder eben nicht.

Bisher habe ich das so gemacht, dass ich dem Shader über eine boolschen uniform mitteile, ob er die Lightmap benutzen soll oder nicht:

Shader:

markieren

Code:

			fragmentOUT main(fragmentIN IN,uniform bool uselightmap) {

...

..

  if (uselightmap) {   

    OUT.Color.rgb = OUT.Color.rgb * f4tex2D(lightmap,tex_coord) ;                          

  }

}

Delphi:
cgGLSetParameter1f(FParamHandle,value);
Jetzt habe ich schon oft gehört, dass das nicht gerade performant sein soll (und ist

), da ja die uniform variable dauernd zum Shader übertragen wird und im Shader ein branching angestossen wird.

Welche Möglichkeiten gibt es denn und benutzt ihr, um solche "Flags" zu setzen, wenn man in einem Shader einzelne "Schalter" setzen will?
Ist es wirklich die einzige und beste Möglichkeit, für jegliche vorkommende Variante (Lightmap an, Lightmap aus, Normalmap an, Normalmap aus usw.) eine eigene Shader-Variante zu kompilieren und dann einzusetzen?

Ich finde das sehr umständlich und der Wartungsaufwand ist ja immens, wenn man viele solcher Flags hat und dann nachträglich bei einer Veränderung jede Variante umschreiben muss...

P.S.:
Ich benutze kein CgFX-Schema, sondern getrennte Vertex- und Fragment-Shader, somit kann ich keine "Techniques" verwenden.

**Medium**

Zitat von blackfin:

Ist es wirklich die einzige und beste Möglichkeit, für jegliche vorkommende Variante [...] eine eigene Shader-Variante zu kompilieren und dann einzusetzen?

Das ist, soweit ich das überblicke, der übliche Weg. Vor allem ohne Techniques wirst du da nicht wirklich drum rum kommen fürchte ich. Das sinnigste dürfte eine Kollektion von Teil-Shadern und spezialisierten Versionen sein, die man "on demand" zusammen schraubt und durch den Compiler nudelt. Nicht traumhaft schön, aber so ist das ja noch an einigen Stellen in der Shader-Welt: Komfort kommt später. Vielleicht.

(Bin ja schon froh Hochsprachen dafür zu haben - und ziemlich fähige Compiler dazu!) Und, wie du ja gemerkt hast, Branching = nono, vor allem dynamisches.*

Ich erinnere mich z.B. an Battlefield 2. Da wurde nach Änderung der Grafikeinstellungen immer reichlich lange mit Ladebalken gewerkelt, mit dem Label "Shader werden optimiert". Ich vermute da hinter genau oben genanntes, es ist also denke ich eher kein bad-practice. Im gamedev Forum gab es dazu auch schon mal irgendwo einen Thread, in dem der Tenor ähnlich war, wenn ich mich nicht böse irre.

Wenn man es wirklich geschickt anstellt, kann man Shader ja in Code-Fetzen zerlegen, die in verschiedensten Kombinationen zusammen gesetzt laufen können. Dann könnte man sich zur Runtime im Speicher seinen dynamischen Shader zusammen würfeln, ohne vorab zig einzelne, für jeden möglichen Fall separate anlegen zu müssen.

*) Ich hab auf gamedev hier und da aufgeschnappt, dass man in einigen Fällen mit Lerp() Branching-ähnliches Verhalten bekommen kann, und dies etwas flotter wäre. Frag mich aber grad nicht nach Details! Das könnte Pipeline-schonender sein, wenn ich mal mutig Mutmaßen soll. Was man aber nicht wirklich verhindern können wird ist, dass immer alle Branches auch ausgeführt werden - zumindest so lange nicht jedes Pixel seine eigene ALU+Caches hat

Ahhh, ich wusste doch, dass DU mich selbst in der Nacht nicht im Stich lässt

Zitat:

Das sinnigste dürfte eine Kollektion von Teil-Shadern...

Das ist eigentlich eine sehr gute Idee. Ein eigenes ShaderLab aus lauter zusammenfrickelbaren Unterprogrammen sozusagen...mhm, klingt schmackhaft.
So funktionieren wohl auch Mental Mill und co., hm?

Nur...wie macht man es dann am Besten mit der Parameter-Übergabe. Die bleibt ja im Hauptprogramm und wenn das auch dynamisch sein sollte, welche Parameter im Hauptprogramm an den Schattierer übergeben werden, kann das doch ziemlich langsam werden, oder liege ich da falsch?
Immerhin kann ich dann ja die Parameter-Übergabe nicht "hardcoden", sondern muss mir in den Shader-Apply-Routinen die aktuellen Parameter und deren Typen auch zusammensuchen und übergeben...mhm...

Zitat:

...Lerp() Branching...

Whut?

Wegen "Branching = nono"...
Ist es inzwischen nicht schon so, dass die neueren GTX-Karten nicht mehr alle Varianten durchgehen, sondern nur noch die, die gebraucht werden?
Aber im Allgemeinen stimmt das ja schon...irgendwie wie in der Steinzeit...aber das macht irgendwie auch Spass

**Medium**

Zitat von blackfin:

Ahhh, ich wusste doch, dass DU mich selbst in der Nacht nicht im Stich lässt

Bedank dich bei meinem alltagsuntauglichen Rythmus

Zitat:

So funktionieren wohl auch Mental Mill und co., hm?

Um das zu beantworten, müsste ich's kennen

Zitat:

Nur...wie macht man es dann am Besten mit der Parameter-Übergabe. Die bleibt ja im Hauptprogramm und wenn das auch dynamisch sein sollte, welche Parameter im Hauptprogramm an den Schattierer übergeben werden, kann das doch ziemlich langsam werden, oder liege ich da falsch?

Och, auffer CPU ist das doch Pusselkrams. Wenn du jetzt nicht gerade ein paar tausend Parameter zu prüfen hast - aber dann wäre eh etwas faul, oder du machst GPGPU =). Ab DX10 kann man auch statt der gewöhnlichen Parameter Streams binden, und das ist in no-time gemacht. Zudem könntest du dann einen fixen Stream nehmen in dem alles ist, und der Shader pickt sich raus was er will. Gearbeitet hab ich damit aber leider auch noch nicht, da ich aus diversen Gründen auf DX9 fest hänge - zumindest in dem Projekt, in dem es interessant gewesen wäre. Aber eine Hand voll if's und cases werden dir im Draw nicht das Genick brechen. Nicht auffer CPU.
(Man könnte auch eine Textur missbrauchen, und in diese sämtliche Parameter werfen, und mit indizierten Lookups sind die im Shader super-flott verfügbar. Wenn diese nur so 16x16 Pixel groß ist, tut das ständige Locken auch nicht SO arg weh. Müsste man einfach mal ausprobieren.)

Zitat:

Whut?

Irgendwie ging es dabei darum, dass man seine Kondition so ausdrückt, dass dabei 0 oder 1 gelerpt wird, und die relevanten Schritte danach bei 0 einfach nix verändern. Wie gesagt, das geht wohl nicht immer, und man muss es darauf auslegen. Zudem spart das wohl nicht das zwangsweise Ausführen beider "Branches", aber ich meine man kommt damit der Pipeline etwas entgegen. Aber nagel mich hier auf nix fest, das sind Infos, die mein Hirn aus Fetzen nebenbei gelesener Forenbeiträge auf gamedev geformt hat. Auf jeden Fall war da was. *hust*

Zitat:

Wegen "Branching = nono"...

Stimmt, da tat sich was. Jetzt wo du's so sagst... Da bin ich grad garnicht mehr auf'm Stand, ob und wie gut das mittlerweile hin haut.

Zitat:

Aber im Allgemeinen stimmt das ja schon...irgendwie wie in der Steinzeit...aber das macht irgendwie auch Spass

Jap

. Hat ein bischen was vom guten alten Pioniergeist der 60er, den ich als kleiner Bub gehofft hatte erhaschen zu können wenn ich mal groß bin - und dann kommen die mit so high-level-gelöt wie IDEs und Standardsoftware...

. Hat aber auch was, vor allem in der Theorie, aber am offenen Herzen fummeln kann eigentlich nichts wirklich ersetzen. Ganze Treiber mit Shadern in's Nirvana jagen - schöner Sport

Zitat:

Bedank dich bei meinem alltagsuntauglichen Rythmus

Das kenne ich nur zu gut....

(Ha! Den wollte ich immer schon mal verwenden!)

Zitat:

Um das zu beantworten, müsste ich's kennen

Das ist so ein ShaderLab:

klick

Zitat:

Ab DX10 kann man auch statt der gewöhnlichen Parameter Streams binden, und das ist in no-time gemacht.
Zudem könntest du dann einen fixen Stream nehmen in dem alles ist, und der Shader pickt sich raus was er will.

Ich benutze gar kein DirectX, sondern den OpenGlibber....
Gibt es da eventuell etwas vergleichbares? Mhm..muss ich doch mal danach suchen.
Ich merke gerade deutlich, wie viel mir eigentlich noch von dem Kram fehlt...

Blackfin is now very busy lerping the Pusselkrams

**Medium**

Zitat:

Das ist so ein ShaderLab:

klick

WAH! Komfort! *wegrenn* =)

Zitat:

Ich benutze gar kein DirectX, sondern den OpenGlibber....
Gibt es da eventuell etwas vergleichbares? Mhm..muss ich doch mal danach suchen.

Ui, OGL ist für mich mehr oder weniger noch ein Fremdwort, bzw. zählt ein paar Quads malen wohl nicht zu "Erfahrung". Kann durchaus sein, dass es da bereits entsprechende Extensions gibt.

Zitat:

Ich merke gerade deutlich, wie viel mir eigentlich noch von dem Kram fehlt...

Ich bin mittlerweile davon überzeugt, dass es unmöglich ist in diesem Feld mit nur einem Menschenleben und normalem Hirn diesen Status zu verlassen

Zitat:

Blackfin is now very busy lerping the Pusselkrams

(Wobei ich eher in Richtung Stückel-Shader tendieren würde muss ich zugeben.)

Viel Erfolch!