multithread game engine design

I remember asking the same questions years and years ago. The problem with multi threaded engines is that an engine is essentially a state machine, which is very anti-multi threading. Managing states would require a mutex for each state, which could be in the hundreds for all you know. Mutexing, albeit fast, still takes its toll on the system. Not only that, but rendering also has to wait for an update pass to be completed. You don't want to render a scene half way through the update pass because you will get odd results.

If you really want to, put some of your trivial subsystems on a thread, such as music playing. I would suggest sticking with a single threaded system. Its easier to implement and is just as fast as a multi threaded system.



I honestly can't find the post I created, I bet its in limbo, but there must be tons of other similar questions posted here.

Quote:

Original post by RealMarkP I remember asking the same questions years and years ago. The problem with multi threaded engines is that an engine is essentially a state machine, which is very anti-multi threading. Managing states would require a mutex for each state, which could be in the hundreds for all you know. Mutexing, albeit fast, still takes its toll on the system. Not only that, but rendering also has to wait for an update pass to be completed. You don't want to render a scene half way through the update pass because you will get odd results. If you really want to, put some of your trivial subsystems on a thread, such as music playing. I would suggest sticking with a single threaded system. Its easier to implement and is just as fast as a multi threaded system. I honestly can't find the post I created, I bet its in limbo, but there must be tons of other similar questions posted here.

i dont see the same problems as you... i have already implemented a game engine without any mutexes at all using a single lockfree queue... with 100% core utilization on a dual core... however my design doesnt scale well with more cores...

I thought this was a good presentation.

Quote:

Original post by RealMarkP I remember asking the same questions years and years ago. The problem with multi threaded engines is that an engine is essentially a state machine, which is very anti-multi threading. Managing states would require a mutex for each state, which could be in the hundreds for all you know. Mutexing, albeit fast, still takes its toll on the system. Not only that, but rendering also has to wait for an update pass to be completed. You don't want to render a scene half way through the update pass because you will get odd results. If you really want to, put some of your trivial subsystems on a thread, such as music playing. I would suggest sticking with a single threaded system. Its easier to implement and is just as fast as a multi threaded system.

I think a game engine has quite a lot of things to do that can be parallelized.

If you're concerned that updating the scene and rendering it at the same time is a problem (maybe because of possible erratic object movement on a 1-frame basis), keep two scenes and update one into the other.

Or on a lower level, if you've got AI calculations to do, put all your AIs into a queue, create a thread for each CPU core and let the threads take AIs to process from the queue until it is empty. Sort of like a mini thread-pool.

Updating the scene can be done in a similar fashion by multiple threads, too. For example, if you've got a scene graph, instead of a single recursive scene tree traverser, whenever you encounter a scene node, put its children into a list that other threads can process from. If you're doing shader shorting, a simple lookup map with a series of lock-free render queues will take care of that.

If you're doing physics calculations, you likely have a system set up that isolates potential collision groups into "islands" (that's how ODE calls it). Each island is a perfect candidate for a thread.


Then again, some candidates like asynchronous rendering or resource loading that sound like they could benefit from threading, don't actually require threads. The GPU will render asynchronously by default and you can load files asynchronously without a thread - DMA allows the chipset to move data from the hard drive into memory without any help by the CPU.

-Markus-

Quote:

Original post by MJP I thought this was a good presentation.

that was a great presentation... i really like the task conecpt... and it works well with the intel tbb library which already has "task" and "task shedluer" implemented...

my only question here is how one would solve the problem where the windows message pump should never be blocked and the render thread has to be in a single thread...
would i have to create a "join" point before rendering?