nV News Forums

 
 

nV News Forums (http://www.nvnews.net/vbulletin/index.php)
-   NVIDIA Linux (http://www.nvnews.net/vbulletin/forumdisplay.php?f=14)
-   -   8178 driver, VBLANK sync and CPU usage (http://www.nvnews.net/vbulletin/showthread.php?t=62414)

morgoth 12-29-05 08:55 PM

8178 driver, VBLANK sync and CPU usage
 
Hi all

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 2.6.14.2 and 2.6.14.5. 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

morgoth 01-05-06 05:37 PM

Re: 8178 driver, VBLANK sync and CPU usage
 
1 Attachment(s)
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 ?

netllama 01-05-06 09:50 PM

Re: 8178 driver, VBLANK sync and CPU usage
 
Are you able to reproduce this problem with mplayer -vo gl or mplayer -vo gl2 ? If so, does it require any specific content to reproduce? If not, please provide a reproducable test case.

Thanks,
Lonni

morgoth 01-06-06 05:55 AM

Re: 8178 driver, VBLANK sync and CPU usage
 
Quote:

Originally Posted by netllama
Are you able to reproduce this problem with mplayer -vo gl or mplayer -vo gl2 ? If so, does it require any specific content to reproduce? If not, please provide a reproducable test case.

Hello Lonni...

In fact there are 3 problems to deal with and they're possibily linked (1 & 2):

1) glXWaitVideoSyncSGI() using 100% CPU
2) random black stripes / flashes with __GL_SYNC_TO_VBLANK=1
3) FSAA problem on 6150 only

To reproduce the problems:
1) use a program that calls glXWaitVideoSyncSGI to synchronize.
"mplayer -vo gl:swapinterval=3 foo.avi" seem to reproduce the same problems of CPU usage: I display a 25 fps video on a 75Hz display => swapinterval=3, CPU=100%. I'm not sure that mplayer code is really clean and uses GLXWaitVideoSync, so it would be better to code a simple program to reproduce the pb. But the symptoms are the same.

2) quite difficult to reproduce with mplayer. A simple program should do the trick easily => I'm going to write it

3) the FSAA problem is ONLY on 6150 (no problem on GeForce 6200, 6600 or Quadro FX 3400). I saw it when displaying a lighted scene. On non lighted scenes, there seems to be no problem...Really strange...Again, I suppose I have to write some code to make an evidence. (should I work at nvidia ? ;-)...

netllama 01-06-06 04:16 PM

Re: 8178 driver, VBLANK sync and CPU usage
 
morgoth,
I've reproduced the first issue (glXWaitVideoSyncSGI() using 100% CPU) and opened bug 204753. Right now, this issue appears to be resolved in an internal development driver, so its likely that this issue will also be resolved in the next driver release.

I'll need you to provide a means of reproducing the other two issues that you listed, and I'll be happy to investigate them further.

Thanks,
Lonni

morgoth 01-06-06 05:19 PM

Re: 8178 driver, VBLANK sync and CPU usage
 
Quote:

Originally Posted by netllama
morgoth,
I've reproduced the first issue (glXWaitVideoSyncSGI() using 100% CPU) and opened bug 204753.

Fine. Happy to see I'm not the only one ;-)

[/quote]
Right now, this issue appears to be resolved in an internal development driver, so its likely that this issue will also be resolved in the next driver release.

I'll need you to provide a means of reproducing the other two issues that you listed, and I'll be happy to investigate them further.

Thanks,
Lonni[/quote]

OK. I'm going to write some code to reproduce the problems (black flashes and missing polygons with FSAA enabled and why not some sync to vblank testing so you can experiment a "low cpu usage" sync to vblank ;-)..Just kiding...

In mid time I had another bug... Sorry Lonni ....;-( This one is more serious. It's a freeze problem when starting Xorg. More to come soon on this...

Thanks for your commitment !

ReimarD 01-07-06 03:36 PM

Re: 8178 driver, VBLANK sync and CPU usage
 
Quote:

Originally Posted by morgoth
"mplayer -vo gl:swapinterval=3 foo.avi" seem to reproduce the same problems of CPU usage: I display a 25 fps video on a 75Hz display => swapinterval=3, CPU=100%. I'm not sure that mplayer code is really clean and uses GLXWaitVideoSync, so it would be better to code a simple program to reproduce the pb. But the symptoms are the same.

I sure hope that at least in this case the MPlayer code is clean :-)
Anyway, it uses glXSwapIntervalSGI (GLX_SGI_swap_control extension), since I never got GLXWaitVideoSync to work (probably stupidty on my part).

morgoth 01-09-06 06:37 AM

Re: 8178 driver, VBLANK sync and CPU usage
 
Quote:

Originally Posted by ReimarD
I sure hope that at least in this case the MPlayer code is clean :-)

I hope too ! (and after a look at it, I'm quite sure ;-)

Quote:

Anyway, it uses glXSwapIntervalSGI (GLX_SGI_swap_control extension), since I never got GLXWaitVideoSync to work (probably stupidty on my part).
Correct me if I'm wrong, but both extensions have the same goal (with differents calls and features: GLXWaitVideoSync seems more flexible than glXSwapIntervalSGI).

Mplayer uses one extension, and I use another in my sources. Both extensions lead to a 100% CPU usage problem. So it's not an "extension" problem: the driver has a bug regarding refresh and vblank. That's all !

Hope this will be fixed soon :)


All times are GMT -5. The time now is 01:24 PM.

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.