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
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.
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
@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 ?
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
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.
Oder sollte ich generell mehr andere Verfahren wie z.B. Listen benutzen?
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.
Zitat:
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.
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.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Coolcat hat geschrieben:
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..
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.
• Excellent method for static geometry • Allows the driver to correct app mistakes • Merge small draw calls • Format data types to be hardware friendly • Reformat primitive types • Fairly large software penalty for compile
(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.
@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?
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:
Code:
glEnable(GL_TEXTURE_2D);
glBegin(GL_QUADS);
// 4 Vertices..
glEnd();
glDisable(GL_TEXTURE_2D);
glBegin(GL_QUADS);
// 4 Vertices..
glEnd();
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:
Code:
[Pseudocode]
//VBO erstellen..
glEnable(GL_TEXTURE_2D);
glDrawElements(vbo, start1, length1);
glDisable(GL_TEXTURE_2D);
glDrawElements(vbo, start2, length2);
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)
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
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
Mitglieder in diesem Forum: 0 Mitglieder und 9 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.