8178 driver, VBLANK sync and CPU usage
I currently have a GL app which has several possible refresh modes:
1) - using __GL_SYNC_TO_VBLANK
2) - using glXWaitVideoSyncSGI
3) - using nanosleep() (no sync to vblank, but accurate framerate)
Using __GL_SYNC_TO_VBLANK is quite expensive (some polling code should propably be removed here. But we can't use the source, luke...) and that's why I coded another sync function using glXWaitVideoSyncSGI: with driver 7174 that was perfect as the CPU usage was much lower (a GL animation was displayed at 25fps with a syncing overhead of 10% CPU vs. 30% with __GL_SYNC_TO_VBLANK)
A bad surprise when upgrading to 8178: the glXWaitSyncSGI takes now 100% CPU ! This was tested with mixed configurations including GeForce6150, GeForce 6600 and Quadro FX 3400, with Pentium 4 or Athlon 64 CPUs, with ASUS, Gigabyte, Fujitsu Siemens motherboards. Linux kernel was 188.8.131.52 and 184.108.40.206. In all cases, the same problem: 100% CPU when calling glXWaitSyncSGI ().
So, I don't think it's a hardware issue...
Question 1: is it a referenced bug or am I missing something in the README ?
Q2: is there a workaround ? Of course without using the *unefficient* (not to say more...) __GL_SYNC_TO_VBLANK.
Q3: If no workaround, should I suppose that anybody who want's to display GL frames *has* to burn 30% more CPU ? This has bad side effects: The extra 30% make an Athlon64 3200 work at 2GHz where it could display normally at 1GHz: 40Watts, some celsius degrees and some dB more just to wait for a vblank. Is this waste really necessary ?
Q4: why is the __GL_SYNC_TO_VBLANK so CPU intensive ? this makes quite a long time this problem exists. I get CPU usage problems since 4xxx/5xxx drivers and nothing was *really* done to correct this situation. Is there something to code/add/remove/tune on the linux kernel side, or more generally something that open source community can handle ?
Thx for help and suggestions
[COLOR="Gray"][I]"Learn from other people's mistakes, you don't have time to make your own."[/I][/COLOR]