Multi-core/Multithreading your engine...

[AthenaOfDelphi]

Multi-core vs. Multi-threaded are distinctly different and require more thought and careful synchronisation/resource protection.

The reason... concurrency, and here's why...

Single Core

Thread 1 XXXX----XXX--------XX
Thread 2 ----XXXX---XXXXXXXX--

Using my really great artwork, what we have above is a simple diagram to illustrate the scheduling of two threads in your app on a single core machine.

As you can see, processing switches between the threads, meaning that at times they will not be executing.

Multi Core

Thread 1 XXXXXXXXXXXXXXXXXXXXXXX
Thread 2 XXXXXXXXXXXXXXXXXXXXXXX

This diagram shows the scheduling of the same two threads, but this time running on a dual core machine. As you can see, both threads are being executed at the same time because thread 1 is on core 1 and thread 2 is on core 2.

Whilst the essence of protecting for multi-core is similar to protecting for multi-threaded, you have to be more mindful of such wonders as deadlock and other timing induced weirdness such as AV's on variables you know you've initialised.

If anyone is new to multithreading and wants some pointers, I did write an article (Multi-threading Part 1 ) about the basics of multi-threading.

[savage]

I just stumbled on this game programming course....
http://users.ece.gatech.edu/~lanterma/mpg/

The great thing is that is has a lot of video material that may be usefull or give others ideas. The multi-core stuff is towards the bottom.

[savage]

I quite like the following separation

 --------------------------------------
| Core   | Thread    | Game Process    |
 --------------------------------------
|   0    |      0    | Game Update     |
|        |      1    | I/0             |
 --------------------------------------
|   1    |      0    | Game Rendering  |
|        |      1    |                 |
 --------------------------------------
|   2    |      0    | Audio           |
|        |      1    |                 |
 --------------------------------------

The idea being that there would be 2 back buffers BB0 and BB1.
1 . Game Update thread would write to BB0.
2. Once complete, the Game Rendering thread would read BB0 and output to the screen
3. While 2 is going on, The Game Update would start writing to BB1

So therefore GU ( Game Update ) is only ever writing to the one of the back buffers, while GR ( Game Rendering ) is only ever reading from one of the back buffers. This then alleviates any read write conflicts.

Obviously GU should be analysed further to see if there is any scope for more parralelism in terms of collision detection, physics or AI that could split up.

Now how to actually get this working and cross-platform, is another matter.

Anyone see any problems with the above?

[cronodragon]

Anyone see any problems with the above?

I would let I/O run on any available core, not restricted for time critical engine operations, being it the most time consuming operation.

[JSoftware]

Using opengl you can only reference the window that has been opened in the same thread

This has a few complications with loading and updating stuff in the game update thread

[NecroDOME]

My code almost works as follows:


one thread for rendering and updating the controls (called the main thread) and several threads for updating the game logic/physics.

So What I basically do in the game loop is:
Main thread - Update input
Main thread - Start worker threads
Worker thread - Update some stuff 1
Worker thread - Update some stuff 2
Worker thread - Update some stuff 3
Main thread - Wait till all worker threads are finished (synchronize)
Main thread - Render

Maybe I can update the input while im rendering. U don't think ist a good idea to update the game logic/physics while rendering. This may cause (if you have a low frame rate) some things update to late or to early. For example: in a race game when you are driving behind a car, it may look like the car is "jumpy".
May be this can be done for none important stuff like particles.

[NecroDOME]

What about an Event Based Asynchronous Pattern - http://msdn2.microsoft.com/en-us/library/ms228974.aspx?
Sound like it could be useful, but not sure how practical it would be in game.

Currently where I work the are implementing this in an application. It can be used in games, but I would say: don't do it with small pieces of code, but for example: take particles, physics and game logic as separate updates. (This would make 3 threads)

[savage]

These links talk about multi-core programming in relation to XBox 360, but should be applicable to other platforms...

Coding For Multiple Cores on Xbox 360 and Microsoft Windows
http://msdn2.microsoft.com/en-us/lib...,printer).aspx

Lockless Programming Considerations for Xbox 360 and Microsoft Windows
http://msdn2.microsoft.com/en-us/lib...,printer).aspx