Spring is running in SMP

[Stealth870]

Yea, using BA in the Air Combat test, as soon as they start shooting each other I get a lot of:
GML error: Sim thread called gmlMultiTexCoord4f
GML error: Sim thread called gmlVertex4f
GML error: Sim thread called gmlEnd
GML error: Sim thread called gmlEndList

[Pressure Line]

Yea, using BA in the Air Combat test, as soon as they start shooting each other I get a lot of:
GML error: Sim thread called gmlMultiTexCoord4f
GML error: Sim thread called gmlVertex4f
GML error: Sim thread called gmlEnd
GML error: Sim thread called gmlEndList

possibly lups. or a ceg going horribly wrong

[zerver]

OK, it could be that there are still some GL calls that need to be factored out from the test script. I will look into this.

Please note that normal gameplay with BA should be fine though. You will not get spammed with GML errors.

And the good thing is that you will have roughly 25% higher FPS on a quad core in a big game with many units.

[reivanen]

Something in ca crashes this gml build, but in ba this gives nice fps improvements on my computer (70->90 at gamestart with only comm)

[zerver]

That's interesting. On my system I have the opposite effect. With only comm, FPS is lower because of increased overhead of the synchronization and thread handling.

CA is confirmed not working, at least with LUAShaders on. You could try turning it off.

[Stealth870]

Been playing a couple more games. Only seems to happen when aircraft show up. And unfortunately spits out the errors during my multiplayer games, so I can't see the chat!

[reivanen]

zerver, quite possibly you have made some serious bug lesser with your changes, i mean i still get utterly poor performance, some kind of compatibility issue.

My laptop with core2 and gf9500 runs in the 150:s fps and my main computer with core2 and gf8800 which is about twice as fast in gaming runs spring with the fps mentioned in last post.

about the ca: yeah i knew that, i just said it wrong I tried to put all the gl. calls into draw* but only succeeded in making the faulty widget hang even on normal spring :D Would need to study lua some more.

[zerver]

Been playing a couple more games. Only seems to happen when aircraft show up. And unfortunately spits out the errors during my multiplayer games, so I can't see the chat!

Alright... disable LuaUI and LuaShaders until it has been fixed.

[xyz]

Nice job.

I have been tested this branch and here is what i got:

PC:
AMD X2 5000+, 2G of ram, GeForce 9800 GT 512Mb
OS:
Windows XP sp3
The game:
version R7105, resolution 1024x615 (wide screen), Shadows on (1024 map size), reflection on, LuaShaders off, dynamic water, and everything pretty much set to max.

Results:
- The frame-rate didn't go up but instead it became a lot more stable
1) Before at the beginning of a game with no water FPS was around 110 on this patch is around 50; On a map with water (set to dynamic) without MT FPS was around 40 with MT the same thing.
2) Later in the game without MT FPS drops to 15-20 with MT it never dropped under 30; although if the thread that is running the sim is overloaded the units start "jumping" around the map, and also the health bar on top of the units flickers.

Bugs:
I found a really nasty hang, but i am not very sure how to reproduce it, but it happened 3 times now and only with MT on and while I was spectating (2 times in a AI vs AI game, and once in a network game) and after 20 min of game-play (decreasing or increasing the game-speed didn't have any effect). After the hang the game became completely unresponsive, even after pressing ALT+TAB windows is unable to draw anything on-top of the game window, but i suspect that's because of the always on top property of the game window. The only way to recover was to terminate the process.

[zerver]

Hi!

Did the hangs occur with LuaUI disabled?

I've had only one hang with 7105, and that happened when I alt-tabbed before game start so I can't be sure it was due to threading.

You are correct there are some graphical glitches. The FPS HUD is a bit borked and units also tend to jump slightly as they leave factory. This is not a big deal though.

The next time it hangs, search your infolog for "GML error".
If you find any, it means there is a risk for hang.
Otherwise it is probably some deadlocked mutexes.

[xyz]

looks like LuaUI is to blame, i forgot to turn it off, once i did that i was unable to reproduce the bug, sorry for the false alarm.

[imbaczek]

IMHO GML errors should be printed also in a single-threaded builds if it's not expensive.

[zerver]

IMHO GML errors should be printed also in a single-threaded builds if it's not expensive.

I'm afraid it is not only expensive, but I can't even think of a way of accomplishing it.

With the current design, it's the threading itself that makes the error detectable.

GML also uses wrappers for all OpenGL calls, which adds an extra layer - causing overhead.
I don't think we want that in the single threaded build.

I asked Auswaschbar to put this build on the download page. To improve it further it must get into mainstream use so that the bug reports keep coming in. I'm afraid not many regular Spring players make their way into this development forum.

[xyz]

Hi

I asked Auswaschbar to put this build on the download page. To improve it further it must get into mainstream use so that the bug reports keep coming in. I'm afraid not many regular Spring players make their way into this development forum.

If it is possible to fix LuaUI, that will make the build a lot more fun to test. Right now i stopped using it as the game without Lua is a bit annoying.

Thanks

[zerver]

If it is possible to fix LuaUI, that will make the build a lot more fun to test.

That's the goal. It's complicated so don't expect it anytime soon though.

U see, I'm an old-school TA player so I'm rather happy with the non-LUA GUI because if offers pretty much everything original TA did

Just out of curiosity, which widget is most important to you?

[AF]

Why cant we just take calls outside the rendring thread, wrap them up, and schedule them to be called later on? Sort of like using th render thread like a worker thread after the calls are made, and throwing errors when this compatibility layer is used?

For example, in java swing, all renderings done on the EDT thread, and when in another thread, you take the GUI code and put it in a runnable object and add it to the queue, so if we have ti so that when a widget or gadget is entered the gl calls are logged and then fed into the render thread where it gets repeatedly executed at the end of every frame or stage until the next sim frame begins.


That or we can take this fatal bug in numerous widgets for what it really is, a fatal bug in numerous widgets caused by improper coding which was ignored and is now reaping whats been sowed.

I would suggest another solution is to ignore the calls outside the rendering thread but then for all I know this is whats currently being done.

[Argh]

What's causing this error, exactly? Calls to OpenGL outside rendering passes?

Certain things must be done before the renderer is active, or during the game but before the drawing would be performed, such as setting up display lists. That's unavoidable, imo.

And zerver... no offense meant, and I certainly do appreciate what you're doing here... but if you think that LuaUI is a non-important and trivial thing, not worth prioritizing... you're so, so wrong. LuaUI is used to generate a lot of the UI behaviors in most games now. It's pretty vital that it operates correctly, tbh, otherwise gameplay may not be correct.

I can't put it any more plainly than that- if you think that the game designers and players use Spring's default UI on a regular basis, and that nobody will raise a fuss if you release a multithread version that "just" doesn't support that feature... you're going to have a rather big shock if you release it to a broad audience

[Pressure Line]

not to mention that disabling luaui can interfere with game specific (and important) ui elements as argh already pointed out, and depending on the game could be quite severe (for instance I dont use teamcolour, thats done in lua)

obviously if all you play is *A on DSD, you probably arent going to notice (apart from LUPS (BA) failing to work). but a CA or PURE player will find themselves crippled when half of the UI doesnt work, leaving them unable to access many of the games features.

obviously, in a pure test environment (just to see if multithreading is implimentable) that doesnt matter. but knocking out luaui (which afaik kills all widgets!) is not really an option for a *real* releasable build.

[xyz]

Hi

No offence but is there anyone here reading before posting?
zerver doesn't want to take out LuaUI:

xyz wrote:If it is possible to fix LuaUI, that will make the build a lot more fun to test.
That's the goal. It's complicated so don't expect it anytime soon though.

Just out of curiosity, which widget is most important to you?

I do miss Immobile builders, got so used to it that now when i am using MT i usually forget to give them work.

[zerver]

I got it... so LuaUI is more than just GUI enhancements.

I will check if it works with LuaUI on, but all widgets disabled.
If it does, then I don't see why we could not release this one.

It's like saying "we will not release the new spring version because CA has a bug".
One buggy widget is not a big issue imo. The widgets and mods are not part of the engine.