Spring is running in SMP

[LordMatt]

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, not because it is waiting for the GPU...?

Also, i think the percentage in player info is the amount of CPU required to execute sim code at full speed or something, not the actual percentage of CPU used... spring always maxes out a core <_<

I can make it go up to 100% if I put it in a situation one would never encounter in game (many planes, high game speed), and it still uses the same amount of CPU in the task manager...

[LordMatt]

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.

Oh? so what is it reporting then?

[Peet]

I'm not entirely certain; it involves a ratio between cpu usage of the sim and a few other things. It can go above 100%.

[aegis]

Also, I believe the percentage in player info is the amount of CPU required to execute sim code at full speed

I can make it go up to 100% if I put it in a situation one would never encounter in game (many planes, high game speed), and it still uses the same amount of CPU in the task manager...

Spring always maxes out a core <_<

Doesn't Spring just use all of the remaining for rendering?

I'm not entirely certain; it involves a ratio between cpu usage of the sim and a few other things. It can go above 100%.

Notice the game gets slower when it goes over 100%? Maybe it's taking someone longer to execute synced code...

[Peet]

It slows down around 50. And I know it's more complex than sim:rendering.

[Argh]

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.

"Fairly easy" != fast. Optimization involves a lot of low-level grunt work. I am not willing to even do the detective work, sorry, I don't play BA, and CA's developers are quite capable of doing their own optimization studies.

However, you can figure out a lot of this yourself. Fix it, no, not unless you're an experienced modder who knows a lot about animation and CEGs, but you can at least get a better handle on where framerate is being impacted, on your rig, and get a better idea how multithreaded stuff might help you.

First question to ask is, "what's your framerate, with 500 CORKROG on screen".

Mine's 12FPS, with a fairly recent CA build, no tweaks to Widgets or anything, shadows off, on a voidwater map. Drops to 7 with shadows on, at 4096 resolution- Spring's implementation of shadows is slow, but it has to be, according to every discussion we've had about this topic.

If you're not getting at least 12 FPS (I'd say you should see at least 20, with your rig), then you may want to tweak with nHancer to optimize your GPU's setup for Spring.

After that, with nothing moving, it's down to Widgets, then down to stuff that causes CPU spikes, that can have a huge impact on your FPS, and does not always show up on the basic CPU meter (but can be seen on the graph).

Clean out your Widgets folder, so that you're only using the stuff that comes with the mod, then .give yourself the max of a Unit... point your camera away from them, so that they're all being culled, and then kill the Widgets, one by one, to see if any of them causing GPU slowdowns. My guess, tbh, is that you're going to find that none of the Widgets results in a massive change, although that depends on the Unit- I'd suggest .giving a mobile Builder, as they get effected by certain Widgets that must run fairly slow code. However, they're only slow on the CPU side.

Lastly... watch what happens when you take even a few Ravens (say, 20) and fire them at the ground, which is a CPU-heavy event.

I suspect you'll find that it's very interesting. Use the "b" key (default key to see Debug / Dev view) and watch the graph spikes, to get a much better understanding of what's actually happening, btw. The default CPU / FPS counters are OK, but are a very, very rough approximation.

[lurker]

I believe the cpu percent is very simple, and makes perfect sense when it goes over 100%. It's the percent needed to run the sim at current game speed. When it goes over 100, it basically means that there are frames taking too long to calculate, and it would be impossible to run at the current game speed, so the actual flow kind of skips and stutters.

[Argh]

Yeah, I'm pretty sure anything over 100% means that it didn't finish all tasks faster than the core framerate of the sim, or 32FPS, and has desynced for that frame. If it happens during one of the very slow update cycles being sent to the network, I suspect it leads to desync right there.

The other thing to look at, irrespective of what that part says, is short but violent spikes on the CPU graph for a particular element.

Ideally, even during peak levels of activity, one should see only minor changes in the flow. IRL, it never works that way, because you always have dips and lulls, and certain frames (SlowUpdates) are always packed with activity that can pile up, when other things are happening. But a spike "through the roof" (off the chart's top end) shows you that something is really, really, really borked.

Ideally, I think that all Lua scripts would avoid SlowUpdate frames like the plague. I've been experimenting with that, and it really seems to help out with CPU loading...

[KDR_11k]

I believe the cpu percent is very simple, and makes perfect sense when it goes over 100%. It's the percent needed to run the sim at current game speed. When it goes over 100, it basically means that there are frames taking too long to calculate, and it would be impossible to run at the current game speed, so the actual flow kind of skips and stutters.

I doubt that, my framerate goes to hell way below 100% and I have only one core. I think not all code is profiled.

[Kloot]

Just to end this needless speculation tangent, the CPU
percentages are based on the profiled performance of
the synced portion of each client's simulation frame:

Code: Select all

if (gu->gameTime - lastCpuUsageTime >= 1) {
	// time to send a CPU usage update for this client
	lastCpuUsageTime = gu->gameTime;
	net->SendCPUUsage(profiler.profile["Sim time"].percent);
}

Which includes these and only these calls:

Code: Select all

// start the clock
ScopedTimer forced("Sim time");

helper->Update();
mapDamage->Update();
pathManager->Update();
uh->Update();
ph->CheckUnitCol();
ground->CheckCol(ph);
ph->Update();
featureHandler->Update();
GCobEngine.Tick(33);
wind.Update();
loshandler->Update();
if (!(gs->frameNum & 31)) {
	for (int a = 0; a < gs->activeTeams; ++a) {
		gs->Team(a)->SlowUpdate();
	}
}
// timer goes out of scope, stop the clock and add the
// time difference to the TimeRecord named "Sim time"
// maintained by the overall profiler

The "percent" part actually sent over the net is nothing
more than the ratio x/y, where x is the sum of all sframe
timings over the profiler's own update interval and y the
length of the interval itself (500ms). Percentages of >=
80% therefore leave very little CPU time to any unsynced
operations (rendering), and any values greater than 100
imply missed sframes (aka. "delayed response" warnings)
where no rendering is done at all.

(Since there are 30 sim-frames per wallclock-time second
at normal 1.0 game speed [or 15 every half-second] each
individual sframe has only ~33 milliseconds at its disposal
at best, so if the cumulative sframe time over the profiler's
update interval exceeds 500ms the simulation will then be
running slower than its internal update rate. The % figures
are just indicators of how close a client is to not being able
to keep up with the set game speed).

[zerver]

I'm not entirely certain; it involves a ratio between cpu usage of the sim and a few other things. It can go above 100%.

It certainly can. I have seen >1000% (for all players) on shore2shore

1000% could mean that it renders one graphics frame every 10 simulation frames. In other words, the CPU is having a very hard time to keep up the pace.

[AF]

Thats because the meaning of that value has changed in the last 6 months so what you remember may have been correct but what it meant at the time doesnt match because you may be remembering it from before it changed.

[NOiZE]

so what stuff in BA is highly inefficietn GPU wise then?

[rattle]

The 11 year old models! The only inefficient thing I can think of may be huge textures for tiny particle effects but that is all.

Wasn't this thread about multi-threading?

[[Krogoth86]]

@LordMatt:
I really don't know how you come to the conclusion that Spring is GPU limited. Especially with things like particles etc. still being calculated on the CPU you very fast run out of processing power - especially if you don't own a more or less recent CPU (like Athlon XP for example). Also why do you think you get 0.5 and less gamespeed in multiplayer games although everyone still has fine framerates? As you talk of your GPU being the limiter I suppose you have shadows and dynamic water activated what you shouldn't because they both are performance killers and especially the (afaik uncached) stencil shadows aren't something you should use in an RTS (heck even in shooters stencils were used only for special models like enemies or something because of their low speed - for an RTS with hundreds of units it's just overkill). So with those things deactivated I have no idea how you bring your 8800er cards to crawl...

There now also is LUPS but afaik this also is just a new management system for particles which still use a CPU calculation...

[jK]

There now also is LUPS but afaik this also is just a new management system for particles which still use a CPU calculation...

LUPS is highly GPU accelerated, that's why it doesn't work on all PCs.

[[Krogoth86]]

LUPS is highly GPU accelerated, that's why it doesn't work on all PCs.

Ah ok - some time ago I was told that LUPS also wouldn't be a solution as it also was CPU only. Good to hear that...

[Argh]

so what stuff in BA is highly inefficietn GPU wise then?

Well, first off, you have all of the OpenGL operations involved in SHATTER events. It's fast, per tri, but it's having to grab from the giant 2048 texture o' doom used for 3DOs, for every triangle, instead of for a quad, which makes it really a lot more expensive.

Go through the scripts, and cut the use of SHATTER out of the death animations, and use a CEG instead. It'll be prettier, and faster, too.

Then you have whatever CEGs are heavy on particle-count. One at a time, they don't matter a lot, but it adds up- remember, particles are also a pair of triangles on the screen, so 1000 particles is 2000 triangles.

Texture fillrate also comes into play, here- last time I looked (admittedly, awhile ago) BA had a number of commonly-used explosion textures that were 256/256... fricking HUGE. I have gotten just about all of the explosion textures in P.U.R.E. down to 64/64, and they still look just fine, given that you can make 'em large then shrink 'em down, then adjust alpha to cover any rough spots. Shrink them as much as you can.

Then you've got whatever Widgets are being used, and the fact that BA is using 3DOs, some of which are higher polycount than a typical unit in P.U.R.E., because of double-sided rendering of quads in Spring.

Your main killers are CPU-related, though. Just eliminating all but the most important uses of FALL, for example, could make that game run a lot more smoothly.

[AF]

The giant texture is already in the gpu it isn't sent every time you transfer a triangle which is really just 9 GLfloat values for the co-ordinates, and 6 GLfloats for the UV-coords. You may add another 9 for normals and so on. perhaps not even that if your using more modern methods such as display lists or buffer objects.

[zerver]

I have moved the Sim to a separate thread. Because the Sim makes so few GL calls, the consumer thread in my producer/consumer system is mostly idling.

In other words, there is plenty of CPU time available to do some useful work there. So, I'm trying to identify parts of the Sim that are independent and can be reordered/run in parallel without affecting the end result. It is tedious work, so suggestions are welcome.

If it turns out to be a dead end, my secondary option is to try to run certain parts of the rendering in parallel with the Sim. Can anyone tell me what types of OpenGL processing takes place during the Sim? I've seen that LoadUnit creates display lists and such, but I'm pretty sure there is more to it.