OpenGL ARB Meeting Notes von Juni/September/Dezember

[Corrail]

Sie sind endlich online! ;)

Juni (http://www.opengl.org/about/arb/notes/meeting_note_2004-06-08.html)
September (http://www.opengl.org/about/arb/notes/meeting_note_2004-09-21.html)
Dezember (http://www.opengl.org/about/arb/notes/meeting_note_2004-12-07.html)

[mapel110]

Volunteers are needed to host meetings in June 2005 and beyond. Please email or phone Jon if you may be willing to host.

hat jemand die email oder die tel nummer? =)
können ruhig auf nen Kaffee vorbei kommen :ucoffee:

[Corrail]

EXT_framebuffer_object is done!

WO? WO? WO? *habenwill* :biggrin: :biggrin: :biggrin:

@mapel:
http://www.opengl.org/about/arb/join/index.html ;)

[zeckensack]

<...> endlich <...>Allerdings =)
Volunteers are needed to host meetings in June 2005 and beyond. Please email or phone Jon if you may be willing to host.

hat jemand die email oder die tel nummer? =)
können ruhig auf nen Kaffee vorbei kommen :ucoffee:Steht am Anfang der Notes. Jon Leech, ljp 'at' sgi.com.

[RLZ]

EXT_framebuffer_object is done!
Es ist vollbracht *freu*

http://www.planetsmilies.com/smilies/party/party22.gif

[Asmodeus]

Was denkt ihr, wie lang wird es noch dauern, bis man EXT_framebuffer_object in eigenen Programmen nutzen und das unsägliche Wort PBuffer endlich aus dem eigenen Wortschatz streichen kann? :wink:

Gruss, Carsten.

[Asmodeus]

Folgende Sache bringt mich allerdings etwas ins Grübeln:


September meeting:

Instancing geometry - DX has an explicit API with per-primitive and per-vertex attributes, allowing instancing primitives with different per-vertex attributes. Pat notes that setting attributes in immediate mode outside of glBegin/glEnd can accomplish this already.

December meeting:

Instancing geometry - no need, GL immediate mode rendering calls support this. Khronos may want to engage on this, though, since they don't have finegrained immediate mode calls.


Kann man die beiden Sachen (instancing unter DX und instancing mit Hilfe von immediate mode calls unter OpenGL) denn überhaupt vergleichen, vorallem von der Performance her? Wäre unter OpenGL ein Instancing auf VBO-Ebene nicht das einzige, was von der Performance her überhaupt interessant wäre, oder überseh ich da jetzt was?

Gruss, Carsten.

[marco42]

Folgende Sache bringt mich allerdings etwas ins Grübeln:



Kann man die beiden Sachen (instancing unter DX und instancing mit Hilfe von immediate mode calls unter OpenGL) denn überhaupt vergleichen, vorallem von der Performance her? Wäre unter OpenGL ein Instancing auf VBO-Ebene nicht das einzige, was von der Performance her überhaupt interessant wäre, oder überseh ich da jetzt was?

Gruss, Carsten.

schau mal unter Opengl Forum (http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012910) nach, da wird das gerade diskuttiert, sogar mit beispielen.

[Asmodeus]

schau mal unter Opengl Forum (http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012910) nach, da wird das gerade diskuttiert, sogar mit beispielen.

Also das Ergebnis von MZ dort im Forum find ich persönlich schon sehr überraschend:


I made a little test app.

GeForce 5200, Athlon XP 1700 (1400 MHz)
icosahedron model stored in display list (20 triangles, 12 verts)
20000 instances drawn each frame
screen size of each: ~15 pixels
dumb vertex shader (MVP matrix multiply preceded by single vec4 add)
dumb fragment shader (constant color)
no blending, etc.

two paths of the innermost drawing loop resemble my A & B pseudocode above: no state changes between drawing instances other than single uniform/attribute.

assembly output shows B needs one VP instruction more than A (6 vs 5)

results:
A, "uniform" mode: 5.25 fps
B, "attribute" mode: 33 fps
...


Könnte das vielleicht mal jemand in eigenen Programmen auf Reproduzierbarkeit nachprüfen? Ich hab dazu bei meinen Programmen leider erst nächstes Jahr wieder Gelegenheit.

Aber bisher hab ich mich bei der Programmierung auch immer einfach an den Spezifikationen zur Granularität orientiert, "Uniforms" für alles bis zu einer Granularität auf Primitive-Ebene und "Attributes" für eine Granularität auf Vertex-Ebene. Aber bei dem Beispiel von MZ hat es ja den Anschein, als wären "Attributes" von der Performance her immer der Vorzug zu geben, wenn es sich um zu übermittelnde Parameter handelt die nur im Vertexprogramm ne Rolle spielen. Und auf "Uniforms" sollte man dann also nur zurückgreifen, wenn es sich um Parameter handelt, die auch, oder ausschließlich an Fragmentprogramme übergeben werden? Bisher war mir das so nicht bewusst, euch etwa?

Gruss, Carsten.

[marco42]

naja, du hast ja wesentlich mehr max uniforms als attributes. ausserdem bringt das AFAIK nur was bei sehr kleinen objecten. ich bin da kein experte aber ich nehme mal an, dass bei uniform aenderungen ein paar nop's entstehen, die du bei attributen nicht hast. es bringt dann nur was bei wirklich kleinen objecten.

[Demirug]

Es ist eigentlich kein Wunder das die Attributes schneller sind als die Uniforms. Das verändern von Uniforms ist eine Veränderung auf Shaderebene die nicht einfach zu einen beliebigen Zeitpunkt durchgeführt werden kann. In der Regel gibt es nur einen Konstanten Speicher (CineFX Fragmentshader sind da ein wenig anders aufgebaut) auf den alle Verticen die in Bearbeitung sind zugreifen. Eine änderung kann also nur erfolgen wenn kein Vertex mehr in Bearbeitung ist der auf den alten Wert zugreifen muss. Im schlimmsten Fall müssen auch noch die Pre und Post Caches leer sein. Das kostet dann ein paar Takte was bei grossen Objekten mit vielen Verticen nicht auffällt aber bei kleinen schon.

Benutzt man dagegen Attribute bekommt der Shader das ganze in der Art eines einizen grossen Objekts presentiert und kann ohne Unterbrechnung durcharbeiten.

Die Frage ist allerdings was der OpenGL Treiber genau macht. Im Zweifelsfall rollt er das ganze nämlich wirklich auf. Die wichtige Frage in diesem Fall wäre auch noch die CPU Belastung.

PS: Schon jemand bemerkt das man mit einem NV40 jetzt 4 Aux Buffer hat?

[marco42]

Die Frage ist allerdings was der OpenGL Treiber genau macht. Im Zweifelsfall rollt er das ganze nämlich wirklich auf. Die wichtige Frage in diesem Fall wäre auch noch die CPU Belastung.


Wie meinst du das mit aufrollen? wenn ich das attribute per glVertexAttrib setze, warum sollte das aufgerollt werden?


PS: Schon jemand bemerkt das man mit einem NV40 jetzt 4 Aux Buffer hat?

Stand das nicht in den dokus von nvidia, bloss habe ich keinen pbuffer anfordern koennen, der dass konnte. :-(

[Demirug]

Wie meinst du das mit aufrollen? wenn ich das attribute per glVertexAttrib setze, warum sollte das aufgerollt werden?

Mit aufrollen meine ich das es nicht nur einmal für alle nachfolgenden Verticen geschickt wird sondern in jeden Vertex einkopiert wird.

Wobei es zu der Thematik ein Whitepaper und eine Demo von nVidia gibt wie man es in OpenGL machen soll. Habe ich aber noch nicht gelesen.

Stand das nicht in den dokus von nvidia, bloss habe ich keinen pbuffer anfordern koennen, der dass konnte. :-(

Ausprobiert habe ich es nicht sondern nur in den Formatbeschreibungen gesehen.