Spring is running in SMP

[Argh]

Um, on my old, slow Athlon 2800+, with a GeForce 7800 GT, I see CPU as the main bottleneck, tbh. I see significant framerate choke being caused by sim calculations.

My GPU is rarely topped out, at least with P.U.R.E.

Instead, it's stuff like CEG particles being drawn, and certain very CPU-heavy operations (the FALL event being the worst, by a long measure) that drag everything down, in my experience. I've had to eliminate the use of FALL entirely, in P.U.R.E., and cut down the life of various particles in my CEGs, to get performance to the targets I wanted.

The only place where I see GPU being a major issue is in Features, or anything else that is drawn irrespective of LOS. If it weren't for borked AI handling of Gaia Units (most AIs attack them, because they aren't Allies, which is lame, since Gaia is clearly defined by Team Number) I'd replace all Features with a specific type of "unit", however I'm going to have to solve this another way.

At any rate... if GPU's really an issue, LordMatt, it has to be mod-specific stuff that's not being done efficiently. Mods that aren't using S3O, for example, are drawing twice as many triangles as they should be. Mods that make heavy use of LUA visuals without a great deal of optimization are not going to run efficiently, either. And any mods that use CEGs that are poorly designed can choke both the GPU and CPU.

Optimization on the GPU side is quite possible, imo, but involves the much-debated cleanup of the .S3O rendering code. Trepan / jK's work on LuaMaterials looks like a good workaround- simply stop drawing the Unit through Spring's native code, and start drawing it through LuaMaterials instead, making use of GLSL and other hardware acceleration methods, with the old rendering as a fallback for users whose hardware cannot run GLSL code. That's what I'd like to do, I just have yet to see any example code from those two (yet) to give me a starting-place and investigate how much speed benefit we can really expect to see, for anybody running on modern hardware. The CPU-grinding stuff is mainly stuff that's slow because it's feature-rich, not necessarily because it's poorly optimized.

FALL is the big exception- it should have been made accessible to several TDF tags to govern gravity, detection-sphere size, and other factors that are currently being calculated on a per-frame basis awhile ago, but it's always been on the list of "fix the major stuff first" changes.

[LordMatt]

Also, LordMatt, you are contradicting yourself. First you say that you think spring hardly ever maxes out a single core (which it does), and then you say you don't want threading because you don't want it to max out multiple cores (which it won't on your quad core)

I am, of course, referring to the fact that spring utilizes 100% of a single core when viewed from the system task manager, regardless of what it is actually using in game (i.e. what is reported in the user info section).

Um, on my old, slow Athlon 2800+, with a GeForce 7800 GT, I see CPU as the main bottleneck, tbh.

And you will be benefited by smp threading optimizations exactly how?

My mod is better than BA (at not stressing the system)

I wish BA had all of those optimizations that you mention, but someone would have to volunteer to do all of that work, and it hasn't happened so far.

[AF]

Currently gpu blocks the simulation and vice versa. Moving rendering into a multi threaded setup can only mean greater frame rates.

Argh, nobody likes a show off, saying your mod is better than another at doing something is either provoking someone or being arrogant.

[zerver]

One of the problems is that when the engine is running at high load (a big maxplayer game), the Sim takes so much time that there is too little left to do the rendering. Sim has priority, so the framerate drops quite a lot.

It is difficult to multithread OpenGL. The method I'm using right now is a special library that I wrote that redefines all OpenGL calls and redirects them to a producer/consumer system. The producers are the worker threads and the consumer makes the actual calls into GL.

I don't expect any big gains from using this on the rendering, right now I see about 15% higher FPS.

However, it paves way for other interesting things:
The Sim also makes some GL calls, and it can now be multithreaded.
If there was a duplicate game state, the rendering could run entirely in parallel with the Sim. This would mean enormous performance gains.

There are possibly other ways to get better OpenGL performance, such as splitting the view into multiple parts and rendering one on each core. I'm not very experienced with OpenGL, so I cant really say whether normal GPU like to draw to multiple buffers simultaneously. There could be quite an overhead.

[Vadi]

Well I think ANYONE with a dual core is not CPU limited atm, so my point stands.

I disagree. Have you talked to many other people on dualcores? Have numbers?

I'm on a 1.5ghz CPU, letting Spring run at 3ghz instead of 1.5ghz would be a huge improvement or me. (I do have a geforce 8600, 512ram - wasn't quite thinking clear that I'd need a matching cpu though. Spring is the first game I've ran into that limitation with)

[AF]

Lordmatt if someone can max out your core they will. Just because this gives no observable gains to you in theory does not mean an optimization should be disregarded.

On the other hand Ive had cpu max out on dual cores myself, and its happened on various intel cpus, even a core 2 duo.

[LordMatt]

Are you dipping below 30 FPS with your CPU% in game well in excess of 50% and playing at normal game speed? I'm not against optimizations, but I am against the whole ZOMG DUAL CORE SPRING WILL BE 2X FAST LOL mentality, particularly when everyone would benefit from GPU optimizations, if they can be had.

[Argh]

One of the problems is that when the engine is running at high load (a big maxplayer game), the Sim takes so much time that there is too little left to do the rendering. Sim has priority, so the framerate drops quite a lot.

I see this problem when "merely" running 3 AIs and a player during playtesting of my game. Eventually, with lots of Units, the load gets quite large, and even with the optimizations I'm putting into place, I see framerate drop to around 20 FPS when the huge, final confrontations take place in late game.

I keep mentioning FALL (see CCobInstance::Explode), though, because it's one of several specific areas in Spring's code where it chokes up a CPU with a very small number of events happening, because the code is so inefficient. I see CPU spikes of up to 5% per FALL event, because it's doing so many complex calculations per-frame. As OTA mods use a lot of FALL events, that's one of the areas where they could address their CPU-hungry nature (that, and the small minority of their scripts that are very poorly optimized, but meh, that's a whole 'nother story).

And you will be benefited by smp threading optimizations exactly how?

Well, I wouldn't see any real benefit, but I see no reason to get upset by it, either, assuming it doesn't perform any worse than it does now, and if this zerver's area he wants to try, all power to him.

The hard part, that zerver's going to run into fairly quickly and has already mentioned, is that there are a lot of areas of Spring where GPU and CPU-side stuff is intertwined. Getting them all separated was the thought behind putting a new rendering pipeline in effect, so I was led to believe, but I haven't seen any sign of progress on this since the initial hoopla about what core rendering engine to use. I'd rather see somebody take a serious whack at separating them first, then having a proper debate about where to go with rendering, before proceeding with the rest of this- personally, I think that to do otherwise is putting the cart before the horse. But meh, that's just me.

[LordMatt]

Why is fall so expensive? Is that something that Jonanin could improve with their math optimizations?

[Argh]

No, imo, although that might speed things up a bit. The big area of suck is in PieceProjectile.cpp, which, among other things, has a raw OpenGL call in it, instead of invoking a separate CEG, and calculates its collision volume every frame, instead of just once. Lol, I just saw that #include "ProjectileHandler.h" is listed twice... I wonder if it's executing twice... OMG, that might be why I saw the errors with explosions earlier...

[Vadi]

Are you dipping below 30 FPS with your CPU% in game well in excess of 50% and playing at normal game speed? I'm not against optimizations, but I am against the whole ZOMG DUAL CORE SPRING WILL BE 2X FAST LOL mentality, particularly when everyone would benefit from GPU optimizations, if they can be had.

Yes, yes I am. Spring never goes above 50% for me - it can't for the most part, it just uses both cpu's at their half-power. Threading = more than 50% of both cpu's being able to use.

I understand your point, but it's invalid - threading will do good things.

And my game does dip below 30fps with lots of units are about. But I even had to disable shadows for it to be stable at 30 - with threading, spring could use more of my resources, and I could get shadows back on.

[FLOZi]

You didn't address the part where I said it isn't even maxing out one core, ever (on two different CPUs spanning 4 years of CPU technology). Additionally I have to use the FPS widget to turn off graphical options as the game progresses so that spring does not completely run the GPU into the ground, and so that the FPS remains ~30 (above which you will not notice much difference). This, of course, has no effect on CPU usage which never nears max. Making spring run on multiple cores will not increase your FPS or the smoothness of your gameplay if you are GPU limited.

Now it may be that my CPU never maxes out because I never have the slowest CPU ingame, and thus my CPU is never taxed as much as another player's, however making spring multi-threaded will not address this issue either, as one person having old hardware will make the game slow for everyone, regardless if they have fast multi-core CPUs or not.

Thus it would make more sense for devs to optimize GPU processing.

Play a better mod.

[LordMatt]

Yes, yes I am. Spring never goes above 50% for me - it can't for the most part, it just uses both cpu's at their half-power. Threading = more than 50% of both cpu's being able to use.

AND no difference in your game playing experience, since you are not CPU limited anyway.

And my game does dip below 30fps with lots of units are about. But I even had to disable shadows for it to be stable at 30 - with threading, spring could use more of my resources, and I could get shadows back on.

Like I said, I would love for someone to spend some time optimizing the GPU functions so that you and I didn't have that problem. Stop thinking that threading is some magic panacea that solve all your FPS problems.

[Vadi]

Go ahead, optimize the GPU.

[Argh]

Er, at the risk of causing offense, LordMatt, he's not saying it's a magic panacea, merely that it's one of the issues involved.

And I have to agree with FLOZi- if the GPU is the bottleneck (which, in BA at least, is not the actual case, in my tests, it's really CPU spikes- when you see 50% on a dual-core, LordMatt, I think you're really seeing 100% CPU use of the single core involved, but I could be wrong) then there must be some royally slow drawing code being executed, and it should be fairly easy to profile it and eliminate it.

[Snipawolf]

Why not just let this fellow multi-thread what he wants and someone else come along and multi-thread what they want? Seriously, why whine when HE is the one doing work?

[LordMatt]

And I have to agree with FLOZi- if the GPU is the bottleneck (which, in BA at least, is not the actual case, in my tests, it's really CPU spikes- when you see 50% on a dual-core, LordMatt, I think you're really seeing 100% CPU use of the single core involved, but I could be wrong) then there must be some royally slow drawing code being executed, and it should be fairly easy to profile it and eliminate it.

Nope you're wrong. I can easily get my CPU % over 50 if I jack the gamespeed up to an insane level. btw, just played a 3 vs 8 game on xantheterra: I was at ~15% in the late game and didn't see anyone over 40% in the player info. If it's "fairly easy" to eliminate the GPU slowness, someone please look into it, instead of everyone saying how getting spring to run on dual cores is going to make some massive improvement.

[aegis]

Maybe your CPU speed never goes over so many percent per core no matter what you do with Spring.... because it's switching a thread between cores...
So, it will get 1/(number of cores) CPU percentage used per core in task manager... not because it is waiting for the GPU...?

I believe the percentage in player info is the amount of CPU required to execute sim code at full speed, not the actual percentage of CPU used... Spring always maxes out a core <_<

[LordMatt]

Why not just let this fellow multi-thread what he wants and someone else come along and multi-thread what they want? Seriously, why whine when HE is the one doing work?

He's welcome to do whatever he wants. You might note that only two people in this thread have said that the gains to be had by multithreading aren't very significant.

[Peet]

Do not, ever, EVER use the % that spring reports ingame as an indicator of anything at all except for comparisons relative to other people in that same game. Other than that, it is essentially meaningless. It has nothing to do with the amount of cpu time Spring uses.