Hi,

ich bin z.Z. am ueberlegen mein Shader Management umzustellen, habe aber davor noch ein paar fragen:

1) Man kann ja eigene funktionen im Shader deklarieren, wenn diese nicht genutzt werden, wirken sie sich auf die Performance (abgesehen von der lade/compilier zeit) aus?
Wenn ich z.B. 20 standard funktionen einfach immer lade, egal ob ich sie in dem speziellen shader brauche oder nicht, ist das okay oder sollte ich es vermeiden?

2) Wie gut optimiert der compiler funktionen? Gibt es sowas wie ein inline statement?
Wenn ich z.B. so eine funktion mache:



ist dies langsamer als wenn ich direkt sowas schreibe:



??

3) Wenn ich diese funktion z.B. auch fuer vec2, vec3 und vec4 haben moechte, muss ich da 4 varianten von schreiben (overload gibt es ja, oder?) oder gibt es irgendeinen variant/generic variablen typ den man nutzen kann und welcher vom compiler dann wie bei einem C++ Template spezialisiert wird?

4) Es gibt ja soweit ich weiss eine maximal laenge fuer einen Shader. Worauf genau bezieht sich diese? Anzahl an Zeilen? Zeichen? Operationen?
Falls es sich auf Zeilen oder Zeichen Anzahl bezieht.. vor oder nach dem optimieren? Wenn ich z.B. wie oben angesprochen immer 20 standard funktionen habe wuerden die ja einiges an Zeichen/Zeilen belegen.


Danke,
Aya~

Also, ich kann dir jetzt nur sagen, was ich gesehen habe, als ich mir einmal (weiß nicht mehr, wie das Tool hieß) den generierten ASM-Code ausgeben ließ, aber irgendetwas, das an CALL erinnert war da gar nicht. Also alle Funktionen geinlined. Wenn das allgemein gilt, sollte es egal sein, ob du etwas als Funktion anschreibst oder nicht und überflüssige Funktionen sollten aus dem Code auch wieder verschwinden.

Was die generics angeht, die gibt´s soweit ich weiß nicht (bin nicht 100% sicher), aber Makros müssten funktionieren.

Also, da weiß ich jetzt wirklich nichts, aber das einzige, was da irgendwie Sinn machen würde, wäre, wenn die Länge des generierten Codes beschränkt ist. Alles andere wäre nur eine künstliche Beschränkung. Aber wie gesagt, ich weiß es nicht.

Hallo,

eine weitere Möglichkeit ist, dass du deine 20 Funktionen die du brauchst jede in einen eigenen Shader packst und diesen dann kompilisiert. In deinem richtigen Shader, der die Funktionen dann benutzen will deklarierst du die Funktion nur.
Alle Funktionen, die benutzt werden muessen dann zu deinem Shader mit glAttachShader angehaengt werden, damit der Linker die Definition findet.
Dies hat den Vorteil, dass du die Funktionen nur einem schreiben und kompilieren musst.

zum Beispiel:
(1. shader)

(2. shader)

Und in deinem Host-Code musst du dann beide shader compilieren und mittels glAttachShader den 1. an den 2. anhaengen und dann den 1. linken.

Mit freundlichen Grüßen
Archaon

1.) Je nach treiber wirst du probleme bekommen, ältere haben sich richtig pissig.
2.) Eine optimierung und das gleiche wie 1.), erwarte es nicht, denn die Specs fordern es nicht.
3.) Nein
4.) Auf Zeichen, inklusive Zeilen Umbruch, 0 terminierung. alles von wenigen hundert bis mehreren tausend ist drin MAX 65535 mit den neueren Karten.

Dein Kern Problem sind die nicht dynamischen Shader. Üblicherweise nutzten Entwickler, aufwändigerer Shader systeme, runtime kompilierung, da sie so mit Scriptsprachen oder eigenen Code die Shader zusammen stellen und dann erst kompilieren. Selbst in unserem Forum hab ich schon 1-2 Post gesehen, wo Entwickler die Shader zusammen bauen, statt zig hundert kombis zu schreiben.

Es geht auch noch ein Schritt weiter wie hier http://prideout.net/blog/?p=1 .

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Danke für die antworten soweit, hilft schonmal weiter

@Tak: Ich baue die Shader natürlich dynamisch über ein script ähnliches system, schon sehr lange. Mir geht es bei den fragen nur um etwas was ich gern noch einbauen/umbauen möchte, und da nur vorher wissen will wieviel arbeit ich reinstecken muss und was ggf der Treiber selbst schon macht.

Aya~

Eine andere frage noch:

Macht es einen unterschied ob ich z.B. zwei vec2-uniform variablen habe anstatt einer vec4? Also sollte man uniforum variablen versuchen zusammen zufassen, oder kann man wenn es fuer das Programmieren uebersichtlicher ist es ruhig in verschiedenen lassen?

Aya

Eine Uniform-Variable braucht immer vec4. Also wenn der Speicher für Uniforms knapp wird, solltest du zusammenlegen. Wenn es aber nur einige wenige Uniforms sind ist Speicher und auch Speicherdurchsatz (beim ändern von Uniforms) kein Problem. In dem Fall ist es besser die Uniforms getrennt zu lassen da sie sonst erst auseinander kopiert werden müssen.

Bei Texturzugriffen solltest du möglichst viel in einem Texel zusammenfassen, da Texturzugriffe teuer sind.

_________________
Yeah!

Bei der Geschichte gibt es nicht viele Regeln, um optimale ausnutzung zu haben.
Folgende Regeln hab ich noch im Kopf.

Die Daten, die zugegriffen werden, müssen immer in 16 Byte verpackt werden. Da das Byte alignment 128Bit ist und wenn Daten größer oder versetzt sind dann wird es langsamer, da 128 Bit eingelesen werden, dann geschiftet und dann erst mit gearbeitet werden kann, bzw. mehr als ein mal 128Bit gelesen werden müssen um die op zu machen.
half float,4x float ist der tot.
8x half float <-schnellste was gibt
2x half float, 3x float <- schneller aber langsamer als voriges beispiel
half float, 3x float, half float <- übelst lahm
4x float <- schnellste was gibt
7x half float <- langasm
1x half float, 3x int <- langsamste was gibt

Datentypen sind wichtig.
Int ist lahm, half float ist schnell, wegen weniger cache misses und float ist super fast

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Was sind denn Deine Quellen, wenn ich fragen darf?

Meine Erinnerungen ^^
Nvidia und ATI schreiben ab und zu solche Infos in die Papers, wie z.B. als Integer hinzu kam.
Integer sind recht neu und langsamer als floating point operationen auf der GPU.
half float sind caching freundlicher, da man weniger cache misses hat und damit schneller als float.
GPU's haben wie SIMD auf der CPU 128Bit alignment, also alles, was nicht in 128Bit passt, ist automatisch langsamer, wegen cache misses.
Mixen von verschiedenen Datentypen in einem 128Bit block ist langsamer, da über weitere schritte die einzelnen operationen für die verschiedenen typen gemacht werden muss. Da man nicht extra operationen mit in die GPU packt, um half float, int, int, half float zu supporten, da müssten hunderte von operationen per hardware rein gegossen werden.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004