[Request] Feedback on multithreaded simulation

[zerver]

I only have a sad dual core. Still worth/helpful to test?

To make it useful, please set SimThreadCount = 2 in the spring settings file.

Edit: To clarify, the reason you need a quad is that normally the sim+draw threads are enough for a dual core, although the sim thread will only max out its core in late game.

[zerver]

Btw, spring-multithreaded.exe in your package crashes, infolog attached.

Crashes/quits within first 20s of game on Zero-K multiplayer.)

Thanks for testing. Does this make any difference?
http://springrts.com/dl/buildbot/defaul ... ortable.7z

[zerver]

I nuked one more crashbug and added multithreaded projectile collision detection as well:

http://springrts.com/dl/buildbot/defaul ... ortable.7z

[Beherith]

build 360 mt-mt-sim still crashes:


Also:
We tested it with Bluestone in multiplayer. Pretty taxing test, no desyncs! Smooth as silk, yet drawframe always took way more than sim frame. Didnt go above 2 cores, but performed well!

Great stuff!

[zerver]

Code: Select all

[f=0000000] Error: Spring: OpenGL content Couldn't create an offscreen GL context: wglCreateContextAttribsARB failed!

Nice! It looks like a loadscreen crash, check if it helps with:
LoadingMT = 0

[Beherith]

Same crash with loadingmt=0

[zerver]

I think this has nothing to do with the MTsim in particular, but instead your graphics driver for some reason does not like some recent changes that jK made. You can test if the regular develop branch has the same crash:

http://springrts.com/dl/buildbot/defaul ... ortable.7z

[cleanrock]

I tried to build MTsim on linux yesterday:
https://github.com/spring/spring/commit ... nt-2063732

[Deadnight Warrior]

Code: Select all

[f=0000000] Error: Spring: OpenGL content Couldn't create an offscreen GL context: wglCreateContextAttribsARB failed!

Nice! It looks like a loadscreen crash, check if it helps with:
LoadingMT = 0

I had the same crash. Then used both LoadingMT=0 and MultiThreadShareLists=0 and it worked. Will try with MultiThreadShareLists enabled, but ever since 0.83 that option breaks rendering on Quadro cards and 64-bit Win drivers

Also, having SimThreadCount=0 and running MT exe causes a crash, setting that value to the number of CPU cores fixed it.

[Google_Frog]

Crash at about the same place.

Probably normal dev related:
* Unit models are not drawn.
* Zooming is smoothed, either something is broken or people are randomly fiddling with the defaults for springsettings.

[Forboding Angel]

Not sure what I'm doing wrong (or right).

Loaded up evo with it and everything seemed fine. During the countdown I was getting almost 600 FPS but it settled down to about 250 on game start and after some units were in the game finally decided to hover around 150.

Dropped to about 123 with 200 units on screen.

However, I looked in the infolog and see:

[f=0000000] [Threading] Multithreading is disabled because the game or system appears incompatible
[f=0000000] [Threading] MultiThreadCount > 1 in the settings will forcefully enable multithreading

And earlier in the infolog I notice:

[f=0000000] [Threading] Simulation multithreading is enabled with 5 threads
[f=0000000] [Threading] SimMT1 thread CPU affinity not set
[f=0000000] [Threading] SimMT2 thread CPU affinity not set
[f=0000000] [Threading] SimMT5 thread CPU affinity not set
[f=0000000] [Threading] SimMT3 thread CPU affinity not set
[f=0000000] [Threading] SimMT4 thread CPU affinity not set

So hell if I know what is going on.

I added multithreadcount = 2 to springsettings.cfg and try to load up evo and it crashes immediately. Then try to load up BA and it crashes immediately.

Mebbie the infolog will be more helpful.

infolog.txt

(29.02 KiB) Downloaded 20 times

The one I was using was: spring_{MTsim}91.0.1-360-ga4397a9_minimal-portable

[zerver]

Yeah sorry, the threads are confusing at the moment and a few of those messages will need to be rephrased.

[Threading] Multithreading is disabled because the game or system appears incompatible

This means your game (evo?) did not specify luaThreadingModel > 2 in the modinfo, so the engine will then assume that a separate main sim thread (one that is independent of the rendering thread) would cause lua compatibility problems and therefore the sim thread has been disabled.
http://springrts.com/wiki/Spring_Multithreaded_Lua

Simulation multithreading is enabled with 5 threads

This means that there are 5 sim helper threads. AFAIK they don't cause any compatibility issues and are therefore auto-enabled because you have a multicore CPU.

Mebbie the infolog will be more helpful.

Wrong infolog I think, looks like a clean exit to me. Thanks for testing!

Code: Select all

[f=0000423] MultiThreaded executable not detected (this is a good thing!) - Autoquit sending quit command.

But this message (evo 4.7) is possibly even more confusing than the threading messages.

[zerver]

Also, having SimThreadCount=0 and running MT exe causes a crash, setting that value to the number of CPU cores fixed it.

Infolog please!

[zerver]

Crash at about the same place.

Your crashes are deep inside Lua. Do develop builds crash in the same way?
http://springrts.com/dl/buildbot/defaul ... ortable.7z

[Forboding Angel]

Code: Select all

[f=0000423] MultiThreaded executable not detected (this is a good thing!) - Autoquit sending quit command.

But this message (evo 4.7) is possibly even more confusing than the threading messages.

derp -_-

Wrong infolog. Sorry, I was kinda tired and the messages kept confusing me into wondering if I was actually getting what I thought I was getting or if I was just screwing up and on the receiving end of a placebo effect. I have a gadget that exits the game if the user launches it with MT because previous MT builds would cause bad JuJu, however, I had remove it prior to running MT (cause otherwise it's like "lolMT ... exiting").

I'll retest and provide a clean infolog, just know that the one time I know for sure I was running MT, Evo didn't crash and my FPS was through the roof even with 200+ units moving around and pathing through each other etc + all of the cegs that each unit produces (only like 2 particles per unit though per second though). Also, I couldn't tell that any of the lua was broken by it save for the minimap events widget.

[Google_Frog]

Crash at about the same place.

Your crashes are deep inside Lua. Do develop builds crash in the same way?
http://springrts.com/dl/buildbot/defaul ... ortable.7z

Where? Do you have a stacktrace converter?

[zerver]

Where? Do you have a stacktrace converter?

Somewhere in DrawWorld... but I cannot reproduce the crash. Tried your short demo, and did torture tests with "give all" etc.

Yeah I have stack traces, but they are engine traces and not lua traces, so it is hard to figure out. Best you can do is test that develop build if it crashes in the same way.

[zerver]

200+ units moving around and pathing through each other etc

Yeah this is where it shines. I have seen the pathing thread use > 50% cpu, and on top of that the sim multithreading really helps when lots of units collide.

[Deadnight Warrior]

Also, having SimThreadCount=0 and running MT exe causes a crash, setting that value to the number of CPU cores fixed it.

Infolog please!

Didn't think it was that important, but here it goes.

[SpliFF]

Sounds awesome. Does this scale to > 4 cores or is the number of threads fixed? If so what is the practicality of passing pathing/collision tests to a pool of worker threads? I ask because I'm investigating the practicality of very high unit counts (10 - 20k) and it's possible (probable) a single core won't be enough to handle all the pathing or collisions. This is just a question, not a feature request.

Will try this out tommorow on my 6-core phenom. I assume the auto affinity wont mind the extra two cores?