Re: 8178 driver, VBLANK sync and CPU usage
Some updates on the weird sync to vblank bug.
After various upgrades (kernel, Xorg), I started my GL animation (full screen, 25 FPS)
- with _GL_SYNC_TO_VBLANK=0 and using glXWaitVideoSyncSGI() the CPU is always 100%
- with _GL_SYNC_TO_VBLANK=1 and glSwapping normally, the CPU is near 20%
- with a simple timed version (sleep(40ms) between frames) without vblank syncing, the CPU is 2-3% !
In both cases with vblank sync, I can see some black stripes occuring sometimes on top of screen. These stripes have a very small duration (1 or 2 refreshes, not more). I have a standard resolution for Plasma: 848x480. I tested on some other displays (23" 16:9 DFP, 21" 4:3 CRT ...) with different resolutions (640x480,1280x1024,1360x768 ....) and the same stripes appear regularly.
I also noticed that these stripes occur more frequently if screen resolution is higher (the bigger the surface is, the more stripes we get).
Of course, the problem can be in my source code too. But the same code worked well without problems of CPU usage or black stripes with previous drivers 7xxx. I logically suspect a driver 8178 bug ...
Also, another problem is the antialising settings: when activating __GL_FSAA_MODE=1 .. 8 (I tried all settings), some polygons are not rendered correctly ! I have to set FSAA mode to 0 if I want to get correct (but ugly) results.
My test configuration:
- ASUS A8N-VM CSM (Bios 0506)
- CPU: Athlon 64 3200+
- RAM: 512M
- Kernels used: 2.6.14.*, 2.6.15-rc*, 2.6.15
- Linux Debian distribution
- Nvidia Drivers 8178
- Xorg 6.9
Can someone confirm these bugs ? Of course, glxgears is not a good way to test. Perhaps mplayer -vo gl or mplayer -vo gl2.
Bug report attached (had to gzip it to fit 100Kb). How can I help more ?
[COLOR="Gray"][I]"Learn from other people's mistakes, you don't have time to make your own."[/I][/COLOR]