NVIDIA Linux + Multicore FPS Fix

[echoone]

It seems NVIDIA + multiple cores, with Spring, has some performance problems. It appears the problem is especially bad on 64 bit Linux too. Fixing the problem seems to be pretty easy.

For the one other person I've tested with, FPS seems to pick up roughly 50% - 80% with Spring. It makes a HUGE difference. So if you're running Linux + NVIDIA and have multiple cores, do try this out!

Do this:

export __GL_SINGLE_THREADED=1
./springlobby

For me, this simple change makes the difference of crapping out (0.01 - 1 FPS) 80% though large multi-player games to having 15-30 FPS at the end of these same games. This also means I can crank up the graphics settings and even enable some AA.

Also, do not add this as a variable to your general environment. It is most definitely bad for most opengl applications. Accordingly, only set it in the environment in which you plan to plan spring.

Hope this helps others.

[Pithikos]

Can you give some more detailed guidance to a Linux noob like me?

[echoone]

Sure.

Start a command shell (gnome-terminal, konsole, xterm, rxvt, etc). Type, "export __GL_SINGLE_THREADED=1", and hit enter. Now, start your lobby client.

If the lobby client is in your path, you can locate it by typing, "which lobbyclient", followed by enter. If its not found, you'll need to locate it by other means. Depending on your install, "locate lobbyclient" may help. Of course, if its in your path, you should be able to start it by simply typing, "lobbyclient", followed by enter.

Once you know where its at, start it up in the terminal window by typing, "/your/full/path/to/lobbyclient". Obviously your path will be different than the example to the left. After you hit enter the client should pop up. Nothing will seem different until you get into your game via FPS improvements.

Of course, to see improvements you must have multiple cores/cpus and an NVIDIA card. I believe a 8000-series card or latter is also a requirement but I'm not sure on that part. I believe AMD systems, especially 64 bit, are especially partial to this improvement too.

[del_diablo]

Don't tell you have not reported this bug yet?
So which side causes the bug?
The kernel drivers for the CPU? (Most likely not)
Nvidia's propitary drivers?
Or is it a spring bug?

[echoone]

Don't tell you have not reported this bug yet?
So which side causes the bug?
The kernel drivers for the CPU? (Most likely not)
Nvidia's propitary drivers?
Or is it a spring bug?

Well, I'm not 100% on exactly what's going on. From what I've been able to determine, I believe Spring is at fault. Please note this is not an assertion of fact.

I think its something along the lines of spring and the drivers are both attempting to impose their own pipeline locking. This in turn is increasing delays for spring to submit a new pipeline, which is already locking out other Spring, non-synchronized threads. In other words, even when spring is not synchronizing pipeline access, the driver still attempts to do so by means of internal locking, which is enable when multiple cores/cpus are detected.

I believe the contention comes from various Lua UI threads which are also attempting to use OpenGL for various GUIs and special effects. The combination is mutually exclusive to nvidia's multithreading optimizations and creates lots of uncoordinated locking contention, which results in yet more contention on Spring's side.

By explicitly disabling nvidia's threading optimizations I believe this is reducing lots of lock contention within the driver and therefore reducing the window for contention within Spring and Lua (they wait less time within the driver). Thereby, effectively reducing lock contention within Spring; albeit at the cost of possibly unsynchronized opengl access by other Spring threads. But since the window for trouble has been reduced, the chances of misc. crashes from unsynchronized access (race condition) has also been reduced.

Since I've started using this trick, my self and my brother have seen both huge increases in FPS as well as much fewer Spring crashes. Likewise, I'm now able to use the multithreaded binaries without crashes. The fact I don't see crashes with any other OpenGL games further lends support this is not an nvidia issue.

Lastly, in this fairly old thread, you can see threading improvements have been in the works for a long time now. And based on both that thread and my own observations, things have steadily been improving in that regard. I suspect when they have everything fixed and properly synchronized within Spring itself, use of this fix will no longer be required. Heck, depending on the details, no longer using this fix may actually slightly benefit performance.

[hoijui]

since this change:
http://github.com/spring/spring/commit/ ... 2fede10daa
(will be in spring 0.83)

Code: Select all

export __GL_SINGLE_THREADED=1

will crash spring when initializing SDL/OpenGL.

So when 0.83 is released, you should no longer use this. It is not a bug, as explained in this report:
http://springrts.com/mantis/view.php?id=2105

__GL_SINGLE_THREADED supposedly fixes buggy dynamic loader in linux if and only if the application is single threaded. Spring isn't exactly single threaded anymore.