DGL :: Thema anzeigen - Shader Limitierungen und Geschwindigkeit

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

Autor:	Aya [ Fr Aug 26, 2011 07:32 ]
Betreff des Beitrags:	Shader Limitierungen und Geschwindigkeit
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: Code: float doSomething(float a, float b) { return a + b } myValue = doSomething(valueA, valueB); ist dies langsamer als wenn ich direkt sowas schreibe: Code: myValue = valueA + valueB; ?? 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~

Autor:	sharkman [ Fr Aug 26, 2011 08:16 ]
Betreff des Beitrags:	Re: Shader Limitierungen und Geschwindigkeit
Zitat: Wie gut optimiert der compiler funktionen? Gibt es sowas wie ein inline statement? 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. Zitat: Es gibt ja soweit ich weiss eine maximal laenge fuer einen Shader. 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.

Autor:	Archaon [ Fr Aug 26, 2011 09:01 ]
Betreff des Beitrags:	Re: Shader Limitierungen und Geschwindigkeit
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) Code: float doSomething(float a, float b) {return a + b;} (2. shader) Code: float doSomething(float a, float b); main() { float ret = doSomething(2, 4); } 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

Autor:	TAK2004 [ Fr Aug 26, 2011 10:00 ]
Betreff des Beitrags:	Re: Shader Limitierungen und Geschwindigkeit
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 .

Autor:	Aya [ Fr Aug 26, 2011 10:07 ]
Betreff des Beitrags:	Re: Shader Limitierungen und Geschwindigkeit
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~

DGL https://delphigl.com/forum/

Shader Limitierungen und Geschwindigkeit https://delphigl.com/forum/viewtopic.php?f=20&t=10051	Seite 1 von 1

Autor:	Aya [ Sa Aug 27, 2011 05:02 ]
Betreff des Beitrags:	Re: Shader Limitierungen und Geschwindigkeit
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

Autor:	Coolcat [ Sa Aug 27, 2011 08:32 ]
Betreff des Beitrags:	Re: Shader Limitierungen und Geschwindigkeit
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.

Autor:	TAK2004 [ Sa Aug 27, 2011 12:37 ]
Betreff des Beitrags:	Re: Shader Limitierungen und Geschwindigkeit
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

Autor:	phlegmatiker [ Mo Aug 29, 2011 07:20 ]
Betreff des Beitrags:	Re: Shader Limitierungen und Geschwindigkeit
TAK2004 hat geschrieben: 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 Was sind denn Deine Quellen, wenn ich fragen darf?

Autor:	TAK2004 [ Mo Aug 29, 2011 09:31 ]
Betreff des Beitrags:	Re: Shader Limitierungen und Geschwindigkeit
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.

Seite 1 von 1	Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/