Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Fr Jul 11, 2025 04:19

Foren-Übersicht » Programmierung » Einsteiger-Fragen
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 31 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3  Nächste
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Sa Feb 14, 2009 18:32 
Offline
DGL Member

Registriert: Do Dez 18, 2008 21:38
Beiträge: 60
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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Feb 14, 2009 19:04 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7810
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Das sollte nicht weh tun. Hier werden nur einzelne Flags gesetzt.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Feb 14, 2009 20:51 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java
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! :mrgreen:


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Feb 14, 2009 21:13 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7810
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Achso... ich dachte du meinst glDrawArrays und sowas.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Feb 14, 2009 21:57 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java
glDrawArrays zeichnet doch was, oder nicht?

_________________
Yeah! :mrgreen:


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Feb 14, 2009 22:05 
Offline
DGL Member
Benutzeravatar

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 networkmy 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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Feb 14, 2009 23:15 
Offline
DGL Member

Registriert: Do Dez 18, 2008 21:38
Beiträge: 60
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 ?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Feb 15, 2009 09:48 
Offline
DGL Member
Benutzeravatar

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.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Feb 15, 2009 12:44 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java
Zitat:
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.

_________________
Yeah! :mrgreen:


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Feb 15, 2009 13:19 
Offline
DGL Member
Benutzeravatar

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.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Feb 15, 2009 13:47 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java
Zitat:
Selbst aktuelle OpenGL-Paper von ATI und NVidia sagen dass.

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

_________________
Yeah! :mrgreen:


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Feb 15, 2009 13:53 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
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 :

Zitat:
Relative performance (best to worst)
• Display lists
• Vertex buffer objects
• Vertex arrays, preferably ranged
• Immediate mode (glBegin/glEnd)
• glArrayElement


Und Seite 15 zu den Displaylisten :

Zitat:
• 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.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Feb 15, 2009 17:09 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 29, 2005 12:28
Beiträge: 2249
Wohnort: Düsseldorf
Programmiersprache: C++, C#, Java
@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! :mrgreen:


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Feb 15, 2009 17:42 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
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:

Code:
  1. glEnable(GL_TEXTURE_2D);
  2. glBegin(GL_QUADS);
  3.   // 4 Vertices..
  4. glEnd();
  5.  
  6. glDisable(GL_TEXTURE_2D);
  7. glBegin(GL_QUADS);
  8.   // 4 Vertices..
  9. 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:
  1. [Pseudocode]
  2. //VBO erstellen..
  3. glEnable(GL_TEXTURE_2D);
  4. glDrawElements(vbo, start1, length1);
  5. glDisable(GL_TEXTURE_2D);
  6. 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)

Aya


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Feb 15, 2009 17:51 
Offline
DGL Member
Benutzeravatar

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 ;)

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


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 31 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3  Nächste
Foren-Übersicht » Programmierung » Einsteiger-Fragen


Wer ist online?

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.

Suche nach:
Gehe zu:  
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.010s | 14 Queries | GZIP : On ]