PDA

View Full Version : glGetSynciv takes too long



mfort
05-10-2010, 07:07 AM
I've added support of ARB_sync to my engine. Unfortunately it does not work as I expected. Function pair glFenceSync/glWaitSync works well, no complains. But functions glFenceSync/glGetSynciv does not.

I have two contexts that must be synchronized. First context prepares something for the second context. When the job has not finished yet, the second context does not complain, it will ask next time. This works well in theory, not in practice. I check the fence by calling glGetSynciv(sync, GL_SYNC_STATUS, ...). Unfortunately there is some kind of stall in OpenGL drivers. The function does not return immediately. It depends on how much is in the pipeline. The function takes between 0.002ms up to 10ms! (CPU time). But if I call glGetSynciv in the same context I called glFenceSync, then the function returns immediately (0.002ms) even if pipeline is full.

I know almost all glGet* stall. But in my opinion this one should not stall. I really do not want to wait until it returns GL_SIGNALED. For waiting there are gl*WaitSync()

Is there any way to check fence status without stalling? Or is this a driver bug?

GTX260, Win7 x64, drv 197.45

Alfonse Reinheart
05-10-2010, 10:02 AM
I really do not want to wait until it returns GL_SIGNALED. For waiting there are gl*WaitSync()

What makes you think you have to? Observe:



If the value of <timeout> is zero, then ClientWaitSync does not block, but simply tests the current state of <sync>. TIMEOUT_EXPIRED will be returned in this case if <sync> is not signaled, even though no actual wait was performed.


Simply use the appropriate WaitSync function with a timeout of zero. Check the return value; if you got TIMEOUT_EXPIRED, then you know it isn't signaled yet.


Is there any way to check fence status without stalling? Or is this a driver bug?

As always, OpenGL defines behavior, not performance. So it is not a driver bug.