DGL
https://delphigl.com/forum/

GLSlang: zur Zeit überhaupt funktional?
https://delphigl.com/forum/viewtopic.php?f=20&t=2437		 Seite 1 von 2
Autor:  Mars [ Mi Jan 28, 2004 14:09 ]
Betreff des Beitrags:  GLSlang: zur Zeit überhaupt funktional?
Diese etwas irritierende Frage stellt sich mir, wenn ich mir die Spezifikationen der GFFX bzw. der aktuellen Radeonkarten so ansehe:
beide können anscheinend keine bedingten Sprünge im FragmentShader durchführen.

Während Vertexshader relativ einfach (und halbwegs performant) auch auf der CPU ausgeführt werden können, das Fehlen bedingter Sprünge hier also mehr oder weniger vernachlässigbar ist, ist dies bei Fragmentshadern nicht der Fall.
Aus diesem Grund frage ich mich tatsächlich, ob auf aktueller Grafikhardware GLSlang überhaupt einen realen Vorteil gegenüber ARB_vertex_program und ARB_fragment_program bieten kann?

Ehrlich gesagt scheint es mir, dass man, um GLslang wirklich nutzen zu können, auf die nächste oder übernächste Grafikkartengeneration warten muss, und dass die derzeitige Implementation (eh nur auf ATI Karten, NVidia hält sich ja ganz zurück) mehr als Testbett zu sehen ist, denn als Feature, das außer dem Lerneffekt tatsächliche Vorteile bietet.
Autor:  LarsMiddendorf [ Mi Jan 28, 2004 16:22 ]
Betreff des Beitrags: 
Es ist wirklich ärgerlich das da noch viele Fehler im Treiber sind, aber ich hoffe mal das die bald beseitig werden. Die ganzen Standard Shader lassen sich umsetzen, so daß man schon einiges damit programmieren und es ist auf jeden Fall besser als glSlang überhaupt nicht zu unterstützen wie NVidia. Das deren Treiber kein glSlang hat liegt vermutlich nicht an der Unfähigkeit so etwas zu implementieren, denn sie haben ja auch Cg entwickelt, sondern eher daran, daß die GeForce Karten bei Shadern langsamer sind und es sich für NVidia erst lohnt glSlang anzupreisen wenn es auch richtig gut läuft. Andererseits ist es schade, denn die 1024 Befehle wird man mit Assembler wohl kaum ausnutzen können und die Shader sind flexibler als die von der Radeon aber leider zu langsam.
glSlang unterstützt das Linken von compilierten Shadern in einer Art und Weise wie Units. Das kann man natürlich auch über ARB_* einbauen, aber es ist schön, daß es direkt in OpenGL integriert ist.
Autor:  Sascha Willems [ Mi Jan 28, 2004 20:24 ]
Betreff des Beitrags: 
Was meinst du denn mit "fehlen bedingter Sprünge" genau? IF-Anweisungen sind ja auch bedingte Sprünge, und die hab ich bereits erfolgreich in glSlang-Shadern eingesetzt.

Aber recht hast du schon, auf aktueller Hardware ist glSlang (zumindest momentan) eigentlich eher zum Lernen der HLSL zu gebrauchen. Beim Verfassen meiner glSlang-Einführung bin ich z.B. auf die ein oder andere Sache gestossen, die auf meiner Radeon nicht funktionierten, wohl teilweise auch aufgrund eingeschränkter Hardwarefähigkeiten. So lies sich auf gl_FrontFacing (!) im FragmentShader nicht zugreifen, Noisefunktionen werden nur per Software emuliert (also im FS damit tabu), unabhängige Texturenzugriffe wurden als abhängig gesehen (mehr wie 6 Texturenzugriffe waren auch mit den komischsten Verrenkungen und Umwegen leider nicht möglich, obwohl es ja 16 oder gar mehr sein müssten), und Texturenzugriffe im Vertexshader (z.B. für Displacement) sind auch nicht möglich.

Sicher die ein oder andere Sache, die sich per Treiberupdate verbessern lässt (was ja u.a. schon passiert ist, siehe ftransform), aber da glSlang ja mit dem Hintergedanken der Langlebigkeit entwickelt wurde, wird aktuelle Hardware wohl nie alle Features unterstützen. Was auf den Radeon-Karten auch noch hemmend dazu kommt, ist die Tatsache das die unterstützte Shaderlänge recht gering ist (96 Instruktionen im FS) und auch dieses Limit hab ich das ein oder andere mal schon gesprengt (wo bleibt eigentlich der F-Buffer, der das Problem eigentlich lösen soll?).

Summa Summarum : Momentane glSlang-Implementationen sind eher zum Einarbeiten in die neue HLSL brauchbar, für den praktischen Einsatz natürlich nocht nicht.
Autor:  LarsMiddendorf [ Mi Jan 28, 2004 20:41 ]
Betreff des Beitrags: 
Mit dynamischen Sprüngen sind vermutlich Schleifen gemeint, deren Durchlaufzahl nicht von uniform Variablen anhängt und daher irgendwo ein bedingter Sprung stehen muß. Die GFFX kann solche Schleifen zumindest im Vertex Shader ausführen. Bei der Radeon kann man im Direct3D VS 2.0 nur Sprünge einfügen, bei denen die Sprungbedingung schon vor Ausführung des Shaders feststeht. Daher kann der Treiber auch while Schleifen vor Ausführung des Shaders ausrollen oder zumindest schon vorher festlegen, wie die Befehlsreihenfolge ist. Bei if Anweisungen werden beide Möglichkeiten ausgewertet und am Ende wird dann (vermutlich mit CMP) entschieden welche Möglichkeit genommen werden soll.

@Mars: Für welchen Technik brauchst du denn diese Fähigkeit im Fragment Shader?
Autor:  Mars [ Do Jan 29, 2004 09:28 ]
Betreff des Beitrags: 
Ja genau das meinte ich - ein Sprung dessen Bedingung erst zur Laufzeit des Shaders feststeht.

Zur Zeit kann ich Fragmentshader ja ohnehin nicht nutzen, dachte aber etwa an Rekursionen - oder aber an völlig unterschiedliche Algorithmen, die zur Laufzeit ausgeführt werden.
Z.B. könnte man dann ohne großen Performanceverlust in Abhängigkeit vom Alphawert zwischen vier verschiedenen Algorithmen wechseln, ohne einen neuen Shader binden zu müssen - z.B.

if (Alpha > 0.75)
Algorithmus1;
else if (Alpha > 0.50)
Algorithmus2;
else if (Alpha > 0.25)
Algorithmus3;
else
Algorithmus4;

Wäre doch schon toll: keine Sortierung nach Shadern mehr, Wechsel des Shaders innerhalb eines glBegin glEnd Blocks, und das Ganze fast gratis, da zur Ausführungszeit eines Algorithmus nur der Sprung hinzukommt. Mit der Unterstützung eines Indexregisters in eine Sprungtabelle ginge es sogar noch schneller.
Allerdings würde dies natürlich auch die Unterstützung komplexerer Shader bedingen, bei der es ja auch noch ziemlich hapert.
Autor:  Sascha Willems [ Do Jan 29, 2004 11:19 ]
Betreff des Beitrags: 
Das was du da willst, geht definitiv, und ich habs auch schon (in kleinerem Stile) selbst in nem Shader im Einsatz :

Code:
  1. uniform sampler1D tex0;
  2. uniform sampler2D tex1;
  3. uniform int pass;
  4.  
  5. void main(void)
  6.  {
  7.   if (pass == 1)
  8.    gl_FragColor = texture1D(tex0, gl_TexCoord[0].s) * gl_Color  * texture2D(tex1, vec2(gl_TexCoord[1])) * 2.0;
  9.   else
  10.    gl_FragColor = vec4(0.0, 0.0, 0.0, 0.0);
  11.  }


Auch der von dir angesprochene Alphavergleich ist über If-Abfragen funktional und hat bei mir auch schon geklappt (via gl_FragColor.a). Problem bei solchen Konstrukten ist aber die Tatsache, das solche Abfragen zu recht langem Shadercode führen, wodurch du zumindest auf Radeons ganz schnell die maximale Anzahl an Instruktionen im Fragmentshader sprengen tust. Dort wirst du also leider kaum mehrere Shader in einem durch If-Abfragen unterbringen können.
Autor:  LarsMiddendorf [ Do Jan 29, 2004 13:16 ]
Betreff des Beitrags: 
Ja es braucht nicht gesprungen werden, sondern man kann das auch in ARB_fp mit dem CMP Befehl implementieren. Der Nachteil ist, daß das im schlimmsten Fall beides berechnet werden muß. In dem Alpha Masking Bsp in Seth geht das auch in fxPascal.
SoS hat mit seinem Einwand Recht. Man sollte nicht einen langen Shader mit mehreren Alternativen, sondern besser mehrere kleinere oder im dynamisch erzeugte Shader benutzen. In einem PDF zu Cg von NVidia wird genau diese Situation beschrieben. Und da glSlang verschiedene Shader Module linken kann, kann man sich ja den gewünschten Shader zur Laufzeit zusammenbauen ohne das man alle Möglichen Kombinationen abdecken muß.
Wenn man allerdings statt alpha eine uniform Variable nimmt, dann könnte der Treiber doch eigentlich bei Änderung der Variablen auch den Shader ändern.
Bei D3D gibt es so eine Reihe von Boolean Registern die nur außerhalb des Shaders geschrieben werden können und die in if Abfragen verwendet werden können. Irgendwie muß auch die normale OpenGL Pipeline durch Shader umgesetzt werden. Vielleicht erzeugt der Treiber je nach Anzahl der Lichter,Texture Gen's,Texture Blend Modi usw.. einen speziellen Shader. Eventuell wird dieses Verfahren auch auf die uniform Variablen übertragen, obwohl ich mir bei dem aktuellen Stand von glSlang das nicht vorstellen kann.
Autor:  Mars [ Do Jan 29, 2004 22:24 ]
Betreff des Beitrags: 
Dass if Abfragen durch CMP realisiert werden können ist mir schon klar - der Vorteil eines bedingten Sprunges ist ja gerade eben, dass wirklich nur ein Teil des Codes ausgeführt werden muss - und nicht etwa sämtliche Schleifenteile berechnet werden und das Endergebnis dann schlussendlich daraus "zusammengewurschtelt" wird.
Zur Zeit ist es ja auch nicht so dringend, weil hochkomplexe Shader ohnehin noch kein Thema sind. Ob ich jetzt übrigens verschiedene Sourceteile vor dem Senden zusammenkopiere, oder OpenGL Programmteile "zusammenlinken" lasse, kommt ziemlich sicher auch performancemäßig auf's selbe hinaus, GLSL nimmt es einem in dieser Hinsicht halt ab einen eigenen Zwischenkompiler wie CG oder fxPascal zu verwenden (wohingegen der ARB-Assembler wahrscheinlich schneller kompiliert werden kann, was einen "Linker" ohnehin überflüssig macht, zumal man die Programmsources ja nicht gerade während der Renderschleife senden wird).

Per Definition unterstützt GLSL aber meines Wissens auch echte Schleifen (die sich den Endwert einer Schleifen z.B. aus einer Textur holen könnten) - und das ist meines Erachtens mit heutigen Karten einfach technisch nicht machbar. Dass empfohlen wird, kurze Shader zu verwenden und unterschiedliche Bedingungen zu vermeiden, liegt ja eben an dieser technischen "Unzulänglichkeit".
Das soll jetzt keine Kritik an GLSL sein, im Gegenteil, es ist für OpenGL ja auch wichtig, zukunftsweisende Anforderungen zu stellen, und nicht nur mit der Unterstützung diverser Features nachzuziehen.

Als praktische Anwendung fiele mir z.B. auch die Möglichkeit ein, echt dreidimensionale Objekte über ein einziges Polygon mittels 3D-Texturen zeichnen zu lassen - Falls ein Punkt außerhalb der Bounding Box (in diesem Fall Rect) liegt, verlässt man den Shader sofort, ansonsten geht man den Richtungsvektor Bildschirmpixel->Quader entlang, bis man das das erste Texel findet, das dargestellt werden soll (von mir aus über den Alphawert definiert) und stellt dessen Farbe dann im Pixel dar - sogar den Z-Wert könnte man korrekt zurückschreiben. Wenn man kein entsprechendes Texel findet, wird das Pixel halt ebenfalls nicht gezeichnet.
Auf diese weise könnte man mit einem einzigen Polygon und einem gar nicht so umständlichen Shader hochkomplexe Objekte realisieren - zwar mit einem (wahrscheinlich) ziemlich langsamen Shader, aber immer noch um's mehrfache schneller als heutige Techniken "echte" Voxel darzustellen (also nicht nur gefakte 2D-Oberflächen, wie sie schon in Comanche realisiert wurden).
Autor:  LarsMiddendorf [ Do Jan 29, 2004 22:47 ]
Betreff des Beitrags: 
So einen ähnlichen Shader habe ich für Cg schonmal gesehen. Da wurde dann 64 Mal aus einer Volumen Texture gelesen. Es wäre natürlich schöner wenn man das abbrechen könnte und richtige Freiheiten hätte.
Du hast ja auf der GFFX glaube ich 512(1024?) Befehle. Vielleicht kannst du das mal ausprobieren? Man hat da ja auch keine Begrenzung mit den Texturezugriffen. Mich würde mal interessieren wie schnell so extreme Shader sind. Auch wenn es unglaublich klingt, sollten doch 512 Texturezugriffe möglich sein. Kann das eigentlich mit der langen Pipeline in der Grafikkarte zu tun haben, daß die sich mit dynamischen Sprüngen schwer tut?
Autor:  Gast [ Do Jan 29, 2004 23:37 ]
Betreff des Beitrags: 
Also Carad meldet Folgendes:
Zitat:
(FP) max program instructions: 1024
(FP) max program native instructions: 1024
(FP) max program temporaries: 32
(FP) max program native temporaries: 32
(FP) max program parameters: 1024
(FP) max program native parameters: 1024
(FP) max program attribs: 16
(FP) max program native attribs: 16
(FP) max program address registers: 0
(FP) max program native address registers: 0
(FP) max program local parameters: 128
(FP) max program env parameters: 128
(FP) max program alu instructions: 1024
(FP) max program tex instructions: 1024
(FP) max program tex indirections: 1024
(FP) max program native alu instructions: 1024
(FP) max program native tex instructions: 1024
(FP) max program native tex indirections: 1024

Für eine 3D Textur fester Größe (32x32x32 oder sogar 64x64x64) werde ich das wirklich ausprobieren: dank fxPascal sollte es gar nicht so umständlich sein :wink: .
Das Polygon könnte dann ein Billboardquad sein, ein Problem stellt sich noch den "Richtungsvektor" vom Pixel in die 3D-Textur zu finden (eventuell würde es dazu sinn machen, die projizierten vier Eckpunkte des Billboards als Parameter zu übergeben, um dann aus der Pixelposition im Quad den tatsächlichen Offset in die Textur zu berechnen - ich denke Texturkoordinaten würden mir da gar nichts nützen) - wird aber sicher interessant.
Hmm, eine 3D-Textur brauche ich auch noch, wird wohl mal wieder eine Kugel oder sonst was Simples herhalten müssen... oder falls man es öfter braucht: kennt jemand eine simple Möglichkeit aus Polygondaten Voxel zu generieren (eventuell über den DepthBuffer aus unterschiedlichen Blickwinkeln) - einen eigenen Rasterizer zu schreiben, habe ich nicht wirklich Lust ?
Autor:  Mars [ Do Jan 29, 2004 23:38 ]
Betreff des Beitrags: 
... hatte mich am Desktop nicht eingeloggt.
Autor:  Mars [ Do Jan 29, 2004 23:49 ]
Betreff des Beitrags: 
... manchmal sitze ich echt auf der Leitung:
wenn ich ein 3D-Objekt und dessen Bounding Box habe, langt es für eine 3D-Textur der Auflösung t ja aus, das Objekt mittels Clipping in t slices der Auflösung z/t in einem Fenster der Auflösung txt zu zeichnen (Orthogonalprojektion), und die Farbe der Pixel in die entsprechende Position der 3D-Textur zu schreiben.
Mal schauen, ob da keine Rundungsfehler dazwischenfunken.
Autor:  LarsMiddendorf [ Fr Jan 30, 2004 00:14 ]
Betreff des Beitrags: 
Von den Fähigkeiten ist die GFFX schon toll: 1024 Befehle. Mit der Radeon und dem fehlerhaften glSlang gibt's bei allen besseren Shader schon Fehlermeldungen. Dafür laufen die Shader die funktionieren, wenigsten in akzeptabler Geschwindigkeit. Hoffe mal die nächste GFFX ist schnell und die nächste Radeon kann viele Befehle.
Autor:  Sascha Willems [ Fr Jan 30, 2004 11:26 ]
Betreff des Beitrags: 
Ich weiß jetzt nicht ob ihr oft im OpenGL.org-Forum vorbeischaut (gehe aber mal davon aus ;) ) : Im Shaderforum hat jemand nen Auszug aus dem Entwicklerforum von Nvidia gepostet :

Irgendjemand bei NV hat geschrieben:
I'm happy to say that we will have a way to enable these extensions in the next week or so.

It should work great for development, but public drivers are not planned to have GLSL support until later in the year.


Die Registrierung ist dort zwar kostenlos, aber irgendwie doch ziemlich schwach das die erst "später im Jahr" glSlang öffentlich machen wollen. Sieht wohl wirklich so aus als wollten die ihre aktuelle Grafikkartenserie nicht bloß stellen, und erst abwarten bis sie auf diesem Gebiet konkurrenzfähige Hardware haben.

Aber ich hoffe auch das die nächste Radeon in Sachen Shaderlänge nicht mehr so eingeschränkt ist. Hab die 96-Instruktionen-Grenze nämlich schon mehr als einmal gesprengt, und in ner HLSL geschieht das ja ganz schnell.

P.S. : ATI hat NV zum ersten mal in der Geschichte in Sachen Marktanteil überholt (liegen jetzt knapp 0.2% vorne), aber Nummer 1 ist immernoch Intel...
Autor:  LarsMiddendorf [ Fr Jan 30, 2004 11:55 ]
Betreff des Beitrags: 
Naja wenigstens kann dann damit schonmal herumprobiert werden. Nur wird sich natürlich nicht jeder den Beta Treiber installieren, nur um eine Demo oder so auszuprobieren.
Bei glSlang habe ich den Verdacht, daß der ATI Treiber die Grenze oft falsch berechnet, weil Shader manchmal angeblich zu lang sind, aber bestimmt nicht 96 Befehle überschreiten, auch wenn man mit einer Zeile glSlang massenhaft Befehle erzeugen kann.
Seite 1 von 2 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/