Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
mathias hat geschrieben:
Ich will aber gerne kompatibel zu OpenGL3.3 bleiben.
Wenns um ein privates Projekt geht würde ich das nicht machen. Da fehlt so viel, grade wenn man modernes OpenGL machen will sollte man min. 4.3 voraussetzen.
mathias hat geschrieben:
Irgendwie wird das ganze sehr kompliziert, um es in meine Classen zu integrieren.
Du ziehst die Sache auch falsch auf. Statt jeden Mesh mit eigenen Shadern zu verknüpfen sollte man besser Pipelines bauen die Shader und Bindings vorhalten und die mit den Meshes verknüpfen. Dann hat man z.B. eine Pipeline für Phong Beleuchtung die von 10 Meshes benutzt wird, eine Pipeline fürs Normal Mapping die andere Shader nutzen, etc. Das ist bei den neuen APIs ja auch so und nicht ohne Grund. Damit ist man viel flexibler als wenn man Meshes direkt mit den Shader verknüpft.
So wie es aussieht, werde ich die UBOs auf Eis legen und mit den normalen Uniforms arbeiten.
Zitat:
Wenns um ein privates Projekt geht würde ich das nicht machen. Da fehlt so viel, grade wenn man modernes OpenGL machen will sollte man min. 4.3 voraussetzen.
Das Problem, es hat leider noch viele ältere Kisten im Umlauf. Aber ich werde mir die neunen Funktion schon genauer angucken.
Zitat:
Damit ist man viel flexibler als wenn man Meshes direkt mit den Shader verknüpft.
Da hast du eigentlich recht. Ich könnte mir von Anfang an Shader laden welche meisten gebraucht werden und der Mesh sagen welcher es nehmen soll. Es wir eine rechte Sammlung geben, ohne Textur, einfaches Texturing, Multexturen Bumpmaping, verschiedene Beleuchtungen, etc. Kleiner Wermutstropfen es werden Shader geladen, welche vielleicht nie gebraucht werden.
Vielleicht kommt mir noch eine gute Idee, wie ich das lösen kann.
So neben beim, wie gross ist der Geschwindigkeitsvorteil von UBOs, gegenüber den normalen Uniforms ?
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
mathias hat geschrieben:
So neben beim, wie gross ist der Geschwindigkeitsvorteil von UBOs, gegenüber den normalen Uniforms ?
Uniforms muss man ja immer einzeln suchen und an die GPU übergeben, bei einem UBO kann man halt direkt in einen Buffer schreiben. Das ist natürlich ein gutes Stück schneller.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
mathias hat geschrieben:
Zitat:
Uniforms muss man ja immer einzeln suchen
Macht man dies nicht nur einmal mit glGetUniformLocation wen man einen neuen Shader erzeugt ? Oder braucht glUniformxxx sehr viel Zeit ?
Ja, die Location sucht man nur einmal. Aber das Übergeben der Daten via glUniform... dauert natürlich viel länger als das direkte Schreiben in den Speicher eines gemappten UBOs. In neuen APIs gibt es den Weg daher auch gar nicht mehr.
Registriert: Mi Aug 14, 2013 21:17 Beiträge: 588
Programmiersprache: C++
@OpenGL-Version: Das Problem sind nicht nur "alte Kisten", sondern auch alte Treiber bzw. open-source Treiber. Da ist 3.3 immer noch der größte gemeinsame Nenner. In der MesaMatrix tut sich zwar einiges, aber bis diese Änderungen auch in Ubuntu LTS Distributionen und dergleichen angekommen sind, dauert es halt. Was man aber gut machen kann, ist einen 3.3 Kontext anzufordern und einige einzelne 4.x-Extensions mit hoher Verbreitung zu nutzen (wie z.B. GL_ARB_explicit_uniform_location).
@UBO: Ein echter (Geschwindigkeits-)Vorteil entsteht doch eigentlich erst dann, wenn man das selbe UBO in mehreren Shadern einsetzt, die sich die Uniforms darin teilen. glUniform an sich ist im Vergleich mit anderen GL-Calls schon ziemlich schnell (gab mal irgendwo Slides von Nvidia dazu*). Wenn du natürlich dutzende Variablen einzeln setzt, ist es dennoch suboptimal. Aber es gibt ja auch die Möglichkeit, ganze Arrays mit einem einzigen glUniform zu erschlagen.
*Edit: Habe die Präsentation wiedergefunden. Wie man außerdem sieht, sind Programwechsel sehr teuer. Allein deswegen ist es schon keine gute Idee, jedem Mesh ein eigenes Program zu geben.
_________________ So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)
Wie man außerdem sieht, sind Programwechsel sehr teuer.
Dann müsste mein alter Atom mit über 800 Meshes ins stottern kommen, aber läuft ohne einen Rukkler.
Zitat:
Aber es gibt ja auch die Möglichkeit, ganze Arrays mit einem einzigen glUniform zu erschlagen.
Das wäre noch eine Alternative, das die Beleuchtung fast nu aus vec4 besteht. Eigentlich Schade, da man keine Records mit glUniform übergeben kann. glUniformR(@MyRecord, SizeOf(MyRecord)) wäre ein guter Befehl.
Mitglieder in diesem Forum: 0 Mitglieder und 3 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.