View Single Post
Old 11-09-02, 04:25 PM   #3
ScoobyDoo
Registered User
 
ScoobyDoo's Avatar
 
Join Date: Nov 2002
Posts: 11
Smile

Hi, thanks for your thoughts

Yes, in order to get vertical sync going I am using the:

__GL_SYNC_TO_VBLANK

environment variable.

This does as it says, just in an unacceptably inefficient fashion!

It certainly does make calls to:

glXSwapBuffers()

wait for the vertical retrace, but while it is waiting, the CPU is at 100%. In the Windows drivers, the CPU would be at 0%.

Does this make sense? Same functionality, but one uses 100% CPU, and one doesnt. This is probably OK if you are running a game (where you generally dont care if other tasks get access to the CPU) but for a desktop application it is not good.

You are quite right about the poll() code - this was only ever a hack (albeit one that had been reported to work at one point on Linux) which I thought may trigger some peoples memory of this sort of thing.

What I would love is just for the code which is behind the:

__GL_SYNC_TO_VBLANK

to actually work like its Windows counterpart, not as a hack, but a reliable feature.

To see if it really is just me (!) please do compile up a simple OpenGL test program, and make sure it sits in a tight loop, with only glXSwapBuffers() to slow it down (no sleep() etc.).

Run this with vertical sync enabled and you should see on Linux/FreeBSD that it will consume 100% of CPU power whilst running. On windows, it will consume only a few % (depending on your setup) to do the same task.

I think the problem is, most people use OpenGL for games, and so are used to their CPU running at 100%. Games in general suck as much CPU power as possible.

Jamie Burns.
ScoobyDoo is offline