Ich habe auch noch mal eine Frage:
Was ist mit glEnable/glDisable? Sind die sehr langsam oder ist das kein Problem? Weil in meinem Programm Teile der Szene eine Textur haben sollen, andere aber nur Farbe Also benutze ich sehr oft glEnable/glDisable GL_TEXTURE_2D

Das sollte nicht weh tun. Hier werden nur einzelne Flags gesetzt.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Richtig, Flags und Statechanges sollte man natürlich nicht unnötig machen, aber so schlimm sind die nicht. Sinnvoller ist es wirklich die glDraw-Calls zu minimieren, insbesondere weil du ja so auch indirekt die Flag-&Statechanges minimierst.

Ich sollte vielleicht noch einmal klar stellen was ich mit glDraw*** meine:
Alles was irgendwie direkt Geometrie zeichnet. Also dazu gehört natürlich auch beispielsweise glBegin/End.

_________________
Yeah!

Achso... ich dachte du meinst glDrawArrays und sowas.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

glDrawArrays zeichnet doch was, oder nicht?

_________________
Yeah!

@Flash: Was die VBOs betrifft, sehe ich bei einer Animation kein Problem, solange keine neuen Vertices dazu kommen. Dann öffnest du im Frame das VBO, änders die Daten und zum schluss zeichnest du es ganz normal. Und wenn nix geändert wird, zeichnest du halt trotzdem.

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

Heißt das mit weniger glBegin/glEnd denn, dass ich nur sehr wenige, dafür aber große glBegin/glEnd Blöcke nutzen sollte, also z.B. zuerst alle Quads in einem Block, dann die anderen Primitive u.s.w.
Oder sollte ich generell mehr andere Verfahren wie z.B. Listen benutzen ?

Der Imediate Mode ist generell recht langsam. ABER. Meiner Meinung nach bei 10-20 Quads noch detulich schneller als ein VBO. Nur wenn du ein paar tausend+ Dreiecke auf einmal zeichnen musst, dann kommst du um ein VBO nicht herum. Da würde ich sogar die Displayliste außen vor lassen wollen. Auch wenn Displaylisten intern selbst nur VBOs benutzen. Aber in Displaylisten ist es nicht zwingend nur ein VBO. Hängt halt davon ab wie du die Flächen zeichnest.

Eines möchte ich aber noch in den Raum werfen. Vergleiche bitte keine kommerziellen Spiele mit Anwendungen von dir. Kommerzielle Anwendungen sind immer wirklich hochgradig optimiert und die reizen meist das Maximum aus deinem System aus. Selbst die die nicht gut optimiert sind. Die arbeiten aber normal auch direkt mit den Grafikkartenherstellern zussammen. Und haben ca 30 Entwickler die sich vollzeit um nichts anderes kümmern.

Ein bisschen auf Geschwindigkeit achten kann aber nie schaden. Aber die meisten Probleme lassen sich nie genau auf einen Punkt eingrenzen. Sondern sind ein Zusammenschluss von vielen kleinen Engpässen. Teilweise genügt schon die Umstellung einer Berechnung oder das Vorhalten von verschiedenen Daten etc. Also die Optimierungen solltest du dort nicht nur bei OpenGL suchen.

Also Displaylisten und Arrays solltest du einfach nicht benutzen, das sind Relikte aus Urzeiten. Für ganz kleine Dinge kann ein glBegin/End sinnvoll sein, vor allem so einfach ist. Für alles andere VBOs benutzen.


Jop. Wobei du natürlich wissen solltest, dass du Quads genau wie alle anderen konvexen Polygone auch in Dreiecke zerlegen kannst. Solltest du natürlich Linien oder Punkte rendern hilft dir das nichts.

_________________
Yeah!

Das ist leider eine Fehlinformation. Für statische Geometrie mit Statechanges etc. sind Displaylisten immernoch die optimale Lösung. Selbst aktuelle OpenGL-Paper von ATI und NVidia sagen dass. Displaylisten haben von allen Geometriespeichermethoden nämlich immernoch das beste Optimierungspotential seitens des Treibers, da diese ja auch Statechanges speichern können die der Treiber dann umstellen kann. Mit VBOs ist dies nicht der Fall. Also bitte nicht behaupten Displaylisten wären ein Relikt aus der Urzeit!

P.S. : Ich mache in meinem aktuellen Spiel natürlich immernoch fleissig Gebrauch von Displaylisten, u.a. auch für meine GUI und statische Modelle.

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

Link? Bei uns in der Uni wurde mir nämlich was anderes erzählt, wenn ich mich da richtig erinnere.

_________________
Yeah!

Leider wurde die Entwicklersektion von ATI nach der Übernahme von ATI umgestellt, aber nach einigem Suchen :
http://ati.amd.com/developer/gdc/2006/G ... rmance.pdf

Ist zwar von 2006, aber dürfte durchaus noch aktuell sein. Dort steht u.a. auf Seite 14 folgendes :



Und Seite 15 zu den Displaylisten :



(letzter Punkt ist fast egal, man kompiliert die ja nur selten während des Spiel/Anwendungsablaufs)


Was an Unis erzählt wird ist nämlich leider oft sehr praxisfern. Wenn man etwas überlegt wird einem schnell klar warum Displaylisten immernoch am schnellsten sind wenn man mehr als nur Geometrie speichert. Denn diese werden ja "kompiliert", und da kann der Treiber dann beliebig optimieren und ersetzt solche Sachen wie Statechanges auch mit Mikrocodes usw. Ausserdem (ganz wichtig) werden die Geometriedaten von Displaylisten bei aktuellen Karten und Treibern sowieso wie VBOs abgelegt.

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

@Sascha Willems:
Thx. Ich hab mir nochmal die Folien der Vorlesung (es war eigentlich eine Globalübung) angeschaut. In den Folien steht keine explizite Aussage dazu was schneller ist, allerdings wird dies durch die Reihenfolge etwas angedeutet und die VBO kommen am Schluss. Mir dämmert, dass der Assistent etwas gesagt hätte wie "nach unten hin wird es immer schneller..." oder so. Wahrscheinlich hat er sich dann nur von der Reihenfolge täuschen lassen. Naja, ich denke Slides von der GDC kann man als verlässliche Quelle werten

BTW: Falls jemand Langeweile hat, könnte er doch diesen Thread mal im Wiki zusammenfassen, oder?

_________________
Yeah!

Zu dem thema fallen mir auch 2 dinge ein..

1) Als ich mit OpenGL angefangen habe - damals auch in C++ weil es nur die NeheTutorials gab - waren meine Programme auch extrem langsam... ich hatte 5fps da, wo andere 1000 hatten.. ich weiß bis heute nicht woran das lag, denn vom OpenGL Code kann ich rein theoretisch nicht soo viel falsch gemacht haben.

Ich glaube das liegt einfach stark auch an der generellen strukturierung vom Programm... es geht oft sehr viel zeit bei dingen verloren die mit OpenGL garnichts zu tun haben. Nach meinen ersten OpenGL versuchen damals hab ich das thema dann wieder abgehakt und erstmal normal weiterprogrammiert.. als ich dann ich glaube 1-2 Jahre später wieder damit anfing (Damals mit Delphi) ging es von anfang an mit sehr viel mehr FPS.

Ob das jetzt an Delphi lag, an falschen compiler-einstellungen von C++ oder sonstwas weiß ich leider nicht... will damit nur sagen, es bringt nichts 5 texturwechsel wegzuoptimieren wenn die zeit eigentlich wo völlig falsches verloren geht.


2) Wegen VBO vs. DisplayList.. Ich weiß natürlich nicht was genau der treiber intern macht, aber von meinem verständnis her erstellt der intern auch nur einen VBO und speichert sich die StateChanges etc.

Wenn man jetzt sowas als Display List hat:



Dann wird der treiber das vermutlich in einen VBO mit 8 vertices speichern. Zusätzlich brauch er noch die information das es zwei primitives sind, deren anfangs index im VBO + länge.. und noch eine Liste mit den state-changes inkl. zeitpunkt.

So auf anhieb wüsste ich nicht wie man sowas performanter lösen kann, als wenn man es hard-coded:



Wenn man dann noch dinge wie ein glColor in die DislayList mit reinpackt, erstellt der Treiber vermutlich noch ein VBO für die farbe, obwohl eigentlich alle vertices die gleiche farbe haben.. also viel überflüssiger speicher verbraten.

Deshalb denke ich mal ist es immer schneller ein VBO so einzusetzen wie man es braucht, statt es dem treiber zu überlassen aus einer DisplayList einen VBO zu erstellen.. denn im grunde ist eine DisplayList wie eine ScriptSprache, wird zwar compiliert und optimiert, wird aber nie so schnell sein wie "derselbe" code direkt.

(Alles nur meine Vermutung, ich kann mich natürlich auch täuschen)

Aya

Ich glaube deine Vermutungen gehen in die falsche Richtung. Denn letztendlich gibt es kein VBO auf der Grafikkarte, und deine Vermutung wäre nur dann korrekt wenn die Grafikkarte die genaue VBO-Struktur aus OpenGL via dedizierter Hardware nachbilden würde. Dem ist aber nicht so, denn genauso wie auf einer CPU wird wohl auch die GPU über Mikroprogramme verfügen, die letztendlich "hinter" den Grafikbefehlen stecken. Dein Beispiel mit der Displayliste wird also nicht wie vermutet auf der Grafikkarte in ein VBO abgelegt (die Vertexdaten einer Displayliste werden von der GPU behandelt WIE ein VBO, aber nicht ALS VBO) sondern als optimierte und sortierte Liste von abzuarbeiteten Mikroprogrammen und Verweise auf die Vertexdaten. Aber um hier genaue Vermutungen anzustellen müsste man sowohl die Interna einer GPU kennen (die gibt ja kein Hersteller raus) also auch die Interna der Treiber.

P.S. : Ein VBO mit 8 Vertices ist keine gute Idee, steht auch in dem von mir verlinkten Dokument. Man muss hier auf die vom Hersteller empfohlene Batchgröße achten, und bei so wenigen Vertices kann ein VBO sogar langsamer als der immediate Modus sein

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