DGL
https://delphigl.com/forum/

in Attribut verändern.
https://delphigl.com/forum/viewtopic.php?f=20&t=11421
Seite 1 von 1

Autor:  mathias [ Di Sep 01, 2015 16:56 ]
Betreff des Beitrags:  in Attribut verändern.

Ist die Veränderung von col zulässig, oder ist es nur Zufall, das es auf meinem PC geht ?
Ich wollte dies auch mit WegGL (GLSE20) machen, aber dort ist es zu einem Fehler gekommen.
Code:
  1. //Fragment-Shader
  2.  
  3. #version 330
  4.  
  5. in vec4 col;
  6.  
  7. out vec4 OutColor;
  8.  
  9. void main(){
  10.   col = col * 0.2;
  11.   OutColor = col;
  12. }

Autor:  Sascha Willems [ Di Sep 01, 2015 17:36 ]
Betreff des Beitrags:  Re: in Attribut verändern.

Eigentlich kann man input Variablen nicht verändern (siehe GLSL-Specs 4.3.4). In deinem Beispiel gehe ich aber davon aus dass der Compiler im Treiber die zwei Zeilen zu einer optimiert und die Zuweisung auf col wegfällt.

Ansonsten einfach mal mit dem Refernz GLSL-Compiler testen : https://www.khronos.org/opengles/sdk/to ... -Compiler/

Was der sagt ist Gesetz ;)

Autor:  mathias [ Di Sep 01, 2015 18:49 ]
Betreff des Beitrags:  Re: in Attribut verändern.

Dann werde ich es wohl besser in einer Variable zwischenspeichern, sonst läuft es wieder nicht auf allen PCs.

Bei deinem Link, ist die ein Shader-Testprgramm ?

Autor:  Sascha Willems [ Di Sep 01, 2015 19:58 ]
Betreff des Beitrags:  Re: in Attribut verändern.

mathias hat geschrieben:
Bei deinem Link, ist die ein Shader-Testprgramm ?


Das ist der offizielle Referenzcompiler für OpenGL (ES) Shader, also eine Referenzimplementation auf die z.B. die Treiberhersteller aufsetzen können. Da der direkt von Khronos kommt setzt er auch alle Spezifikationen 1:1 um. Wenn ein Shader also da kompiliert, dann sollte er das überall tun.

Autor:  TAK2004 [ Mi Sep 02, 2015 09:12 ]
Betreff des Beitrags:  Re: in Attribut verändern.

Ich kann auch jeden anderen nur empfehlen den Referenz Compiler in die Build Pipeline mit ein zuarbeiten.
In einem vergangenem Projekt hatten wir den über cmake mit angebunden und jedes mal, wenn wer an einer den Shadern was geändert hat, hat cmake die Shader durch den Compiler gejagt.
Hat einige Probleme ersparrt und kostet weniger Zeit als die Engine zu starten.

Wie schon gesagt deckt der Compiler die Specverhalten ab und ist wesentlich sicherer als mit NV Treibern zu kompilieren und zu testen.
Meiner Erfahrung nach ist der NVidia Treiber so tollerant und optimierungsbedacht, dass er ganz schnell weit ab vom Spec agieren kann.
Der AMD Treiber hat sich bisher immer penibel an die Specs gehalten, wie der Referenzcompiler.
In dem vergangenen Projekten hatten meine Kollegen immer eine NV Karte und ich eine AMD, zum einen damit wir beide Systeme Testen können, die Tools von AMD einfach spitze und kostenfrei im vergleich zu NV und Intel sind und weil ich so ständig die groben Fehler unserer NV Nutzer fixen konnte(dafür kommt AMD immer extrem viel später mit neuen Treibern, die Hardware ist nicht gerade Energie effizient und deren SDKs sind quasi nicht mehr vorhanden).
Nach dem wir den Referenz Compiler in die Build Pipeline eingebaut hatten sind die Probleme mit falschen Shadern auf 0 gesunken und ich musste nur noch OpenGL API Fehler fixen(was Verhältnismäßig selten Änderungen hat) und grobe Performance Probleme korrigieren.

Zum Code.
Bei aktiver Optimierung wird er Zeile 10 entfernen und die Multiplikation nach Zeile 11 schieben.
Bei nicht Optimierung sollte eigentlich ein Compiler Fehler kommen.

Autor:  Sascha Willems [ Mi Sep 02, 2015 20:39 ]
Betreff des Beitrags:  Re: in Attribut verändern.

TAK2004 hat geschrieben:
Ich kann auch jeden anderen nur empfehlen den Referenz Compiler in die Build Pipeline mit ein zuarbeiten.
In einem vergangenem Projekt hatten wir den über cmake mit angebunden und jedes mal, wenn wer an einer den Shadern was geändert hat, hat cmake die Shader durch den Compiler gejagt.
Hat einige Probleme ersparrt und kostet weniger Zeit als die Engine zu starten.


Sehr schick, mach ich teilweise auch! Grade jetzt mit Vulkan und SPIR-V wird man die Shader dann ja eh durch den Referenzkompiler jagen müssen, da bietet sich sowas an. Oder alternativ evtl. über git hooks beim Commit bzw. als Prebuilt-Ereignis. Da bin ich mir noch nicht ganz sicher.

Aber egal ob man OpenGL, OpenGL ES oder Vulkan verwendet, der Referenzcompiler ist Gold wert. Wenns da geht muss man sich um die verschiedenen Hersteller i.d.R. keine Sorgen mehr machen.

Wobei ich die Tage einen sehr speziellen Fall hatte (NVidia) bei dem ein Shader der im Referenzkompiler ging und sich auch via GLSL im Treiber kompilieren lies dann zu ner fehlerhaften Pipeline geführt hat. Aber war wohl zu speziell ;)

Autor:  yunharla [ Do Sep 03, 2015 08:28 ]
Betreff des Beitrags:  Re: in Attribut verändern.

Ist generell ne gute Idee wenn man mit solchen Ressourcen arbeitet die durch einen Compiler gehen. Wir haben auch noch Office
mit angeschlossen um beliebige Workflows zu triggern. Das spart dann so pi mal Daumen 60% der Doku-Arbeit. Fuer uns ist das
dann so ziemlich 1-2 PT pro Woche.

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