I'm a grad student at RIT in the game design program, and I'm currently in an "emerging themes" class. At the moment, we're discussing multithreaded/multicored design in games.

Since Supreme Commander is currently fairly well known as taking advantage of multiple cores, I was wondering if a developer could give a moderately detailed description of how Supreme Commander uses threads? Of particular interest would be how the threads are organized, when and how they're synchronized, if there's anything unusual about the way they're used, what kind of difficulties you ran into, etc.

I know I would appreciate the information, and I expect my fellow students would as well.

Players who are considering upgrading their rigs would also be very interested to know exactly what sort of benefit might be found in going to quad-core.

There is also curiosity as to whether GPG will release future patches to increase the thread handling by multi-cores to further improve performance when using quad-core over dual-core.

From what I understand, 1 thread will be for rendering, and another thread for everything else.

I would expect to see very little gain between quad cores and duel cores unless they change their technology. About the only benefit you will get is that the OS and other stuff will be on a third CPU instead of sharing one of the other two threaded ones.

If you do a forum search you can already find some info on how it works.

There are two primary threads:
- The simulation, which contains AI and all the unit racking code, this thread runs nearly at 100% all the time
- The UI / rendering thread this takes care of all the visuals
- Then there are extra helper threads that do not depend on order or time as much.

A Dual core system should see one core at 100% and the other very high.
A quad core system will se one core at 100% one very high and 2 in much lower use.

As anyone who as done coding will know, some jobs can not be divided as they need to be done in sequence and in sync.

Yeah, I've seen those posts before. I was hoping for a bit more detail. More information about how and why their design and implementation works, that sort of thing. I know the devs may not really be able to talk about it, but I figured I'd ask.

Pathfinding also has it's own thread (as far as I know)..

So.. one thread for the game logic, like simulations...
A render thread...
input thread for captureing mouse and keyboard events...
pathfinding thread...


The simulation thread is not the thread which will run at max... instead, the simulation thread will run at a variable speed, depending on how many units there are and how high the speed is set...

also.. the render thread will run at MAX speed, if the rendering is not limited, for instance, by V-Sync.


these are just theories however...

Do you have a paper to write and you're looking for a little "help"?

Neither. It's for discussion later today about multithreaded/multicore game implementations, both how people have already done it and how we (the students) might do it in the future, and the difficulties, and such.

If anything, you shouldn't be looking at Supreme Commander then. It's threading implementation is basically the rendering thread on 1 core, everything else on the other, which skirts the interesting issues of state sync, since those tasks are entirely seperate. It's basically the logical "first step" of multithreading.

For really cutting edge multithreading work though, check out the new Edge engine framework for PS3(Cell), they are actually threading across SPUs at a fine grain for skinning, morphs, blends, rendering, animation, object-level culling, transformations, tec.

Rendering should actually be the core that is always at 100%, so you get as much power out of your graphics card as you can.

It has been stated by a dev in another thread that that is the case. Render gets 100% on one core, everything else runs on the second core at around 80% utilization. If you have more than two cores, things get split up more with progressively diminishing returns.

It is my understanding, from other threads, that if you have more than 2 cores, windows will schedule non-SC tasks such as non-graphics (nonblocking) driver activity, os activity, paging, etc. to the 3rd and 4th cores, leaving 2 whole cores to SC, however SC itself does not take advantage of more than 2 cores explicitly.

All I know is that in Supcom at least, the quad core out-performs the dual core: http://uk.gamespot.com/features/6166198/p-6.html

The sad thing is right now the quad is about $1,000.

AFAIK SupCom scales to any number of processors you may have. Heck, if you have 32 CPUs, it can scale to 32 CPUs. Unfortunately, I think the Rendering Part is confined to one thread/core, simply because stuff like that doesn't work well multi-threaded.


I think Supcom's Lua implementation has their own lightweight Threads/Fibers and the engine only spawns one "major" thread per core, and all the load balancing is done by that lightweight implementation. Of course there are other threads, too.

You should check one of the ren_Show* console commands (can't remember the name and I don't have the game at hand to fire it up).

There is one that displays a graph of how the engine schedules tasks throughout the game. You can see that there are multiple threads and when they are running etc.

Perhaps you should PM squidbot - he seems to know a bit about the threading design... he was looking into performance issues with dual cores a while back.

Hmm, that sounds like it might be interesting....



Thanks, I might do just that.

There is a one small problem here, it would most likely immediately desync in multiplayer games. The simulation has to execute exactly same code in exactly same order to guarantee same results. While it would be possible to track all the dependencies between lua threads it also would be extremely difficult and probably nullify all the gain from using more physical threads.

One interesting thing I saw in the a previous post was that the AI is contained in the main simulation. I wonder why they couldn't have made the AI an external entity like the player, acting on its own and sending back commands.

Not true.

Tasks in games are handled in discrete slices of time. The size of the slices (or ticks) is usually either based on the framerate the game is running at, or is some fixed length. In the case of Supreme Commander, I believe the length of a tick is either 1/10th or 1/30th of a second for the simulation. That's if you're running at +0 speed, anyway. At higher or lower speeds, the ticks are processed faster or slower, but the math is done as if the length is the same (either 1/10th of a second, or 1/30th of a second).

At the same time, in a game you generally want the results of any simulation that occurs in a tick to be the same regardless of what order you process the simulated entities. From a game logic perspective, everything that happens in a tick happens at the exact same time.

Because of these two facts, and because the simulation in multiplayer SupCom always runs at the speed of the slowest player, it is perfectly feasable to different execution orders on different machines. As long as you only check for sychronization between ticks, you're fine.

In fact, it must be possible to do things this way. Otherwise, you'll have desyncs when people with different operating systems play together, since the OSes are liable to schedule the threads differently.

my guess is because AI is still simply calculations done based on data in the game, not actually a self-aware, rational program that can run on its own and interact with the game like a player

Consider this:
There is a shield up with 50hp left and 2 projectiles in air going for a unit under the shield. A projectile deals 60 damage, B projectile 100 damage. Both projectiles hit the shield in the same tick. 3 things can happen:
1) A projectile code is executed first, the shield is damaged for 60 and goes down, B projectile will not hit the shield and after some time will hit the unit for 100 damage
2) B projectile code is executed first, the shield is damaged for 100 and goes down, A projectil will not hit the shield and after some time will hit the unit for 60 damage
3) Changes done by projectile A and B are invisible in the current tick to avoid desync and the shield will go down in next tick. Both projectiles hit the shield and are stopped by it which is obviously wrong.

Do you now see why maintaining strict order in dependent code is required ?

Answer to the post below: Im getting annoyed by you claiming that 2+2=5 so Ill let you live in your own world and let other (smarter) people decide what is correct.

Thwut?
One projectile *will* hit before the other. If they hit in the same .1 second span, the order is irrelevant. The shield goes down and 110 (in 2 projectiles either way) continue past the shield radius. Either way, order that damage is dealt is irrelevant.

Because its a sim, things like that can happen.

Actually, Im not sure how the game deals with damage from projectiles that drop a shield.

I would actually argue that 3 is the correct way to design the simulation. Technically, it eliminates the within-tick dependency.

Logically, within the frame of reference of the simulation, the two projectiles hit at the exact same moment, so there's no meaningful way to say which one affects the shield and which one penetrates.

It even makes sense if you use a real-world analogy: If two missiles were to hit at pane of glass at the exact same moment, they would both detonate. Neither would penetrat to whatever is on the other side.



What?

What about 2 engineers capturing the same unit in same tick ? Which player will get the unit ?