Welche Funktion hat drvPresentBuffers (nvoglv32.dll / NVIDIA OpenGL ICD)

inter2k3

Krug zum Gruße,

beim profiling eines von mir geschriebnenen kleinen 2D-Spielchens stelle ich fest, dass beim release-build die meisten time-samples für drvPresentBuffers draufgehen.
Ich finde leider keine Information bezüglich der Aufgabe dieser Funktion (wird aus nvoglv32.dll importiert - weilches Teil der NVIDIA OpenGL IDC ist).

Wird diese durch (1) SwapBuffers aufgerufen oder hat es eher mit dem (2) Binden von Buffer-objekten zu tun?

Falls (1) kann ich wohl wenig an der Performanceschraube drehen.

Grüsse und TIA für eure Antworten.

hustbaer

Ich vermute (1).
Kann dein Profiler denn nicht anzeigen von wo aus drvPresentBuffers aufgerufen wurde?

inter2k3

Ich benutze AMD CodeAnalyzer momentan (allerdings auf einem Core2Duo) und kann diese Information nirgends finden.
Ich werde mir mal die Testversion von vTune installieren und schauen wie es sich dort verhält.

Oder kannst du eventuell einen profiler empfehlen? Habe mich damit bisher noch nicht wirklich beschäftigt und CodeAnalyzer war nun der erste profiler den ich genutzt habe.

dot

Ich bin mir ziemlich sicher dass das SwapBuffers() ist. Hast du denn ein Performanceproblem dass du da profilen gehst oder könnte es einfach nur sein dass dein Spiel so schnell rendert dass die meiste Zeit einfach auf den VSync gewartet wird!?

Wenn du mit OpenGL arbeitest, solltest du gDEBug zum Profilen verwenden:
http://www.gremedy.com/

Der ist aufschlussreicher.
Und ich vermute auch dass dein Code einfach auf den VSync wartet.

hustbaer

inter2k3 schrieb:

Ich werde mir mal die Testversion von vTune installieren und schauen wie es sich dort verhält.

Oder kannst du eventuell einen profiler empfehlen?

vTune ist cool.

inter2k3

Ich danke für eure Antwoten.
VTune gefällt mir schon um einiges besser als CodeAnalyst und auch gDEBugger ist ganz nett. Ich werd mich mal mit beiden Programmen eingehender beschäftigen um ihr Potential zu ergründen.

Ganz sicher bin ich mir noch nicht, aber es scheint tatsächlich so, dass drvPresentBuffers eine Funktionn der Aufrufkette ist, die durch SwapBuffers entsteht.

Performanceprobleme hab ich keine, ich habe das profiling einfach nur aus Interesse durchgeführt, da ich mich wie schon erwähnt noch nicht wirklich damit beschäftigt habe.
An vsync kann es nicht liegen, da ich dieses momentan im Spiel deaktiviere (wglSwapIntervalEXT(0)) - sofern der Treiber dies nicht mit einer default-Einstellung überschreibt.
Da es sich nur um ein relativ simple gehaltenes Arkanoid Spiel handelt und kein grosser Schnickschnack verwendet wird (simple shader, core-profile, keine frameworks sondern direkt openGL und winAPI) läuft es mit angenehmen 2000 fps, daher ist es ohnehin nicht nötig sich nach hotspots umzuschauen.

Bei deaktiviertem vsync und einer so hohen framerate wird wahrscheinlich trotzdem immer ein wenig gewartet werden bis alles fertig gerendert ist (GPU-load ca. 90%-95%, GPU Memory Controller Load ca. 70%) - daher vermutlich dann die Tatsache, dass die meisten timesamples für drvPresentBuffers gelogt werden.

Grüsse.

hustbaer

3D APIs warten normalerweise nach einem Render() Call nicht bis alles fertig gerendert ist, sondern warten erst dann, wenn es nötig ist. Also z.B. wenn man ein Rendertarget lockt oder eben Present/SwapBuffers/... aufruft.

BTW: vTune kann dir anzeigen wie viel Zeit in einer Funktion mit "arbeiten" verbracht wurde (also wo die CPU aktiv etwas tut), und wie viel zeit mit "warten" verbracht wurde. Ich vermute mal dass der Grossteil der Zeit in drvPresentBuffers "warten" ist. Das würde dann zu der Vermutung passen, dass drvPresentBuffers einfach warten muss bis die Grafikkarte mit dem aktuellen Frame fertig ist.