Spring is running in SMP

[Kloot]

Yep, the dynamic ingame pathfinding would be a much bigger
issue if it used multiple threads even on single-core machines
(that's why I'm working on that in my own separate branch ).
I do not believe however that the pregame mthreaded pathing
should only be part of a second (MT-enabled) executable, it's a
bit too trivial IMO to be #ifdef'ed for the sake of it.

[Tobi]

Note that zerver is going to use boost Thread::hardware_concurrency to replace his code to detect number of processors (which was Intel copyrighted). Maybe that would be useful too as default number of threads for the pre-game pathing.

[Argh]

Hey guys... one question... has zerver's code sliced all of the OpenGL calls out of the gamecode? Or is that still a side issue?

[clericvash]

So can someone explain to me basically this:

If i have a dual core system or a quad core, will spring eventually now how to deal with it with these changes that are comming/in progress?

Thank you.

[AF]

eventually, yes. How far away that eventually is however could be a long time for all we know. Depends how much testing gets done.

[zerver]

Hey guys... one question... has zerver's code sliced all of the OpenGL calls out of the gamecode? Or is that still a side issue?

What I did, you can see for yourself here:
https://spring.clan-sy.com/svn/spring/branches/gml/

The OpenGL multithreading library is located in rts/lib/gml
Very much macro based which makes the code difficult to read - sorry for that.

It essentially redefines (patches) all GL calls. So, the GL calls themselves look the same as they did before, but a different function is in fact called.

I did some testing with the profiler today and can confirm that all the four parts I have multithreaded do in fact increase the performance.
However, this is with my system (8 cores). Many units and/or large maps in combination with high graphics settings seem to give the best results. You may get very different results, please have a try.

I also tried threading a fifth part today (the CSmfReadMap::GridVisibility) but I'm afraid it ran slower than when single threaded.

[Vadi]

This certificate thing is making FF3 bitch pretty badly.

[reivanen]

This sounds like pure win.

[rattle]

Are there any special preparations to make for building? I'm getting tons of errors when building with scons.

edit: never mind

[Argh]

Thanks for posting that zerver, I'll take a look-see when I get home this afternoon. Probably won't have anything intelligent to say about it, mind ye, I know zip about multithreading. My understanding was that moving the OpenGL stuff out of the gamecode was the first major step to rebuilding the rendering system, though, so I'm rather curious as to what that part looks like.

[zerver]

My understanding was that moving the OpenGL stuff out of the gamecode was the first major step to rebuilding the rendering system, though, so I'm rather curious as to what that part looks like.

Well, if you mean moving all GL code out of the Sim that has not been done yet. My code does run SimFrame in a separate thread though, so any GL calls in there end up in the producer-consumer system. This makes it dead easy to locate the functions in question so we can get rid of em.

[Forboding Angel]

Zerver, I would just like to express my thanks for taking us in this direction. It has been somewhat badly needed for some time now, and it's really neat to see someone tackle this extremely difficult task, so...


Thanks!

[Vadi]

+1, thanks much.

[Argh]

Took a look at it, zerver. I'm a little confused about what you mean by the server being forced to run in sync... does that mean that the player serving as the game server will run all commands in sync, including all graphical events?

As for the GL calls in gamecode... the big, nasty area is the mix of COBHandler calls and other gamecode and drawing 3DO / S3O models. Most of the other crap is minor, and could be fixed fairly easily, by just converting the calls to OpenGL within the functions to a call to the Custom Explosion Generator code (CEG) and letting it execute the effect- the vast majority of the little stuff is hardcoded special effects that have been around since SJ was still coding Spring.

[zerver]

Took a look at it, zerver. I'm a little confused about what you mean by the server being forced to run in sync... does that mean that the player serving as the game server will run all commands in sync, including all graphical events?

Synced in this case means a worker thread will encounter GL calls, put them in the queue, and as soon as a new GL call has been put in the queue, it will be processed by the server thread. So, the server is running "immediately behind" a worker.

Why do this? Well, if the GL call has a return value, the worker cannot continue until the server has processed the GL call and supplied the actual return value to the worker. Synced is bad for performance since the rate at which GL calls are processed will be limited by the rate that a single worker produces them. This is why GL calls that return data should be avoided in threaded code.

In other words, this concept has nothing to do with the spring gameplay "Sync" at all.

[BoredJoe]

While I'm not sure how widgets are loaded/run currently, it should be pretty easy to multithread LUA widgets - giving each widget its own thread.

There are practically no dependancies (if any) from spring to the widgets themselves so it could bring some easy performance gains to those who run a lot of the more cpu heavy widgets.

The only potential problem/overhead I can think of is if multiple widgets try to access or load a file simultatiously, but I don't think any widgets do this and the only collision i can think of is if 2 widgets load the same image file at the same time.

[imbaczek]

widget per thread is not a workable idea - I don't think the lua interpreter is threadsafe. Whole LuaUI in a thread would be doable, I guess, but only with great care.

[jK]

The engine doesn't even know that there are objects called "widgets", the engine only starts some specific lua files (named main.lua and draw.lua). Widgets/Gadgets are defined by the widgetHandler.lua and gadgetHandler.lua
Also widgets/gadgets share HUGE of their code, not to forget that they need to run in a specific order (they have OpenGL access!) and share their enviroments...
And yeah even Lua itself isn't threadsafe.

[BoredJoe]

widget per thread is not a workable idea - I don't think the lua interpreter is threadsafe. Whole LuaUI in a thread would be doable, I guess, but only with great care.

doh! didn't think about that. Edit: It's far too easy to confuse yourself when thinking about multi-threading things. I was originally thinking about threading only the lua logic itself, but as almost all of that logic is based off of spring calls, it wouldn't do much.

Threading entire widgets would add quite a bit of work/overhead now I think about it. You could parse the lua file, see what spring functions are called, then either do a lot of locking or allocate and deep copy lots of memory which you need to keep updating. Not really worth it lol.

[zerver]

I have made various changes and updated my branch with the latest stuff from trunk.
https://spring.clan-sy.com/svn/spring/branches/gml

I want to put it in trunk real soon, so I need to know if this compiles/runs with non-MSVC compilers.
Please tell me about your findings... Thanks!

When it goes in trunk it will be disabled by default.
This is done by setting GML_ENABLE 0 in the file gmlcls.h