Spring is running in SMP

[DuGi]

ok, compiled without problems but now i have errors in console when large number of units is in the game... btw spring is running well but this is really annoying. (USE_GML_DEBUG=false)

Code: Select all

GML error: Sim thread called gmlGenLists
GML error: Sim thread called gmlGenLists
GML error: Sim thread called gmlGenLists
GML error: Sim thread called gmlGenLists
GML error: Sim thread called gmlNewList
GML error: Sim thread called gmlBegin
GML error: Sim thread called gmlMultiTexCoord4f
GML error: Sim thread called gmlMultiTexCoord3f
GML error: Sim thread called gmlMultiTexCoord2f
GML error: Sim thread called gmlMultiTexCoord2f
GML error: Sim thread called gmlVertex2f
GML error: Sim thread called gmlMultiTexCoord2f
GML error: Sim thread called gmlVertex2f
GML error: Sim thread called gmlMultiTexCoord2f
GML error: Sim thread called gmlVertex2f
GML error: Sim thread called gmlMultiTexCoord2f
GML error: Sim thread called gmlVertex2f
GML error: Sim thread called gmlEnd
GML error: Sim thread called gmlEndList
GML error: Sim thread called gmlNewList
GML error: Sim thread called gmlBegin
GML error: Sim thread called gmlMultiTexCoord4f
GML error: Sim thread called gmlMultiTexCoord3f
GML error: Sim thread called gmlMultiTexCoord2f
GML error: Sim thread called gmlMultiTexCoord2f
GML error: Sim thread called gmlVertex2f
GML error: Sim thread called gmlMultiTexCoord2f
GML error: Sim thread called gmlVertex2f
GML error: Sim thread called gmlMultiTexCoord2f
GML error: Sim thread called gmlVertex2f
GML error: Sim thread called gmlMultiTexCoord2f
GML error: Sim thread called gmlVertex2f
GML error: Sim thread called gmlEnd
GML error: Sim thread called gmlEndList

[zerver]

You have incompatible widgets. You can compile with USE_GML_DEBUG to find out which are to blame, or read here:
http://springrts.com/phpbb/viewtopic.php?f=1&t=19338

[AF]

Can we not just disable a widget if it uses rendering code in synced code? Surely the lua widget and gadget handlers should know when the code being called is synced or not and thus we shouldn't have such a fugly way of reporting these errors

[zerver]

Can we not just disable a widget if it uses rendering code in synced code?

Would be great. I have no idea how to programmatically disable a widget though.

[Kloot]

Gadgets (widgets have no synced code) can't be disabled without breaking the game they're part of anyway, so that wouldn't be a good idea. Best to just keep spamming errors.

[AF]

widgets yes but gadgets, it would be better to catch the error in the gadget handler and display errors that are more descriptive and less cryptic to the developer.

A gadget error should be handled at the gadget level, not the engine level, and certainly not the rendering sub system.

I would rather be told my xyz gadget is calling graphics calls in synced code, rather than being told "GML error: Sim thread called gmlMultiTexCoord2f" aka an arbitrary piece of synced code is calling opengl stuff.

I also think such a gadget level handling should be enforced regardless of wether an SMP executable is being used or not, or this problem will keep re-occuring as widgets and gadget are developed on test environments that aren't running multiple threads

[jK]

well, those assumptions are what they are, if you want lupsmanager on GML, it'll be easier to change the widget than the engine. just saying.

Seems you don't know how lua code is written. Perhaps it sounds as an easy job to you, but IT IS NOT.

That said, this problem with incompatible widgets is indeed fixable, but
* it would mean added complexity
* it might have negative effect on performance
* there is no "portable" way of doing it --> separate coding for linux/windows

Erm...
some facts:

• Yeah, you would have to write separate code for linux, windows & mac, BUT such code wouldn't be larger than 50 lines in total! And it would replace 90% of the current GML code (currently ~300kB large!), so it would REDUCE the complexity A LOT.
  Also all those delayed loading functions in the model loader could be removed etc.
• And yeah, it could decrease the performance under some conditions,
  BUT in the case of Nvidia you would finally make usage of "multithreaded optimizations", so there would be even an performance increase with that option enabled (no need to disable it anymore!).
• At last, it is the only clean way (in lua AND c++) and would even open a lot of new ways for performance increases, so you could precreate displaylists for the terrain drawer in 10 threads and then render them in the main render thread, or preload textures,models,vbos, etc.

[zerver]

That 90% of GML code is for the wrappers that allow you to draw in multiple threads simultaneously - something you cannot do with the solution you are suggesting (needs switching rendering contexts).

If someone wants to add those 50 LOC you are talking about to the engine, please go ahead. I have absolutely nothing against it . I do have my doubts on your claim about the "multithreaded optimizations" thingy though.

I would rather be told my xyz gadget is calling graphics calls in synced code, rather than being told "GML error: Sim thread called gmlMultiTexCoord2f" aka an arbitrary piece of synced code is calling opengl stuff.

And this is exactly what you get with the debug version. It is slightly slower though.

[jK]

untested!
this code is based on a lot of coke and some google searches/memories, I don't take any responsibilities for it ^^
cause I don't have a multicore cpu to debug it, nor the knowledge how to inter-communicate between threads in c++.

[imbaczek]

i never said it was _easy_, just that lua is _easier_ to change and test than c++.

[zerver]

If someone has a copy of [MTDEBUG]0.79.1.2-spring_exe_0.79.1.2-0-gbb45722.zip please upload it to springfiles. Thanks!

(the link on the download page is broken because as you know planetspring died.)

Could also rebuild it of course, but I'm not sure if the recent changes buildserv will cause a desync.

[bibim]

You can get it here.
(I have all planetspring files on my server if needed)

[Hacked]

is there a multithreaded version of the latest spring exe?

[zerver]

Yes, but it is not stable atm.

Crashes here almost every game:
http://github.com/spring/spring/blob/ed ... l.cpp#L211

You can still try it and send your stack traces to help me figure it out...
http://buildbot.eat-peet.net/spring/exe ... d79d6b.zip

Some stack traces from Linux would be very valuable too.

[Hacked]

lol it was never stable for me to begin with
cant go fullscreen, must set shadows=-1, alleged missing glextensions, small but plentiful lag spikes

ill give this one a shot though
thx for link

[zerver]

The instability in the MT release is possibly caused by a compiler problem on buildbot. I have been able to compile a stable MT release with another mingw version (TDM-1 4.4.0 sjlj). Unfortunately it for some reason prints a sync warning on start-up and also hangs on exit. Will not release anything until I figure out why.

[Hacked]

should i hold off until you release this new version?

[zerver]

That's probably best, bug reports will not help me much since this seems to be a compiler issue.

[zerver]

Okay, seems MT has issues with NaNs, probably in the rendering code. Not very surprising if you consider that it reads many intermediate values from the Sim.

So, I have disabled NaN checking and it works better. For some reason it also had to be compiled with -fsignaling-nans otherwise it was unstable.

http://springrts.com/wiki/Download

[Hacked]

i downloaded the debug version and tested it with bots (im afraid of crashing during multiplayer games)

spring crashed reliably after i was able to spam a few fleas on red comet with both RAI and KAI, thought i have the feeling it's an ai issue.

i have not experienced crashes with these ai's with the standard exe, and ill try to play online with others later