Registriert: Mi Aug 14, 2013 21:17 Beiträge: 588
Programmiersprache: C++
mathias hat geschrieben:
Ich kann mir vorstellen, das es noch einige hat was man noch verbessern könnte.
Du könntest z.B. die for-Schleife in GetNormal() ersetzen durch
Code:
vec3 a = P1 - P0;
vec3 b = P2 - P0;
Ist viel einfacher, tut das gleiche und ist vor allem schneller, wenn der Compiler nicht intelligent beim optimieren ist. Für das Kreuzprodukt gibt es auch eine eingebaute Funktion.
_________________ So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)
Registriert: Mi Aug 14, 2013 21:17 Beiträge: 588
Programmiersprache: C++
glAwesome hat geschrieben:
Für das Kreuzprodukt gibt es auch eine eingebaute Funktion.
*Wink mit dem Zaunpfahl* Die Funktion heißt übrigens cross().
_________________ So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)
Registriert: Mi Aug 14, 2013 21:17 Beiträge: 588
Programmiersprache: C++
Falls das missverständen wurde, möchte ich betonen, dass es keinen Performance-Vorteil bringt, durch Inlining die Anzahl der mit Semikolon abgeschlossenen Anweisungen zu reduzieren.
Beispiel:
Code:
// Variante 1
vec3 a = P1-P0;
vec3 b = P2-P0;
vec3 c =cross(a,b);
// Variante 2
vec3 c =cross(P1-P0, P2-P0);
Beide Varianten werden zu exakt demselben Maschinencode kompilieren und daher gleich schnell laufen. In solchen Fällen ist daher stets die übersichtlichere oder besser wartbare Variante zu bevorzugen. Welche das ist, darüber kann man streiten.
Ebenso sind Zuweisungen als kostenlos zu betrachten, wenn sie keinerlei Rechenoperationen beinhalten, sondern nur kopieren:
Code:
vec4 p0 = gl_in[0].gl_Position;
Solch triviale Sachen optimiert der Compiler sowieso weg. Deine "Verbesserung" der main-Funtion bezüglich der Parameter von GetNormal() ist also keine (jedenfalls nicht in Bezug auf Geschwindigkeit).
_________________ So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2621 Wohnort: Berlin
Programmiersprache: Go, C/C++
glAwesome hat geschrieben:
Falls das missverständen wurde, möchte ich betonen, dass es keinen Performance-Vorteil bringt, durch Inlining die Anzahl der mit Semikolon abgeschlossenen Anweisungen zu reduzieren.
Beispiel:
Code:
// Variante 1
vec3 a = P1-P0;
vec3 b = P2-P0;
vec3 c =cross(a,b);
// Variante 2
vec3 c =cross(P1-P0, P2-P0);
Beide Varianten werden zu exakt demselben Maschinencode kompilieren und daher gleich schnell laufen. In solchen Fällen ist daher stets die übersichtlichere oder besser wartbare Variante zu bevorzugen. Welche das ist, darüber kann man streiten.
Ebenso sind Zuweisungen als kostenlos zu betrachten, wenn sie keinerlei Rechenoperationen beinhalten, sondern nur kopieren:
Code:
vec4 p0 = gl_in[0].gl_Position;
Solch triviale Sachen optimiert der Compiler sowieso weg. Deine "Verbesserung" der main-Funtion bezüglich der Parameter von GetNormal() ist also keine (jedenfalls nicht in Bezug auf Geschwindigkeit).
Dazu will ich noch als Hinweis geben, dass Optimierungen nicht aus einem gemeinsammen Compiler passieren, sondern jeder Grafikkarten Hersteller eigene Treiber mit eigenen Compilern liefert und die Qualität der Optimierung geht von wahnsinn bis gar keine. Apple's iOS Shader Compiler z.b. konnte bis zur meiner letzten nutzung(knapp 1-2Jahren) nix, nicht mal das obige Beispiel oder if(true)... else ... optimieren. Unity3D hat extra deswegen ein Shader Optimizer geschrieben, der auf den Mesa Parser und Optimizer basiert, weil dies auch wohl auf den meisten Android Geräten der Fall war. Da der immer noch für alle Mobile Platformen aktive verwendet wird, geh ich davon aus, dass dies wohl immer noch der Fall ist. Die Optimierungen kann man sich also nur sparen, wenn man explizit auf Nvidia, Intel und AMD Karten setzt. http://developer.amd.com/tools-and-sdks/graphics-development/gpu-shaderanalyzer/ kann helfen aber seit 2Jahren auch nicht mehr geupdated wurden, schätze es ist ein Teil von CodeXL nun und ich find es einfach unter den vielen anderen Tools ned :\
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2621 Wohnort: Berlin
Programmiersprache: Go, C/C++
CodeXL kann Shader Debugging, ich hab es noch nicht benutzt, weil ich noch auf mein AMD System warte aber in der Tutorial Sektion von der Hilfe wird es Schritt für Schritt erklärt und das gab es auch schon im vorigen gDebugger.
Auf der GDC2014 war ein Talk von Nvidia wo die Speaker Optimierungspunkte erklärt haben und bei Shadern meinte der eine, dass die wichtigste Optimierung das parallelisieren des Shaders ist. Es gibt in der Shader Language Funktionen die synchronisieren müssen, auf Werte zurück greifen, die ein Warten auslösen und natürlich Hardware bedingte Sync. Operationen wie z.B. Texel zugriff. Dies sind Hotspots und für diese muss man optimieren, weil diese das skalieren auf Grakas reduzieren. Ein gutes Beispiel ist z.B. Texels aus verschiedenen Blöcken einer DXT Textur zu zugreifen, das erzeugt mehr Cache misses und die Shader Unit muss für ein VRAM Sync warten. Je mehr Shader Units aus dem gleichen Texturblock lesen, je höher die Performance, weil zum einen kein Sync passiert und zum zweiten der Cache um längen schneller ist als VRAM. So kann also ein schlecht gewählter noise lookup für SSAO starke Performanceunterschiede hervor rufen. Es ist ab einer zu testenden Reichweite schneller ein horizontalen blur über mehere Schritte nacheinander zu machen als in ein Step und gleiches für den vertikalen Schritt.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Mi Aug 14, 2013 21:17 Beiträge: 588
Programmiersprache: C++
OpenglerF hat geschrieben:
Nvidia bietet auch noch Nsight, das unter-anderem Shader-Debugging erlaubt. CodeXL sollte das, soweit ich weiß, nicht beherrschen.
Wann gibt es diese Tools endlich als Standalone? Ich habe und will kein Visual Studio/Eclipse...
OpenglerF hat geschrieben:
Bei der Gelegenheit möchte ich auch nochmal darauf hinweisen das auf halbwegs moderner Hardware auch auch "cross" und die meisten solcher Funktionen grundsätzlich erstmal keinen Performancevorteil bieten.
Dennoch sollte cross() verwendet werden. Diese eingebauten Funktionen sind alle optimal, d.h. es ist nicht möglich, die Funktionalität mit anderem Code nachzubauen, der schneller läuft. Der Nachbau von solchen Funktionen kann also höchstens gleich schnell sein. Und dass aktuelle Nvidia-Hardware skalar statt vektoriell arbeitet, mag derzeit stimmen, jedoch gibt's auch noch ältere Hardware und in Zukunft kann das auch wieder anders aussehen. Und bei anderen Herstellern ist es vielleicht auch anders. Nur damit sich hier niemand berufen fühlt, eingebaute Funktionen nicht zu benutzen.
Edit: Habe jetzt das Dokument http://www.humus.name/Articles/Persson_LowLevelThinking.pdf durch. Wenn das (auch für OpenGL) stimmt, was da steht, sollten neue OpenGL-Versionen hier ansetzen. Es kann doch wohl nicht wahr sein, dass ein Shader-Compiler unter dem Vorwand der IEEE-Kompatibilität solche einfachen Zusammenhänge nicht erkennt:
Standardmäßig sollte der Compiler floats mathematisch als reelle Zahlen betrachten und keine Rücksicht auf eventuelle Genauigkeitsfehler aufgrund der endlichen Genauigkeit usw. nehmen. Das ist das, was man als Programmierer in 99% der Fälle will. Falls man es wirklich exakt haben möchte, kann man immer noch ein #pragma precise oder so einfügen. Ich habe jedenfalls als Entwickler keine Lust, die Folgen dieses Unsinns durch mühsame Handarbeit auszubaden.
_________________ So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)
Mitglieder in diesem Forum: 0 Mitglieder und 4 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.