Ich hatte heute morgen irgendwie das Verlangen mich mal wieder mit einer recht neuen Extension auseinanderzusetzen, zu der nicht bereits dutzende Demos im Netz rumschwirren, und hab mich dann dazu entschieden GL_ARB_VERTEX_BUFFER_OBJECT zur Darstellung von statischer Geometrie in Form einer Heightmap zu nutzen, da man damit ja besonders auf moderner Hardware nen recht hohen Dreiecksdurchsatz erreichen kann.

Die Implementation selbiger Extension lief dann auch recht einfach ab, und worum es mir hier in diesem Posting eigentlich geht ist der Dreieckdurchsatz.
Eine Radeon9700 (auf meinem AthlonXP 2600+) hat einen Peakdurchsatz von knapp 180 MTris/s (laut Datenblättern), und meine Anwendung schafft mittels VBOs einen Dreiecksdurchsatz von knapp 150MTris/s bei einer Heightmap mit 2 Millionen Dreiecken (alle anderen Größen darunter bringen weniger Durchsatz, VBO-Typ = GL_STATIC_DRAW_ARB).

Jetzt gibts hier im Forum ausser mir sicher noch einige andere Personen die bereits diese Extension genutzt haben, und deshalb wollt ich mal rundfragen wies bei euch mit dem Dreiecksdurchsatz aussieht, und ob ihr hier auf entsprechender Hardware höhere Durchsatzraten bekommt, denn immerhin fehlen mir bis zum "Optimum" noch knapp 30MTris/S, und sowas verschenkt man ja nur ungerne

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Also ich habe damit bisher auch schon ein bisschen gemacht. Und 180 MTris/s sind schon sehr anständig. 8)
Tom Nuydens hat auch seiner Seite eine Demo gemacht und dazu solltest dir mal die Kommentare ansehen. http://www.delphi3d.net/forums/viewtopic.php?t=154
Da sind einige interessante Results drin. Ich habe mit einer Radeon 9500 Pro und einem Duron 1200 einen Durchsatz von 107 MTris/s

In meinem Programm hatte ich es so gemacht, dass alles in einem VBO liegt. Dabei konnte ich feststellen, dass bei einem Heightmap ab 1024x1024 die Performance auf ca. 10MTris/s sinkt. Das war allerdings noch mit einem recht alten Treiber (Catalyst 3.4). Es kann sein, dass das in neueren Versionen nicht mehr so extrem ist.
Im Normalfall habe ich aber zwischen 80 und 90 MTris/s bei einem Heightmap von 786x786. Wenn ich mehrere größere VBO's verwenden würde so würde ich sicherlich einen noch höheren Datendurchsatz erreichen (da auch mehr Daten vorhanden wäre). Allerdings bin ich mit dem Ergebniss ganz zu frieden vor allem wenn ich bedenke, dass ich noch einen glOrthomodus mit verwende. Der bremst auch noch mal um ca. 10%.

Aber das mit dem weniger Durchsatz bei weniger Daten konnte ich auch super feststellen. Bei ATI's sind wahrscheinlich die Aufrufe wesentlich Zeitintensiver als die eigentlichen Tätigkeiten. Bei dem Demo von Tom hatte ich auch Spaß mal die Anzahl der Flächen halbiert und siehe da die FPS war immernoch gleich. Nur der Durchsatz ist dann auch auf die Hälfte gesunken.

PS: Mit dem neusten Treiber unterstützt sogar eine TNT2 VBO's
Diese werden allerdings nur durch den Treiber emuliert, denn diese sind dort genau so "schnell" (langsam) wie Displaylisten, VertexArrays oder Iterativ.

Mit der Performance bin ich auch auf jeden Fall zufrieden, fehlen mir doch nur knapp 17% bis zum Peakdurchsatz meiner R9700.
Ich konnts mir auch nicht nehmen lassen, die VBO-Performance auf meiner Karte mal mit verschiedenen VBO-Größen zu testen und hab dann auch noch ein Diagramm in Excel erstellt welches es im Anhang zu "bestaunen" gibt.

Wie zu erkennen fühlt sich der R300 wohl im Bereich um die 2 Millionen Polygone herum recht wohl, und lässt danach ein wenig nach.Das letzte VBO welches ich testen konnte war (Siehe Tabelle) 123MByte groß, alles darüber scheint wohl nicht mehr in den Speicher der Karte zu passen und bereitet ihr dann schwere Probleme (10MTris/s, schwere Darstellungsprobleme), aber solch große Vertexdaten findet man wohl im Consumerbereich recht selten (>6 Millionen).
Natürlich sind diese Ergebnisse nur dann zu gebrauchen wenn man auch nur ein einziges riesiges VBO nutzt, denn durch die Nutzung mehrerer VBOs dürfte sich nochmal drastisch was ändern.

Was micht aber immer wieder erstaunt, ist die Tatsache das selbst eine recht "alte" Grafikkarte wie die R9700 ohne Mühe über 150 Millionen texturierte (!!!) Dreiecke berechnen kann (und das bei brauchbaren Frameraten), während mein erster 3D-"Beschleuniger" anno 1996 (ELSA Victory3D, S3-Virge, 4MByte EDO) nur wenige tausend Dreicke per Frame berechnen konnte, und dazwischen liegen nur knapp 6 Jahre...

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Tom Nuydens hat auf seiner Seite noch etwas anderes. Er lädt dort ein riesiges Model einer Fabrik in was weiß ich nicht wie viele VBO's es sind so viele, dass diese nicht alles sammt in den Speicher der Graka hinein passen. Bei dem Catalyst 3.5 bricht er glaube ich ab. Es kann auch sein, dass es der 3.6er war. Bin mir da nicht so ganz sicher. NVidia lagert alles dort nicht hinein passt in den Haupspeicher aus. Er verwendet allerdings generell nur VBO's die ca 0.5 MB groß sind.


Das ist in der Tat sehr erstaunlich. Ich bin auch mal gespannt wo das noch hinführen soll. Allerdings bin ich der Meinung, dass die Spieleindustrie von solchen Technologien nur recht wenig gebrauch macht bzw. Gebrauch machen kann. Weil solche Dinge teilweise anders interpretiert werden. Siehe Ergebnisse bei Tom's Demo. Und weil die VBO's leider nicht überall einsetzbar sind.
Für eine Landschaft sind die Perfekt. Da renderst du alle VBO's die irgendwo angezeigt werden müssten. Du rendest vielleicht die doppelte Menge an Flächen aber das ist immer noch schneller als per Algorythmus so eine Hand voll Flächen ausschließen zu können. Allerdings sobald das dann noch auf älteren System (GF1/2) zum Einsatz kommt haben die Leute wieder verlohren. Ein Teufelskreis. Man müsste das so machen wie bei Doom 3. Rausfinden was für Hardware da drinne steckt und dann speziell für Hardwaregruppen einen eigenen Renderpfad. Aber welche Firma könnte sich so etwas schon leisten. Teufelskreis 2.

Sit die Anzahl der VBOs eigentlich begrentzt? Denn mann könnte ja dann hergehen, einen Octree mit recht toleranter Polygon-Anzahl erstellen und jeden Leaf in einem eigenen VBO ablegen. Somit hätte man eine recht schnelle und eifnach gestrickte Engine. Mann müsste zwar für die kollisions-Berechnung das komplette Level nochmal im Hauptspeicher haben, aber was sind ein paar MB RAM für bessere Speed?

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Das ist auf jeden Fall eine recht geile Lösung für so was. Allerdings beziehen sich meine Angaben (schätze mal die von SOS auch) alle auf TRIANGLE_STRIPS. Ich weiß nicht wie schnell VBO's mit TRIANGLES wären. Habe nur gerade keine Möglichkeit das mal zu testen.

PS: Die Anzahl ist meines wissens nur durch die Größe der ID begrennzt. (uint) Also irgenwas an die sehr viel.
Ähmmm nein. Ist nicht begrenzt.

@SchodMC :
Ganz genau, VBOs sind für Sachen wie Octrees oder Terrainchunks (auch für Geo-MipMapping) geradezu prädestiniert, und haben den Vorteil das sie im Gegensatz zu einer Displayliste bei Bedarf auch noch verändert werden können.Ich hab sowieso grade vor ne "Landschaftsengine" zu schreiben die auf VBOs und Terrainchunkgs basiert, und die dürfte besonders auf ner modernen Grafikkarte ohne jeglichen LOD (bis aufs Frustum-/Distanzculling der Chunks) sehr schnell laufen, da es ja quasi keinen CPU-Overhead mehr gibt.
Ausserdem sollte es von der Geschwindigkeit her kaum einen Unterschied machen ob du jetzt ein riesiges VBO verwendest, oder viele kleine VBOs.Solange ma Ende die gleiche Polygonzahl rauskommt dürften sich beide Varianten in Sachen Durchsatz nichts nehmen, allerdings hast du bei vielen kleinen VBOs logischerweise nen größeren Overhead, der allerdings kaum interessant sein dürfte.
Edit : Hab ganz vergessen zu erwähnen, das man die Vertexdaten nachdem sie als VBO an GL übergeben wurden wieder aus dem Hauptspeicher löschen kann.Das geht zwar bei ner DL auch, allerdings kann man die VBO-Daten dann immernoch ohne die Vertexdaten im Hauptspeicher im Nachhinein verändern.

@LossyEx :
Ich muss dich leider "enttäuschen" , denn der Primitiventyp scheint wohl nicht viel auszumachen, was aber bei einem VBO vom Typ GL_STATIC_DRAW_ARB daran liegen kann, das es ähnlich wie ne DL beim Hochladen omptimiert wird, denn ich nutze in meiner kleinen Demo weder Tris noch Tristrips sondern einfach nur QUADS.

Habs übrigens gestern Abend geschafft ganz genau an das Limit meiner R9700 zu kommen, in dem ich meine 2 Millionen-Dreieckelandschaft neunmal in einem Frame zeichne (jeweils gespiegelt und verschoben).Das läuft dann zwar nur mit 10fps, allerdings komm ich dann dank 18 Millionen sichtbarer Dreiecke auf einen Durchsatz von stolzen 179MTris/s.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich habe das vor eingier Zeit mal auf einer GF4 getestet und da ist mir aufgefallen, daß die Dreiecksanzahl stark von der Vertex Größe abhängt. Deshalb ist es schade, daß die Radeon außer beim Color Array nur noch gl_float als Format unterstützt. Außerdem hat es etwas gebracht, die Dreiecke/Quadrate in größere Quadrate zu gruppieren, anstelle lange Streifen zu zeichnen. Das liegt vermutlich am Vertex Cache. Bei der GF4 konnte man soviele Buffer erstellen wie man will, daß ging sogar soweit, daß die Buffer in die Auslagerungsdatei verschoben wurden.
Im Gegensatz zu D3D sind Bufferwechsel schnell, nur man soll glDrawElements immer mit einer gewissen Mindestanzahl von Dreiecken aufrufen.
Meistens ist man ja sowieso durch die Füllrate gebunden und deshalb denke ich auch, daß man eher ganze Gruppen von Dreiecken cullen sollte, anstelle von einzelnen.
Bei http://users.belgacom.net/xvox/ gibt es eine D3D Demo, die mit einem Vertex Program CLOD auf einer Landschaft berechnet. Über die CPU sollte man die Punkte im VBO am besten gar nicht mehr ändern, weil Zugriffe auf den Videospeicher langsam sind.

Hab' mal gelesen, das der Treiber von NVidia mit VBOs noch nicht so ganz optimiert wäre. Stimmt das?

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Ja, zumindest bevor ich zum ATI-Lager gewechselt bin war die VBO-Performance auf meiner GF4-Ti4400 (Detonator 44.xx) recht grottig und um den Faktor 10 schlechter als bei meiner R9700.Allerdings gehe ich mal davon aus das NVidia da mit einem der nächsten Treiberreleases wohl noch etwas nachhelfen werden.

Hab mich übrigens noch ein wenig eingehender mit VBOs beschäftigt und mich richtig über die Funktion glMapBufferARB gefreut, mit der man von OpenGL direkt nen Pointer auf das VBO bekommt und über diesen dann auch direkt Vertexdaten "in" das VBO hineinschreiben kann.Das ganze hat den großen Vorteil (solange man die Daten nicht für z.B. Kollision braucht), das man die Vertexdaten erst gar nicht in den Hauptspeicher einlesen (und dort zwischenspeichern) muss, sondern diese direkt in das VBO schreiben kann.Meine Demo durchläuft also die Heightmap in Form eines TBitmaps und schreibt dann die Vertexe (+Texturkoordinaten) über den VBO-Pointer direkt in den Grafikkartenspeicher.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich freu mich besonders über die VBOs, da das fehlen einer solchen Funktionalität im gegensatz zu D3D IMO ein groses Manko war. Nur gut, dass sich das nu erledigt hat!

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?

Bei der Verwendung von gl_short als Vertex Attrib Array Format sinkt bei mir der Dreiecksdurchsatz unverhältnismäßig auf 12% des Wertes mit gl_float als Format. Die Test Szene besteht nur aus ca 100 Dreiecken und ist damit nicht gerade polygonlastig aber genau darum ist es sehr seltsam. Das Problem scheint wohl an dem gl_short zu liegen, obwohl das Format in der Optimization Guide angegeben ist. Mich würde intressieren, ob das jemand bestätigen kann. In der VBO Spezifikation wird gl_short nämlich nicht verlangt. Die Grafikkarte ist eine Radeon 9800 pro mit Catalyst 3.7.