Nvidia "threaded optimization" do's / don'ts?

Started by with 1 comment, last by gold August 30, 2008 01:53 PM
AgentC
2,476
August 30, 2008 01:53 PM
Hi, googling around I find evidence of various problems - stuttering framerate, slowdown, or even crashes - in OpenGL applications when the Nvidia control panel setting "threaded optimization" is enabled. Is there anywhere a set of rules or documentation that explains what to do & what to avoid to not get these sorts of issues and make your programs run equally well regardless of the setting? I guess it has to do with synchronization issues inside the driver... Personally I know at least one somewhat obscure bug that only occurs with threaded optimization on: if you have two or more rendering contexts, and are using VBO's in one context and for example vertexarrays in the other, you should bind buffer object zero (thus disabling VBO) even in the non-VBO context, otherwise the VBO from the other context may still occasionally be bound and you'll render incorrect geometry (or crash).
Yann L
1,802
August 30, 2008 03:07 PM

Correct frame timing with threaded optimization on can be a real bitch.

Consider this game loop:

// Handle Windows messagesPeekMessage(Msg, ...)TranslateMessage(Msg)// Start time of this framestart = GetCurrentTime()// Render it, but don't swap buffers yetRenderFrame()// Do physics, AI, whatever, partially in parallel with the GPUDoOtherStuff()// Swap buffers, flush GPU command queue for this frame// Do potential GPU -> CPU readbacks hereFinishFrame()// Calculate this frames time deltaframeTime = GetCurrentTime() - start


This will NOT work reliably when threaded optimization is on, vsync is off and you are running on a multicore CPU ! frameTime will often drop to very short amounts of time, and/or fluctuate heavily. In fact, you have to add the next PeekMessage call into your current frame timing ! Somehow it seems that the driver doesn't really finish the frame when you swap/present it. It still runs on a separate thread. For some obscure reason, it actually completes only on the next PeekMessage call !
gold
412
September 01, 2008 03:34 AM
The number one rule is: don't call anything that starts with Get. The GL is designed for information to travel one direction: from the app to the hardware. Gets force a pipeline stall. Likewise, there is almost never a good reason to call Finish. Flush is OK but usually unnecessary, and flushing too often can slow you down.
Share:

This topic is closed to new replies.