Bug: glFinish and glXWaitGL busy-wait for vsync buffer swap

[bearoso]

I've known about this driver bug for a while, and I'm bringing it up now with hopes that it'll be fixed. The problem is that when the GLX function glXSwapBuffers waits for the vblank interval, the glFinish and glXWaitGL functions seem to use a busy-loop to wait for the buffer swap, causing 100% CPU usage. I've attached a small sample program to reproduce the problem. It can be compiled as follows:

$ gcc glbusy.c -o glbusy -lX11 -lGL

after renaming the attached glbusy.c.txt to glbusy.c.

Run the application with vsync enabled in nvidia-settings or with

__GL_SYNC_TO_VBLANK=1 ./glbusy

and it will use 100% of the CPU or a core. After commenting out the glXWaitGL on line 55 of the source and recompiling, the same application uses very little CPU time because the glXSwapBuffers function itself correctly waits for the previous swap to finish by using an interrupt or other method.

This bug affects situations where a GL window is encapsulated inside another GL window, like running OpenGL applications on a window compositor. For 1:1 frame-to-frame correspondence, a compositor needs to know that the framebuffers of the child-windows are complete/swapped before deriving the textures from them. Either glFinish or glXWaitGL is needed because glFlush and friends don't make this guarantee. glXSwapBuffers only provides an implicit glFlush.

I've attached a nvidia-bug-report.log, also, for completeness.

[etherfish]

Try setting 'Option "UseEvents" "on"' in your Screen section. The busyloop will be replaced by a poll() system call.

[bearoso]

Originally Posted by etherfish

Try setting 'Option "UseEvents" "on"' in your Screen section. The busyloop will be replaced by a poll() system call.

The line is already there. Said function calls still use a busy loop--hence the bug report.

[etherfish]

You know, I spoke too fast, I just enabled that option myself and ran your test to find the same behavior. I must admit my naïvete, however; I added a call to glXWaitVideoSyncSGI(1, 0, .. ) between glXSwapBuffers and glWaitGL() and glbusy no longer consumed 100% CPU. Placing glXWaitVideoSyncSGI() before the glXSwapBuffers() or after the glWaitGL() glbusy only consumed 50% CPU. To be perfectly honest, I don't know where the glXWaitVideoSyncSGI() call belongs.

Also, I'm too inexperienced to divine if this information is actually helpful to you or not. I apologise.

[etherfish]

I should add, the first case I described with the glXWaitVideoSyncSGI between the glXSwapBuffers and the glXWaitGL() calls consumed so little cpu time that it failed to register on the output of top.

[bearoso]

Originally Posted by etherfish

You know, I spoke too fast, I just enabled that option myself and ran your test to find the same behavior. I must admit my naïvete, however; I added a call to glXWaitVideoSyncSGI(1, 0, .. ) between glXSwapBuffers and glWaitGL() and glbusy no longer consumed 100% CPU. Placing glXWaitVideoSyncSGI() before the glXSwapBuffers() or after the glWaitGL() glbusy only consumed 50% CPU. To be perfectly honest, I don't know where the glXWaitVideoSyncSGI() call belongs.

Also, I'm too inexperienced to divine if this information is actually helpful to you or not. I apologise.

glXWaitVideoSyncSGI is an very archaically-designed extension for its purpose and shouldn't be needed if glFinish/WaitGL operated correctly. Not to mention that placing it after the buffer swap would have the effect of forcing a horribly mistimed application-side vsync even when the swap doesn't want to use it. The solution for this problem needs to happen in the driver.

[bearoso]

I still see this in drivers as recent as the 190.xx set. I've since noticed this problem can be lessened by using __GL_YIELD="USLEEP", with which it uses about 3% of the CPU instead of 99%.

[AaronP]

I should point out that this is not a bug: the spec does not require a particular maximum CPU usage when these functions are called. However, conserving a CPU would be a useful feature request, so I'll see if I can reproduce the issue and will file a feature request.

[asch]

Originally Posted by AaronP

I should point out that this is not a bug: the spec does not require a particular maximum CPU usage when these functions are called. However, conserving a CPU would be a useful feature request, so I'll see if I can reproduce the issue and will file a feature request.

Hi!

The same issue is present today.

I have written a simple openGL texturing benchmark application that can be copiled easily on Linux: http://pastebin.com/f5f9c076f

Running with: $ ./glfwTexture
top says the process consumes a CPU core to about 100%
Running with: $ __GL_YIELD="USLEEP" ./a.out
top says the process consumes a CPU core to about 5%

Both cases make about 30 FPS. The only difference is CPU usage.

I believe it is a bug. Is there a standard way to configure openGL to wait GPU idling the CPU so that other threads may use it?

I am using NVIDIA driver version 190.42 on "Linux xxx 2.6.31-15-generic #50-Ubuntu SMP Tue Nov 10 14:53:52 UTC 2009 x86_64 GNU/Linux". My GPU hardware is: GeForce 9400 GT

[sswam]

FYI, if anyone is in a position to fix this, an easy way to sleep precisely and fairly reliably without burning 100% cpu is to nanosleep() or similar for perhaps 100 micro seconds less than the actual sleep time required, then to busy wait until the exact time. Not sure if this is applicable in waiting for vsync, depends whether the time of next vsync can be predicted with any accuracy. It should be possible.