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.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
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.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
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.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
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.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
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
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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.
Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.