Da ichs nicht in den Projektethread hänge wollte mach ich hier nen entsprechenden Thread auf.



Schande über mein Haupt, das stimmt ja. Keine Ahnung wie ich mich so vertun konnte, aber nach der Korrektur (habe ne extra PolyCount-Variable eingefügt) kommen knapp 40 MTris/s raus, was wohl eher der Wahrheit zu entsprechen scheint und somit stark unter dem Limit der Karte liegt. Liegt aber evtl. auch an den interleaved Arrays, also werde ich mal sehen ob sich da irgendwo was steigern lässt.

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

Habe meinen Beitrag mal verschoben. Die Meinungen gehören ja ins extra Forum:

Ich habe alle Tests mal durchlaufen lassen und bei mir scheint 32MB auch die Grenze zu sein. Allerdings kommt die VBO Demo von SoS bei mir auf 210 MTris/s, so daß vermutlich nicht die optimalsten Kombinationen getestet werden. Vielleicht sind viele einzelne Quads die für den Vertex Cache günstig angeordnet sind, für die Karte besser als Triangle Strips.

--------------
Es gibt da noch eine VBO Demo von Delphi3D.net. Die kommt bei mir auf immerhin 160 MTris/s. Es wird da aber nur Farbe und Position verwendet(GL_C4UB_V3F). Eigentlich müßten die Formate, bei denen die Vertexdaten hintereinander in einem Buffer liegen schon wegen des Caches optimal sein, solange der Buffer die 32MB Grenze nicht überschreitet.

Bei der Demo von Delphi3D bekomme ich nach dem Starten 90Mtris, die sich durch geschicktes Wählen des Bildausschnitts erstaunlicherweise auf bis zu 120Mtris erhöhen lassen. (was ich ehrlich gesagt nicht verstehe, weil die Grafikkarte eigentlich nicht Füllratenlimitiert sein sollte und auch nicht selbst cullt oder?)
Wenn ich ähnliche Einstellungen in meinem Tool wähle (GL_4CUB_V3F, Indexed&Vertex Buffer, 2000.000 Tris und weniger als 200 DrawCalls) dann bekomme ich auch 90MTris. Das ist allerdings auch nicht besser, als wenn man die TriStrips einfach als Interleaved Array rendern lässt. Eigentlich klar, denn ein Tristrip ist schon ziemlich optimal, da immer 2 von 3 benötigten Vertices schon im Cache vorhanden sein müssten. (Umso erstaunlicher, dass die Performance nicht immer gleich ist. Bei 32byte großen Vertices (Pos/Tex/Nrml) liegt die Indexed&Vertex Bufferlösung 40% vorn obwohl die 32Mb Grenze nicht überstiegen wird. Hat einer ne Idee?)

Aber mal was ganz anderes: Wenn man ein Modell rendert oder irgendetwas ähnliches, dann hat man nur ziemlich selten TriStrips. Vielleicht sollte man den Performance-Vergleich besser mit abgeschlossenen Tris (GL_TRIANGLES) durchführen um einen praxisnäheren Vergleich zu haben? SoS Demo mit den Quads deutet ja schon an, dass die Performance dann wesentlich schlechter ist!
Und wo wir schon bei Praxisnähe sind, da sind die Modelle ja meist viel kleiner. Ein interessanter Vergleich wäre noch, wie sich viele Würfeln in einzelnen VBO's im Vergleich zu einem großen gemeinsamen Buffer schlagen. Das könnte ziemlich wichtig werden, für die Entscheidung ob eine Engine Vertexdaten zentral verwaltet oder jedes Objekt seinen eigenen Buffer hat.

_________________
Selber Denken macht klug!

VBOs sind so ausgelegt worden dass es keinen (kaum) Unterschied macht ob man einen großen Puffer rendert (in dem dann z.B. alle Objekte liegen) oder viele kleinere Buffer. Das Wechseln zwischen den VBOs geht nämlich recht flott und ist kaum bemerkbar. Wenn man VBOs nutzt spielt es also keine Rolle ob es wenige große sind oder viele kleine, wichtiger sind da dann andere Sachen wie Texturen- oder Shaderwechsel. Da machts natürlich Sinn z.B. nach Textur bzw. Shader sortierte VBOs zu erstellen.

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

Macht Sinn und deckt sich auch mit meinen Erfahrungen soweit, auch die Zahl der DrawCalls spielt kaum eine Rolle. (außer bei der Kombination aus Index & Vertexbuffer wo es schon ein paar 1000 Vertices sein müssen um ordentlich fix zu sein, und zwar sogar schneller als glDrawArray() aus nur einem Buffer mit TriStrps.)
Dann gelten ansonsten anscheinend die selben Regeln wie beim Rendern aus dem AGB-Speicher (Strips sind schneller als einzelne Primitives etc) mal von der Obergrenze abgesehen, die ein VBO haben darf.

Hat das eigentlich schonmal einer mit ner Geforce ausprobiert? Ist das Limit da wie bei den R300er bei 32Mb?

-lith

_________________
Selber Denken macht klug!

Irgendwo im OpenGL Forum stand mal, daß glBindBuffer auf der GF sehr schnell sein soll, aber die gl*Pointer Befehle nicht, weil der Bufferwechsel bis dahin verzögert wird. Letzlich kann so ein Wechsel dazu führen daß ein Buffer aus dem Hauptspeicher (oder Festplatte) wieder in den Grafikkartenspeicher eingelagert werden muß. Ich habe schonmal so viele Buffer erzeugt, daß sie dann in die Auslagerungsdatei kamen. Der ATI Treiber verändert den Standort eines Buffers nach der Erstellung nicht mehr. Daher wird der Bufferwechsel billiger sein, aber dafür gab(oder gibt) es Probleme mit vielen Daten, so wie z.B. mit dem 300MB Modell von Delphi3D.net.
In den Spezifikationen wird ausdrücklich darauf hingewiesen daß glBindBuffer schnell ist, daher entspricht das Verhalten der GF immer noch den Anforderungen.
Hab das ganze selber auch noch nicht ausprobieren können, weil ich eben eine Radeon habe. Auf der GF4 gab es zeitweise mal bezüglich nv_var so ein Limit, aber ich habe auch schon gesehen, daß 98MB belegt wurden.