Multiple OpenGL applications and NVidia
I haven't seen anything about this listed in any FAQs that I have seen. What I'm seeing is that if I run multiple applications that utilize OpenGL simultaneously, when I start more and more of them eventually all newly started apps no longer get accelerated rendering. This only happens on NVidia hardware with the NVidia proprietary driver. It does not happen with other cards, and I have not yet tested with the XF86 nv driver (I have a GeForce 3 card and will need to upgrade my RedHat 7.2 install to XFree86 4.2).
An easy way to reproduce this problem is with tuxracer. If I set my display to 1600x1200x24, and then open up 3 copies of tuxracer running windowed at 1280x1024x24, in each window all 3 will run just fine. But if I open up a fourth copy of tuxracer, it will run extremely slowly, and closing the other 3 running copies will not speed it up. It really appears to be running unaccelerated.
This isn't just a problem with tuxracer. All moderatly complex OpenGL apps appear to reach a threshold at some point. I haven't been able to find that point with simple apps like "gears" or "tunnel" yet, though. Opening lots of these apps while using NVidia's driver locks the entire system up before I get to the point were I see the above problem.
Does anyone have a clue what NVidia is doing odd with their driver? Is there any way to tune this to make it go away?
I'd really appreciate any insight that anyone has to offer.
Well first of all, nvidia's drivers are EXTREMELY memory hungry... The reason is they try to push as many frames as possible with total disreguard for system performance. And the best answer you will probably get is to use more swap space... that will stop the crashes that you have been suffering with...
But as far as making the drivers use less resources, there isn't a good answer at all... Oh yeah and by the way, if you have to start 4 copies of any single application that will use the same textures, then you can use the same textures repeatedly (pass the same pointers back) so you don't have to load the same textures into video ram at the same time...
I had just used tuxracer as an example for ease of reproduction. In reality I am experiencing the problem while trying to run several completely different OpenGL apps. Also, this is not a memory issue as the machine has 2GB of RAM... tuxracer isn't *that* memory hungry.
Today I discovered that if you switch to a virtual console and then back again while the apps are running (Ctrl-Alt-F1, then Ctrl-Alt-F7), it fixes the problem. All 4 copies of tuxracer will all run at speed. This definetly looks like a bug.
NICE FIND :)
I never thought about switching to console and back... :)
hopefully they can locate and fix this bug quickly :)
Well, maybe. I'm getting the standard "you need to buy a Quadro card" from NVidia so far. This does indeed look like a problem you might run into without Unified Back Buffer support, but I'm trying to convince them there's more to it than that. Without UBB, it's possible you can get your card into a super memory thrashing state if you open up a lot of double buffered applications, but it looks like NVidia's driver doesn't allow this state... if you requirest buffer space and you are out of VRAM it just denies acceleration alltogether, and when buffer space becomes available again it doesn't reallocate it to apps that need it so they keep running unaccelerated. The fact that this little virtual console switch can allow you to run a few more apps accelerated than were running before the switch shows that you really can squeeze more apps into VRAM if you "repack" the allocations, and so their normal allocation method is not being as efficient as it should.
Anybody have any tips or thoughts for or against this theory?
Well there is always the mod to turn your gfX card into a quadro card (it really does work) If you remap the same textures instead of loading them again (I have started work on such an algorith, but its not done yet) then you don't have to load up all the textures for all the applications (assuming that your apps will be using many of the same textures over and over again) this way you can save video ram space
I experienced similar problems with my Quadro-4, runny only two OpenGL apps.
It wasn't just dropping to unaccelerated, it was totally bogging down to the point that it took seconds to render even a wireframe box... even with a software implementation, OpenGL normally flies on my machine.
Unfortunately, I can no longer duplicate this problem. It was happening a few weeks ago, and the only solution I found was a reboot (restarting X was not sufficient), although if it happens again, I will try the console switching suggested.
It may be that I no longer have this probelm. The only changes I've made in the interim was deleting the "static" libGL.a and libGLU.a (hmmm?), and changing some nfs mounting parameters (definitely unrelated).
If I learn anything, I'll make sure to post.
OpenGL lib really buggy?
I see the same problem using xmms visualization plugins; after 15-20 times i start plugins which uses OpenGL library, several plugins will run very very slow.
Notice that i don't start OpenGL programs simultaneously, but from xmms i
load a visualization plugin
unload the visualization plugin
start new visualization plugin
The problem occurr after 15-20 times i start a plugin using OpenGL and SDL libraries.
Another info: i'm using Mandrake 8.2 with an Athlon XP1800 and via chipset; i've seen an increment of performance instaling the newer XFree86-libs-4.2.0-25mdk instead of the version installed by Mandrake (4.2.0-10mdk): in this package the library /usr/X11R6/lib/libGL.so.1.2 is included, and with the new version opengl plugins are much faster!
Also i suppose that this library is responsable for the problems you have stated.
Please try this library!
I've just upgraded the XFree86-libs package, and till now i have not seen the problem above mentioned. BTW i have not tried enough.
Ok, that's all for now.... sry for my very poor english. Paolo
|All times are GMT -5. The time now is 02:29 AM.|
Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Copyright ©1998 - 2013, nV News.