Und? Das ist kein grund so aggresiv zu reagieren (und dann nichtmal entschuldigen o.Ä..)...
Aber egal, soll nicht zum OffTopic verkommen hier.

Ich probier das heute abend oder am Wochenende mal aus mit den VBOs wie die geschwindigkeits unterschiede sind und sag euch dann was rauskam

Aya~

Ein kleines VBO ist in sofern "langsam" weil der verwaltungs-aufwand mehr beansprucht als einfach das Quad zu zeichnen.

Ob ich jetzt allerdings ein großes VBO binde, ein Quad daraus zeichne und wieder unbinde, oder das gleiche mit einem kleinen VBO mache sollte relativ egal sein (wenn überhaupt ist da würde ich sagen das kleine sogar schneller).

Das große VBO mit vielen Quads lohnt sich nur wirklich wenn es einmal gebunden wird und dann einfach immer nur quads daraus gezeichnet werden (ohne jedesmal neu zu binden).

Aya

So meinte ich das ja dann auch alles in ein Vbo packen und die quads hintendran oder vorne je nachdem^^
Aber dass nur der verwaltungsaufwand zu groß wird, bei kleinen vbos, dass kam bei mir nie ganz rüber, gut zu wissen! =)

_________________
System: Phenom XII X4 955 3,21Ghz , GTX 560 TI, 4GB-Ram, Windows 7 64x

Für die UI würde das durchaus auch gehen einfach alle Quads in ein VBO. Problematisch wird es halt wenn man mal einfach so mittem im code ohne vorwarnung ein Quad zeichnen will

Und zusätzlich fällt halt pro Quad ein haufen variablen an den man irgendwo hinpacken muß (VBO, Index etc)

VBOs sind meiner Meinung nach nicht für so Kleinstdatenmengen ausgelegt. Bzw dann wird der Verwaltungsaufwand überwiegen. Der Imediate Mode wird direkt im Treiber abgebildet. Die haben da natürlich ganz andere Möglichkeiten die Verarbeitung zu optimieren als mit einer gekappselten Funktionalität. Ich denke die werden sich direkt irgendwo in die Pipeline hängen können. Die VBOs allerdings müssen vom Treiber auch nach außen gereicht werden. Entsprechend wird das auch irgendwie schon gebremmst werden. Wenn auch nicht extrem aber es wird sich bei solchen kleinen Daten schneller zeigen.

Habe aber mal bei meinen Fonts ein bisschen rumgespielt.
- VBO mappen, Quad reinschreiben, VBO Entmappen und zeichnen war mit Abstand am Langsamsten. Glaube nur 1/3tel so schnell wie nachfolgendes.
- Quad vorbereiten und mit glBufferData/glBufferSubData ins VBO schreiben und das dann Zeichnen war schon schneller aber immernoch langsamer als der Imediate mode. In etwa um die Hälfte.

Könnte mir auch gut Vorstellen, dass das auf anderen Systemen wieder anders aussieht. Getestet mit Radeon HD 2400 (Shared) und Radeon 3850.

Was ich jetzt nicht gestestet hatte war das Cachen von 100-200 Quads und diese dann auf einen Schlag zu zeichnen. Das verschiebt das Gleichgewicht wieder enorm in Richtung VBOs. Das geht aber nur, wenn die Texturen gleich bleiben etc. Also für GUIs etc ist so etwas wohl einfach nicht immer möglich. Evtl komme ich ja noch dazu das am Wochenende zu machen (glaube ich aber leider noch nicht dran).

VBO sind auch ned für kleinstdatenmengen Ausgelegt, da vermutest du völlig richtig, ATI und NV schreiben sehr selten aber doch vorkommend die optimalen Verticegrößen für die einzlenen Karten, in Whitepapers und Präsis.
Bis ich diese finde, würde ich 1-2 Tage mit suchen verbringen ... aber 4 bzw 6 Vertice(je nach umsetzung) pro VBO sind höchstgradig ineffizient(glaube bei der r9800 waren es 16k).

Darum sagte ich ja auch ein VBO für alle Statischen widgets und die Dynamischen bekommen pro typ eins.
Ein weiterer grund wieso mehrere VBO ineffizent sind, ist das binden und entbinden der vbo's.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hm, interessant. Aber diese Lösung ist mir einfach zu statisch. Gegenvorschlag: Alle Widgets in ein VBO packen und über Indizes ansteuern. Damit bleiben sie veränderbar (auch nicht so uninteressant in Bezug auf einen späteren Editor). Außerdem muss man ohnehin dazwischen immer wieder eingreifen, wenn verschiedene Texturen gebunden werden müssen.

Bei Indices bei einem 4Eck werden 2 vertice(24byte) weniger gebraucht aber es kommen 6 indices(24byte) hinzu und damit gleicht sich das wieder aus.
Der Vorteil liegt dann in der Geschwindigkeit, da der Vertexcache besser greift.
Auf die Updatefähigkeit hat dies aber keine Auswirkung, da man nach wie vor Start und Count für jedes Element mit speichert und ob Start direkt auf ein Vertex zeigt oder auf ein Indice macht kein unterschied.
Updates können ja eh gemacht werden, ist ja nicht so, das die ganze App zusammen bricht, wenn du mal ein Update machst.
Da kannst auch schon je nach größe und Grafikkarte einige hundert die sekunde machen. Dieser fall passiert aber wirklich selten von daher schon fast vernachlässigbar.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hey, ja Du hast recht. Ich verstehe zwar nicht, warum man bei indizierten Vierecken zwei Vertices weniger und zwei Indices mehr braucht, aber trotzdem hast Du recht. Die einfache Methode mit First/Count ist schneller.

Ein Quad besteht aus 6 Vertice also 2 Dreiecken. Stellt man es über ein Indice dar, dann kommen 2 Vertice doppelt vor, unzwar die beiden, wo die 2 Dreiecke aneinander liegen und diese braucht man bei indices ja nur einmal in der Verticeliste speichern(daher nur 4 Vertice). Man muss aber für jedes Vertice ein Index angeben und da wir mit Dreiecken arbeiten braucht man 6 Indices. Die 2 entfallenden Vertice sind 24Byte groß 6xfloat und die 6Indices sind 24Byte groß und damit hat es sich im Fall des Quads ausgeglichen. Bei Meshes spart man sogar Platz, wenn man auf Indices Umstellt, da oft von mehreren Dreiecken verwendet wird und mit jeden wird weniger Speicherplatz gebraucht.
Wenn du nun deine Quads zeichnest, dann packt die GPU gleich einen ganzen block von den Vertice in den Cache und da du mehrere Indices hast, die gleich sind und sehr nahe aneinander liegen, hat der Cache höhrere trefferchancen und damit steigt die geschwindigkeit. ATI bietet kleine tools, die Meshdaten so umbauen, dass diese Trefferchance dramatisch gesteigert wird. Das macht man durch Trianglestripes, die Spiralformig aufgebaut werden(leihenhaft ausgedrückt).

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Also moment mal. So wie ich das verstanden hab, soll man eben nicht vier Vertices in ein VBO packen sondern ein großes VBO für die komplette UI verwenden, wo jede Kompo ihren eigenen Platz zugewiesen bekommt und dann der ganze Kram gezeichnet wird.

Was ich mich allerdings frage... Wie soll das klappen mit dem Clipping an Fenster/Komponentengrenzen? Schließlich muss man dann ja trotzdem alle UI-Elemente einzeln (oder zumindest alle, die auf einer Komponente liegen) einzeln zeichnen, weil man das Scissoring oder Stencil-Testing (je nach dem, was man verwendet) ändern muss.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ich beziehe mich auf den Befehl:
glDrawArrays(GLenum mode, GLint first, GLsizei count)

normalerweise würdest Du schreiben: glDrawArrays(GL_QUADS, 0,4) // = zeichne vom Vertex Null an ein Quad aus den nächsten 4 Vertices (wobei das ganze VBO nur 4 Vertices hat)
aber Du kannst z.B. auch schreiben: glDrawArrays(GL_QUADS, 120,4) // = zeichne vom Vertex 120 an ein Quad aus den nächsten 4 Vertices (hier zeichnet er einen Ausschnitt aus dem VBO)

Das sollte eindeutig schneller sein als meine obige Variante mit den Indices. Ich nehme einfach ein Quad, keine zwei Triangels, aber das kann ja jeder machen wie er will, und den Scissoring Test beeinträchtigt das nicht.