multithreaded game engines

Advice: Don't do it. =)
No but seriously think hard before you want to venture down this path. It's not the magic bullet some people might think it is. It's a world full of hurt and strange bugs if done just slightly wrong.

But if your prepared then carry on.
For starters if you have a engine already I suggest multithread on a function basis. This is the safest way to utilize multithreading. It works like this.
Profile your game. Say you find that the path finding algorithm is taking the most cpu time. Then in that function let multiple threads (One for each core) help in doing the pathfinding. When you exit the function your threads should be done with thier work. This way you contain the threading to a single place and can also much more easiy make sure you dont access things in other threads that you shouldn't.

Another way to do it is to split up the work into physics/collision/render threads. The problem is the data access between the threads. It can kill your performance when syncing up the threads if done wrong. You can also easily fall into the trap where you think "But in my physics i just need to access that little collision object" and you forget it's on another thread. 2 months later you engine starts crashing randomly for no apparent reason. With a stack trace that doesn't help you at all.

Put simply. If it's you first engine. Don't care about threads. When you now how to build a fast single threaded engine then you can jump into the joys of multithreading.

Also make sure you run on a multicore cpu when you actually build your engine (Not just hyperthreaded). That way you engine will start crashing faster if you have done something wrong.

Thanks for you reply.

It wouldn't be my first engine. I'm more interested in the second way you mentioned, namely paralellizing rendering/physics/ai.
I'm aware of that it's quite complex topic, that's why I asked for pointers :]

Having a multicore system is a must, without that I would definitely run headfirst into the wall :D

Nothing special about multi threaded game engines but Andrei Alexandrescu and Herb Sutter have got a lot of interesting articles about mutithreaded software, and also try to provide some alternatives for lock based data structures, which imo should be considred an antipattern...

t0}{!c

The way I'm doing it is simply making sure that each property that is shared, is used exclusivly by that thread at any given time.

I.e

A want a path.A.WantPath = true;Path thread calculates path for A.

suppose that A's update wants to check the path object for A, it first checks if WantPath == true. if so, it ignores touching the path this update.

Same goes for loading/rendering:

if (A.Loaded) Render();

This works really great... maybe too great, since I'm probably using more threads than I should. ;)

But I really prefer having a smooth gameplay and letting an object fade into view (for example) than having an annoying stutter or "Loading" while loading that object/map/whatever!

Hmm, sounds interesting, Rasmadrak ;)
Which subsystems/tasks do you have a separate thread for?
Do you have any threads that takes care of multiple tasks?

Quote:

Original post by Xetick Another way to do it is to split up the work into physics/collision/render threads. The problem is the data access between the threads. It can kill your performance when syncing up the threads if done wrong. You can also easily fall into the trap where you think "But in my physics i just need to access that little collision object" and you forget it's on another thread. 2 months later you engine starts crashing randomly for no apparent reason. With a stack trace that doesn't help you at all.

That model of threading really only tends to work well in Apps, For a game it typically works better to keep a linear process (ie, collisions -> physics -> Ai -> rendering) and make each of those units utilize threads to their maximum ability.

Normally you would create a pool of worker threads at game startup (rather than spawning & deleting them during the update cycle), and assign different work units to each thread.

Whole mirade of articles coming out on multithreading engine design due to the introduction of multiple cores on PC and consoles.

One example:
http://msdn.microsoft.com/library/en-us/directx9_c/coding_for_multiple_cores.asp?frame=true

At this years GDC there are quite a few articles might want to do a bit of a search since consoles like xbox360 and ps3 all have multiple cores.

The idea presented presented in the MSDN articles (1 input/update + 1 render + some worker threads) seems to be simple enough and sounds quite okay for me.

I've read in a presentation that the Unreal team are doing it this way:
"How we cope in Unreal Engine 3:
- 1 main thread responsible for doing all work we can’t hope to safely multithread
- 1 heavyweight rendering thread
- A pool of 4-6 helper threads. Dynamically allocate them to simple tasks.
- Program Very Carefully!"
Source: http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt

I like the last one the most :))))

My threads are as following:

- Update/Rendering (will be separated later, using a renderqueue)
- Input
- Loading stuff
- Pathfinding
- Sound

Basically I have a queue for the loading and pathfinding threads, and they just sit idle until something is put into their queues.

Input is running all the time to keep mouse updates and keyboard input smooth at all framerates.

What could be implemented is a forceload and a priorityqueue, for instance:
My pathfinding system priorities objects that are inside the frustum - this fools the user into thinking the game is much more responsive than it is.

If forceload is activated: A loading screen is shown and the game is "paused" while loading occurs. This ensure that that object is loaded entirely before continuing - useful for loading stuff as the initial terrain surrounding the camera while starting a new level or teleporting etc.

Priority: well... Obviously we don't want our input thread (etc) to use 100% of the cpu, so I keep it slightly less prioritized than the rendering.

I also have a global variable "Done" that lies inside all threads, which closes the thread if true. This is called on the application exit, and the main thread waits until all threads are closed before quiting.

/Robert