   multithread game engine design
  ive been looking for some good documentation and discussions on multithread design in game engines... and i havent found much... i found a good video from intel where they discuss 3 different approaches to threading games.. but they dont go into much detail... and im unsure which would be better... ive also looked at some articles at gamasutra, but they dont say much...is there any good papers, presentations or other resources discussing this?right now im using a render-split (producer/consumer) system... where i have a render thread and a do everything else thread... but its not very scalable over more than 2 threads... sure i could have more threads in the "do everything else" thread...but i would like a good system where one simply can add a new "subsystem" such as AI without having to change much of the code...something like.... Subsystem    Subsystem   \/   Service  |   GameDatawhere one have several subsystems that can read simultanously the game/state data... and send results as commands to the "service" which then updates the gamedata... the gamedata probably should be double buffered to avoid waiting... they mentioned it briefly at this "intel video"... but didnt discuss any specific detail or solutions to some issues i have   
  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 RealMarkPI 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 RealMarkPI 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 MJPI 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?   