[OpenGL] Anfängerfrage: State machine vs. Performance

[shadow]

Hallo,

ich habe eine Frage bzgl. OpenGL als als Status-Maschine: Wie findet man heraus, welche OpenGL-Aufrufe Performance kosten, und welche nicht?

Ich habe in meiner kleinen Engine Code-Stellen, wo GL_TEXTURE_2D enabled sein muss, und ein paar wenige Stellen, wo es disabled sein muss. Da sehe ich grundsätzlich zwei Möglichkeiten:

(1) Ich gebe "enabled" als default vor, also setze es anfangs einmal auf "enalbed". Immer wenn ich dann GL_TEXTURE_2D "disabled" brauche, setze ich es kurzfristig auf "disabled", danach aber gleich wieder auf "enabled", um den default wieder herzustellen.

(2) Ich setze GL_TEXTURE_2D an allen Stellen auf "enalbed" oder "disabled", wie ich es gerade brauche.

Variante (1) hätte meiner Schätzung nach deutlich weniger Methodenaufrufe zu glEnable() bzw. glDisable(). Dafür sehe ich Variante (2) für mich als etwas stabiler an, ich hatte schon manchmal den Fall, wo ich nach Möglichkeit (1) vergessen habe, den ursprünglichen Zustand wieder herzustellen und dann lauter weiße untexturierte Quads gesehen habe...

Grundsätzlich würde ich zu (2) tendieren, wenn ich wüsste, dass allein glEnable() bzw. glDisable() keine Performance verbrauchen würde.

Danke!

[Artificial Mind]

Ich denke das hängt unter anderem vom Treiber ab. Was du dir aber einfach bauen kannst ist eine kleine "Wrapper"-Klasse/Funktion für solche States, die den Aufruf nur dann weiterleitet wenn sich was geändert hat. Das ist vom overhead her ein Function-Call + ein Conditional Jump, also vernachlässigbar im Vergleich zu Treiberaufrufen. Das einzige potentielle Problem ist dabei, dass man diesen Wrapper dann konsequent überall einsetzen muss, damit der intern gespeicherte Zustand konsistent bleibt.

[shadow]

Das mit dem Wrapper ist ne wirklich gute Idee, dass ich da nicht selbst draufgekommen bin :?

[Sternmull]

Ich würde auch zu 2. raten. Im Zweifelsfall kannst du das glEnable/glDisable ja auch noch durch eigene Funktionen wrappen die sich merken was als letztes gesetzt wurde und die OpenGL nur aufrufen wenn es tatsächlich ein anderer Wert ist. Einen Versuch wäre es wert. Aber ich schätze das wird keinen wirklichen Performance-Unterschied machen. Soweit ich das verstehe wertet der Treiber den State erst dann aus wenn er ihn wirklich braucht (z.B. beim nächsten Aufruf der was zeichnet). Dann wird entschieden ob/wie die Hardware umkonfiguriert werden muss.

Der Aufwand hängt vom vorherigen Zustand und natürlich von Hardware und Treiber ab. Umschalten auf eine andere Textur kann z.B. vom einfachen setzen eines Pointers (weil zwischen zwei Texturen mit gleichem Format und gleicher Größe umgeschaltet wird) bis zu aufwändigen Speichertransfers und einer Rekonfiguration der Hardware kosten (neue Textur ist noch nicht geladen und hat ein anderes Foramt). Bei glEnable/glDisable ist das so ähnlich. Aber man sollte erwarten das der Treiber redundante Umschaltungen erkennt und sich dann auch keine unnötige Arbeit macht (angeschaltet, aus, an, aus, an, rendern --> nichts machen).

Vor einer Weile hatte ich mal eine gute Beschreibung dieser Vorgäng gefunden. Leider find ich das grad nicht wieder. Das hier geht aber ungefähr in die Richtung.

[Krishty]

Gehen OpenGL-API-Aufrufe denn direkt in den Treiber, also verursachen sie mit relativer Sicherheit einen Kontextwechsel?

Ich habe hier eine extrem CPU-limitierte Direct3D-9-Anwendung, und sowohl Treiber als auch Laufzeitbibliothek filtern redundante Zustandsänderungen sowieso. Alles in allem hat mir manuelle Zustandsverwaltung einen Zuwachs von ungefähr einem Prozent gebracht – also eine Verbesserung von 100 Hz auf 101; und das nur, weil meine CPU sowieso zu 100 % ausgelastet ist! Wenn man davon ausgeht, dass ein solide entworfener (also nach Materialien usw. sortiert zeichnender) durchschnittlicher Renderer 10 % der CPU-Zeit benötigt, um flüssig zu zeichnen, entspricht dein erwarteter Leistungsschub höchstens einem Promille der Gesamtleistung.

Ob sich Programmier- und Wartungsaufwand und die erhöhte Komplexität für den Sprung von 30 auf 30,02 Hz lohnen, musst natürlich du entscheiden. Ist ja auch nicht ausgeschlossen, dass unter OpenGL alles anders läuft und die Treiber weniger liebevoll optimiert sind. Ich persönlich bin dazu übergegangen, nur noch die Zustände Umgebung, Terrain, HUD manuell zu verwalten und alles andere Laufzeitbibliothek und Treiber machen zu lassen.

[dot]

Egal ob OpenGL oder Direct3D, auf einigermaßen aktueller Hardware ist wohl das Wichtigste, die Anzahl der Shader und Texture Wechsel zu minimieren. Statt irgendwelche Statewechsel zu cachen, was der User Mode Driver sowieso tut, sortier also deine Objekte so, dass du möglichst viel mit dem gleichen Shader und möglichst viel mit einem DrawCall zeichnen kannst. Das dürfte wohl erstmal die größte Effizienzsteigerung bringen.
Wenn du dann noch Performanceprobleme hast, heißt es wohl erstmal profilen um rauszufinden, wo genau die Zeit draufgeht.

[shadow]

Ok, danke für die vielen Antworten!! Damit komm ich erst mal klar...

Shader nutz ich eh nicht, und die Texture Wechsel kann ich in meiner 2D-Engine ganz gut kontrollieren...

Danke nochmal!
Stefan

[dot]

Wenns um einen Spriterenderer geht, solltest du dir überlegen, deine Sprites zu batchen. Also ein dynamisches VBO zu machen, das z.b. groß genug ist um 1000 Sprites zu halten. Wenn ein Sprite gezeichnet werden soll, wird es einfach in diesen Buffer geschrieben. Erst wenn der Buffer voll ist, oder z.B. die Texture gewechselt werden soll, renderst du alle Sprites in dem Buffer auf einmal.

[shadow]

Ich fürchte so weit bin ich noch nicht...
Leider überhaupt keine Ahnung, was VBO ist. Ich bin schon froh, dass ich es überhaupt geschafft habe, meine 2D-Engine auf OpenGL umzustellen :) ... und da hab ich noch genug Probleme, zu denen ich sicher früher oder später nochmal hier aufschlagen werde :?

(Nur zur Info: Ich verwende OpenGL1.1 über das Java-Binding LWJGL)

[antisteo]

Ich fürchte so weit bin ich noch nicht...
Leider überhaupt keine Ahnung, was VBO ist. Ich bin schon froh, dass ich es überhaupt geschafft habe, meine 2D-Engine auf OpenGL umzustellen :) ... und da hab ich noch genug Probleme, zu denen ich sicher früher oder später nochmal hier aufschlagen werde :?

(Nur zur Info: Ich verwende OpenGL1.1 über das Java-Binding LWJGL)

OpenGL 1.1 ist Spielzeug. Damit kannst du anschauen, wie Grafik vor 15 Jahren ausgesehen hat oder für irgendwelche Wirtschaftsheinis eine Visualisierung für ihre Anlage bauen (da achtet auch keiner auf die Grafik).

OpenGL 1.1 bietet dir nicht wirklich viele Möglichkeiten, an der Performance zu tweaken. Wenn du auf GL 1.1 bleiben willst, gib dich mit der aktuellen Performance deines Codes zufrieden.

[shadow]

Macht es bei textured quads einen Unterschied, welche OpenGL Version ich benutze?

[Florian Keßeler]

Kommt drauf an. Wenn du sie bei deinem Code mit glBegin()...glEnd() zeichnest, wird es fast immer langsamer sein, als wenn du sie mit VBOs zeichnest. Ob es wirklich einen spürbaren Unterschied macht, hängt unter anderem auch davon ab, wie viele Quads du zeichnest und ob du deine Vertexdaten zwischen verschiedenen Frames wiederverwenden kannst.

[kimmi]

Macht es bei textured quads einen Unterschied, welche OpenGL Version ich benutze?

Die Art des Zeichnens spricht wie du die Renderdaten definierst ist unter OpenGL4.x anders als die unter OpenGL1.1 . OpenGL hat mittlereile alles in Buffer verpackt und nimmt Abstand von einzelnden glVertex-Calls. Und wenn du GLSL benutzen willst, musst du sowieso von OpenGL1.1 weg. Das wird erst ab OpenGL2.0 unterstützt ( also als festn betandteil der API und nicht als Extension ).

Ich rate dir: gehe gleich zu OpenGL4.x, dann sparst du dir das Umdenken, enn du mit deinen Experimenten weiter kommen möchtest.

Gruß Kimmi

[Artificial Mind]

Ich rate dir: gehe gleich zu OpenGL4.x, dann sparst du dir das Umdenken, enn du mit deinen Experimenten weiter kommen möchtest.

Ich rate dir: OpenGL 3.2/3.3. OGL 4.x wird imho von zu wenig Karten unterstützt, also meine 9800er können es noch nicht und so alt sie die nicht. Also mit "zu wenig" meine ich es gibt noch zu viele "zu alte" Karten.

[dot]

Ja, ich würd auch zu OpenGL 3.3 als Baseline raten (in 3.2 fehlen mir z.B. die Sampler Objects). Das ist hinreichend brauchbar und auch einigermaßen verfügbar...

[Florian Keßeler]

Ich denke mal, hauptsache ist, dass man mit nem 3er Core Profile anfängt. Der Rest lässt sich dann nach Bedarf dazulernen...

[glassbear]

meine 9800er können es noch nicht und so alt sie die nicht. Also mit "zu wenig" meine ich es gibt noch zu viele "zu alte" Karten.

Die 9800er basieren auf den 8800er, welche Ende 2006 vorgestellt wurden. Das ist in der IT-Welt dann doch "alt", auch wenn du die erst vor Monaten gekauft hast ;)

[dot]

Und selbst die unterstützen OpenGL 3.3...

[kimmi]

Ihr habt ja alle recht. OpenGL3.3 geht auch nur auf meiner Grafikkarte :-) ...

Gruß Kimmi

[dot]

Das größte Problem mit OpenGL 3.3 ist meiner Erfahrung nach nicht die Hardware, sondern die Treiber. So gibt es da draußen viele Laptops, die zwar OpenGL 3.3 fähige Hardware verbaut haben, aber keine OpenGL 3.3. fähigen Treiber haben, weil die Laptop Hersteller dafür sorgen, dass die offiziellen Treiber nicht drauf laufen und selber niemals Updates liefern, sodass man für immer und ewig mit Treibern aus dem Jahre Schnee arbeiten darf, wenn man nicht gerade gern ein wenig rumhacked...

[kimmi]

Die Treiber unter Windows waren auch schon bei OpenGL2.0 ein großes Problem. ich erinnere mich an ein Szenario, wo eine Anwendung plötzlich einen Einbruch bei den FPS aufzeigte, nachdem in einem Schader Branching benutzt wurde. Die Ursache - Wirkung war dabei schwer nachvollziehbar.

Gruß Kimmi

[antisteo]

Ich empfehle einfach mal OpenGL ES 2.0
Das unterstützt Shader, hat keinen Intermediate Mode und es gibt sogar einen Wrapper zu DX9 (falls der User Windows benutzt) und man ist auf Smartphones&co präsent.

[pUnkOuter]

Das größte Problem mit OpenGL 3.3 ist meiner Erfahrung nach nicht die Hardware, sondern die Treiber. So gibt es da draußen viele Laptops, die zwar OpenGL 3.3 fähige Hardware verbaut haben, aber keine OpenGL 3.3. fähigen Treiber haben, weil die Laptop Hersteller dafür sorgen, dass die offiziellen Treiber nicht drauf laufen und selber niemals Updates liefern, sodass man für immer und ewig mit Treibern aus dem Jahre Schnee arbeiten darf, wenn man nicht gerade gern ein wenig rumhacked...

Genau so einen Scheiss-Laptop habe ich auch.

[antisteo]

Das größte Problem mit OpenGL 3.3 ist meiner Erfahrung nach nicht die Hardware, sondern die Treiber. So gibt es da draußen viele Laptops, die zwar OpenGL 3.3 fähige Hardware verbaut haben, aber keine OpenGL 3.3. fähigen Treiber haben, weil die Laptop Hersteller dafür sorgen, dass die offiziellen Treiber nicht drauf laufen und selber niemals Updates liefern, sodass man für immer und ewig mit Treibern aus dem Jahre Schnee arbeiten darf, wenn man nicht gerade gern ein wenig rumhacked...

Natürlich. Die können ja mit dem Marktstart nicht warten, bis die Treiberentwickler fertig sind. Das sind doch Millionen, die da den Bach runter gehen.

[glassbear]

Das größte Problem mit OpenGL 3.3 ist meiner Erfahrung nach nicht die Hardware, sondern die Treiber. So gibt es da draußen viele Laptops, die zwar OpenGL 3.3 fähige Hardware verbaut haben, aber keine OpenGL 3.3. fähigen Treiber haben, weil die Laptop Hersteller dafür sorgen, dass die offiziellen Treiber nicht drauf laufen und selber niemals Updates liefern, sodass man für immer und ewig mit Treibern aus dem Jahre Schnee arbeiten darf, wenn man nicht gerade gern ein wenig rumhacked...

Kann ja nur Via oder Sis sein :roll: Es gibt sowohl von Nvidia, Intel als auch von AMD/ATI Treiber für Mobile GPUs auch für ältere GPUs.

[dot]

Nein, ich sprech da von ganz normalen NVIDIA und AMD/ATI Karten, z.B. der Mobility RADEON HD 5650 in meinem Sony VAIO. Die Treiber von AMD helfen einem nichts, wenn man Sie nicht installieren kann. Steht eh auch schon auf der von dir verlinkten Seite:

The following notebooks are not compatible with this tool:
Notebooks equipped with switchable graphics
Toshiba® notebooks
Sony® VAIO® notebooks
Panasonic® notebooks

Das Problem ist mittlerweile wohl viel besser als es früher noch war, vor allem auf NVIDIA Seite, aber es existiert noch. Wenn ich nicht in stundenlanger Recherche rausgefunden hätt', wie ich das Setup für einen aktuellen AMDTreiber so modifizieren kann, dass er sich bei mir installieren lässt, könnt ich immer noch kein OpenCL und OpenGL auf meinem Laptop verwenden. In anbetracht der Tatsache, dass zum Zeitpunkt da ich den Laptop gekauft hab schon seit über zwei Jahren entsprechende Treiber von AMD verfügbar waren, ist das dann doch sehr ärgerlich... ;)

[glassbear]

Ops :D

Ich kenn nur mein Thinkpad mit AMD E450: tut mit dem Treiber.
Und lauter HP-Laptops mit Nvidia-Grafik und auch da: Treiber tun.

[dot]

Ja, wie gesagt, vor allem mit NVIDIA ist das Problem mittlerweile wesentlich besser hab ich den Eindruck. Die neuesten VAIOs, die nun auch NVIDIA verbaut haben, laufen afaik auch mit den NVIDIA Treibern.
Aber sowohl mein 2 Jahre alter VAIO (AMD) als auch mein ASUS davor (NVIDIA): Keine Chance.