Hallöchen.

Für meine BA möchte ich einleitend einige Grundlagen zu OpenGL erklären.
Ich wüsste gern genau warum VBOs schneller sind als DLs und warum DLs schneller sind als der ImmediateMode.
Natürlich ist mir klar warum das so ist, jedoch möchte ich in der BA nicht mit gefährlichem Halbwissen aufwarten.

Mir würde schon reichen, wenn mir jemand ene Quelle für entsprechende Informationen liefern könnte.

Grüße

_________________
ack nack nack nack nack

Hmm… Quelle… öhm… Notfalls selber benchmarken, aber was schon reicht ist, die abläufe zu beschreiben. Da wird einem Leser recht schnell klar, warum das eine schneller als das andere sein muss.

grüße

_________________
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

Ok, dann vllt ein anderer Ansatz:
Ich umreiße das ganze und jemand der Ahnung davon hat sagt ob das so hinhaut oder nicht

ImmediateMode -> DisplayLists:
Entlastung des Flaschenhalses (was genau stellt den Flaschenhals dar?) da OGL-Kommandos nicht zur Zeit des Aufrufs auf die Graka geschoben werden

DisplayLists -> VBOs:
Verringerung der Zahl von OGL-Kommandos + Halten der Daten auf der Graka.

Ist es richtig, dass Bei DisplayLists Die OGL-Kommandos auf der Graka gehalten werden und bei entsprechendem Aufruf ausgeführt werden?
Hat die Graka extra einen Cache für diese Infos/Listen?

_________________
ack nack nack nack nack

Der erwähnte Flaschenhals ist meist der PCIe-Bus bzw dessen Anbindung.

Bei DLs vs. VBOs ist der punkt, dass die graka ne DL wie ne Skriptsprache verarbeiten muss, das ist langsamer als wenn du ihr nen 1MB block vertexdaten hinschmeißt und sagst: das sind 2D-Floatkoordinaten mit 2D Texturkoordinaten, render!

grüße

_________________
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

Displaylisten sind eigentlich genauso schnell wie VBOs...liegt einfach daran das der Treiber aus der Displayliste einen VBO macht. Wenn du den aber direkt benutzt hast du mehr Kontrolle und kannst etwa Daten effizienter speichern. Insbesondere die Verwendung eines Indexbuffers (auch Elementbuffer oder IBO) ist nur mit VBO möglich und das kann die nötige Datenmenge in üblichen Fällen auf etwas mehr als 1/6 reduzieren. Zusätzlich werden die nötigen Aufrufe des Vertexshaders deutlich reduziert da der Vertexcache benutzt werden kann.

Der größte Flaschenhals beim ImmediateMode sind die vielen Funktionsaufrufe. Für jeden Vertex werden mehreren Funktionen auf gerufen (Position, Normale, Texturkoords, Farbe, ...). Das es deutlich schneller ist einfach Daten direkt 1:1 zu kopieren sollte klar sein. Außerdem werden beim ImmediateMode die Daten bei jedem Frame erneut zur Grafikkarte übermittelt. Bei einem VBO wird nur das Kommando zum rendern übermittelt, die Daten sind schon da.

Edit: Sinnvoller Link wenn du abschätzen möchtest wieviel ein Indexbuffer bringt:
http://wiki.delphigl.com/index.php/Mesh

_________________
Yeah!

Ich würde auch eher erklären, was die 3 Möglichkeiten denn genau machen und dann kannst du darauf hinweisen unter welchen Bedingungen sie schnell wären und welche Bedingungen üblicherweise herschen.
Damit sagst du nicht, dass A, B oder C schneller ist aber der Leser lernt es recht einfach daraus.

Ich würde kein commitment machen, denn das eine DL z.B. ähnliche Performance wie eine VBO liefert ist eine gefährliche Aussage. Da DL um einiges mehr kann als ein VBO.

Was ich vermisse sind vertex array objects(vao) und vertex array(va).

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

Projekte: https://github.com/tak2004

Nö. Ist eine dehnbare Aussage

Intermediate glBegin/End, VA, VBO sind die 3 Vertex Daten lager Möglichkeiten.
Daneben gibt es Container, dass sind das alte DL, das neue VAO.

1. Lagert daten und zweifels ohne ist VBO das effizienteste auf GPU seite, VA umgekehrt und glBegin/End ist das langsamste auf beiden.
VBO wird im Arbeitsspeicher geladen, dann nach VRAM kopiert und vom Arbeitsspeicher entfernt, sämtliche GPU seitigen zugriffe sind daher schnell und CPU seitige sehr langsam, da erst vom VRAM in den Arbeitsspeicher kopiert werden muss.
VA liegen im Arbeitsspeicher und werden in den VRAM kopiert, dort aber nicht persistent und daher sind GPU seitige zugriffe nicht immer schnell(wegen erneuten sync) aber CPU.
glBegin/End sind die krönung, es wird speicher im Arbeitsspeicher angelegt, in den VRAM kopiert und in beiden wieder weg geworfen. Das der Sync Prozess die ganze Zeit auf frisst ist wohl einfach zu erraten.

Da Chiphersteller es gerne so schnell wie möglich haben, werden hinter den Kullissen natürlich optimierungen gemacht, so das z.B. VA eben doch persistent im VRAM gelagert sein könnte und damit weniger Sync anfällt und damit es schneller wird oder VBO die Daten im Arbeitsspeicher hält und ein low prio sync macht und CPU zugriffe zu garkeinem Sync führen.
Daher meine Aussage, dass solche behauptungen sehr gefährlich sind.

2.DL ist ein container, es enthält Befehle die ausgeführt werden sollen. Die Treiber sind aber so stark optimiert, dass sie z.B. glBegin/End Code als VBO umbauen und vieleicht später auch mal gebrauch von buffer pointer extension machen.
VAO ist ein anderer container, welcher Buffer beherbergen kann. Dieser kann nicht wie DL was rendern aber den Overhead vom Objekt orientierten Ansatzt, der mit OpenGL 2 und aufwärts sich als Imediate Mode alternative etabliert hat, erheblich erleichtern.

Hier noch mal passend 2 Worte zu den Buffer pointern. Nvidia hat eine Extension raus gebracht, welche es erlaubt das bind/unbind zu umgehen, indem man in ein weiteren Buffer die Pointer der Objekte hinterlegt. Dann gibt es nur noch ein bind/unbind dieses Objektes und alle shader, texturen, vbo und so weiter sind verknüppelt. Mit OGL 3 wurde das bind/unbind zum bottleneck und das soll es reduzieren. Braucht natürlich ne menge VRAM, weil alles zum Objekt im VRAM gehalten werden muss.

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

Projekte: https://github.com/tak2004

Also das nur ImmediateMode, DLs und VBOs erklärt werden sollen hat den einfachen Grund, dass meine kleine Engine momentan nicht mehr unterstützt als diese 3 Varianten. Es soll auch überhaupt nicht allzu stark darauf eingegangen werden, da das nicht Teil des eigentlichen Themas ist. Trotzdem sollen wie gesagt einige Grundsätze dazu erklärt sein. Da ich im Nachhinein natürlich begründen muss, warum die komplizierteren Objekte als VBOs gehalten werden.

Interessant finde ich die Aussage, eine DL sei genauso schnell wie ein VBO. Ich kann die Begründung, es wird intern als VBO gehalten, nachvollziehen. Meine eigene Erfahrung damit zeigt jedoch recht klar, dass ich mit VBOs mehr Objekte ruckelfrei rendern kann als mit DLs. Woher kommt dann diese Differenz?
Außerdem stünde das der Aussage LordHorazonts entgegen:
Oder zumindest scheint es verschiedene Abstufungen in der Optimierung zu geben. Was davon stimmt denn nun?

_________________
ack nack nack nack nack

Naja, die grafikkarte kann natürlich glBegin/glEnd blocks durch nen Drawcall auf ein VBO ersetzen. Aber bindcalls und so müssen immer noch wie von einer Skriptsprache verarbeitet werden (oder werden womögilch direkt in irgendeinen Bytecode compiliert, den die Grafikkarte ausführen kann).

grüße

_________________
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

Super, vielen Dank für die Informationen, ich danke damit lässt sich was anfangen.

Grüße!

_________________
ack nack nack nack nack

Im Endeffekt erlangt man einen rel. großen Bonus, wenn man einen reinen OpenGL 3/4 Context verwendet - dann gibts nämlich keine deprecated Funktionen wie DL's mehr. Allein deshalb sollte man immer VBO's nutzen, schließlich laufen die auf fast allen Graka's und man brauch keine Codeumstellungen via IFDEF wenn man o.g. Context verwenden will.

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Ich habe vorhin versucht einen kleinen recht subjektiven Benchmark duchzuführen.
150 Objekte eines komplexen Modells werden dargestellt und schlichtweg die Kamera um die Objekte gedreht.
Beim IM läufts natürlich gruselig bis gar nicht.
Jedoch ist zw. DL und VBO überhaupt kein Unterschied mehr zu erkennen.
(Beides ruckelt in etwa gleichstark)

Also habe ich noch mal Onkel Gogl angestrengt:
http://www.opengl.org/discussion_boards/showthread.php/172532-VBO-vs-DisplayList

Daraus geht tatsächlich hervor das DL in VBOs umgewandelt werde.
Interessanterweise ist das erst der Fall seit dem ich vom TAO-Framework auf OpenTK umgestiegen bin. (Vorher konnte ich definitiv einen fetten Unterschied feststellen)

Was aber nicht weiter schlimm ist, da ich natürlich die Entscheidung pro VBO immer noch auf größere Flexibilität schieben kann.
Außerdem scheinen DLs ja nicht mehr lange überhaupt eine Option zu sein wenn man den Threads einiger Foren so glauben darf.

Grüße!

_________________
ack nack nack nack nack