| DGL https://delphigl.com/forum/ |
|
| UnifomBlockObject https://delphigl.com/forum/viewtopic.php?f=20&t=11450 |
Seite 4 von 4 |
| Autor: | Sascha Willems [ Do Nov 12, 2015 20:06 ] |
| Betreff des Beitrags: | Re: UnifomBlockObject |
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. |
|
| Autor: | mathias [ Do Nov 12, 2015 20:41 ] |
| Betreff des Beitrags: | Re: UnifomBlockObject |
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 ? |
|
| Autor: | Sascha Willems [ Do Nov 12, 2015 20:49 ] |
| Betreff des Beitrags: | Re: UnifomBlockObject |
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. |
|
| Autor: | mathias [ Do Nov 12, 2015 21:07 ] |
| Betreff des Beitrags: | Re: UnifomBlockObject |
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 ? |
|
| Autor: | Sascha Willems [ Do Nov 12, 2015 21:09 ] |
| Betreff des Beitrags: | Re: UnifomBlockObject |
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. |
|
| Autor: | glAwesome [ Do Nov 12, 2015 21:54 ] |
| Betreff des Beitrags: | Re: UnifomBlockObject |
@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. |
|
| Autor: | mathias [ Fr Nov 13, 2015 16:43 ] |
| Betreff des Beitrags: | Re: UnifomBlockObject |
Zitat: 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. 
|
|
| Seite 4 von 4 | Alle Zeiten sind UTC + 1 Stunde |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|