PDA

View Full Version : Alternative to glXWaitVideoSyncSGI



Bruce Wheaton
12-30-2011, 12:07 PM
I'm having a problem with glXWaitVideoSyncSGI, probably driver related.

http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=308282#Post3082 82

What's a good alternative? What I want to do is finish all rendering, then wait for the next swap to occur. Ideally I'll be starting at the very start of the next frame (near the VBI).

I currently use (on Linux) the standard:

glXGetVideoSyncSGI (&retraceCount);
glXWaitVideoSyncSGI (2, (retraceCount + 1) % 2, &retraceCount);

Is this a good candidate for a wait on one of the 'new' sync objects? Can I place one after the final swap and wait for it?

Bruce

Dark Photon
01-01-2012, 01:50 PM
What I want to do is finish all rendering, then wait for the next swap to occur. Ideally I'll be starting at the very start of the next frame (near the VBI).
With sync-to-vblank enabled...


glXSwapBuffers();
glFinish();

IIRC, this is a common idiom. Here the glFinish will wait not only until all the rendering for the current frame is finished, but also until any downsample necessary for presenting the current frame has completed as well and for the frame to be presented. AFAIK with this, unless your rendering code is breaking frame, you can be reasonably sure that after this you're at vblank.

If you don't do the glFinish(), the GL driver may read on ahead grabbing GL commands for the next frame (or frames) even before you've presented this frame, and will block on random GL calls in some future frame when the pipeline fills. This leads to the CPU side getting fairly out-of-sync with the GPU side, which can cause problems.

Bruce Wheaton
01-11-2012, 11:07 AM
I was wondering.... so in this case, where I've managed to move most of my main work to a single thread/context, and the thread is for this one job, blocking the CPU to wait for the frame to complete does no harm?

That's cool. It's the easiest solution. Thanks.

Bruce

Dark Photon
01-12-2012, 08:39 AM
I was wondering.... so in this case, where I've managed to move most of my main work to a single thread/context, and the thread is for this one job, blocking the CPU to wait for the frame to complete does no harm?
Far as I know, should be fine. Been using it for quite a while. It's about the only decent way to get good intraframe timing stats on the CPU in the GL thread. Otherwise you have the GL driver blocking things at random points, and not necessarily even for the frame to be displayed next.