View Single Post
Old 04-13-06, 08:14 PM   #9
acoates
Registered User
 
Join Date: Apr 2006
Posts: 2
Default Re: even with 8756, minimal multitasking slows down glxgears performance

Finally found someone with the same problem, apparently.

I'm using the 2.6.16-1.2080 kernel + 1.0-8178 drivers. Everything functions properly, however, any program that attempts to take over the CPU causes graphics performance to tank (e.g., glxgears drops to ~20 fps; any of my own GL apps to less than 5 fps). Compiling the following trivial program and running is sufficient to cause problems:

int main(int argc, char* argv[]) {
while (1) {
}
return 0;
}

This is not a "performance issue" as suggested by the above posts -- several other machines with inferior hardware handle the workloads without any difficulty (one running Mandrake 9, on a 1.2Ghz Athlon...). It appears to be some kind of multitasking issue.

Additional info:

Hardware is not my own; basically a Dell machine with GeForce Quadro2, P4 2.8Ghz, 1GB RAM. It's not the card performance -- it runs beautifully when multitasking is functioning properly (explained in the following).

Nicing the CPU-hogging process reduces the problem substantially. The un-niced process successfully causes graphics performance of GL apps (but not other graphics like console updates, firefox, etc.) to drop unreasonably (again, not the expected drop as a result of normal multitasking). Really, I have more faith in the Linux scheduler than this (unless they've reverted to coop multitasking and not told anyone...) In top, you can easily see the test app consuming 90+% of the CPU (with other processes happily receiving time; but the GL apps are starved). After nicing the process, it continues to use 90+% of the CPU, but the GL apps performance improves substantially and they receive an apparently "fair" share of the CPU budget (sufficient, at least, to maintain an acceptable frame rate).

The use of the glFlush() call appears to worsen the problem substantially. While I would expect this to reduce frame rates somewhat, its use in this case appears to stall the caller for as long as 100's of milliseconds.

I'd attach my "bug report" file, except that it exceeds the length allowed by the forum...
acoates is offline   Reply With Quote