I found this interesting article the other day while looking for a multithreading design for my engine without having to screw up my existing architecture
The article can be found here: http://software.intel.com/en-us/article ... cheduling/ (source code included)
I successfully got it implemented in my own rendering engine (since my game engine doesn't really have any other functionality besides rendering yet) and with some small modifications this could be applicable to irrlicht too, with a really easy mechanism for adding other libraries like physics, audio, AI, etc.
This mechanism will spawn a number of worker threads equal to the amount of hardware threads (CPU cores) your computer has, and will divide all the work, implemented as separate tasks, among these threads using a work-stealing scheduling algo.
In my engine design I let every entity that needs to be updated the next frame register itself with my scene manager, it will then gather all information needed for rendering (and for staying thread-safe) and separate tasks are created (animation/physics tasks, decision making, etc.) which are then fed to the scheduler. After all threads have completed their work the scene will be drawn and presented to the user (maybe when I start on a DX11 driver I will be able to multithread this too)
This could all be changed in the future, my engine is still an unstable WIP so architecture changes and optimizations will probably happen
This may not be the most optimal multithreading system out there, but it's definitely a great system for people being used to writing single threaded games
Work-stealing multithreading
-
- Posts: 1215
- Joined: Tue Jan 09, 2007 7:03 pm
- Location: Leuven, Belgium
no replies? odd
Its a good read, I remember reading something similar on Insomniac's R&D section: http://www.insomniacgames.com/research_dev/
(I cant find the exact article, sorry)
This is the one of the most efficient ways to go about multithreading in modern games:
both the engine and the game can make use of MT without hogging up all the resources for themselves, and it's also very open for debugging and verifying thread safety
My engine doesn't do it this way (yet).
its quite pointless to use multiple threads on iOS devices anyway, but some form of thread management is crucial these days on PC and modern games consoles
*thumbs up*
Its a good read, I remember reading something similar on Insomniac's R&D section: http://www.insomniacgames.com/research_dev/
(I cant find the exact article, sorry)
This is the one of the most efficient ways to go about multithreading in modern games:
both the engine and the game can make use of MT without hogging up all the resources for themselves, and it's also very open for debugging and verifying thread safety
My engine doesn't do it this way (yet).
its quite pointless to use multiple threads on iOS devices anyway, but some form of thread management is crucial these days on PC and modern games consoles
*thumbs up*
-
- Posts: 126
- Joined: Wed Sep 29, 2010 8:23 pm
-
- Posts: 1215
- Joined: Tue Jan 09, 2007 7:03 pm
- Location: Leuven, Belgium
The only problem I've found is that when animation calculations are done task-based, the animations can become quite choppy when not in a synced framerate
This happens in irrlicht too, probably since the timer class in my engine uses the same mechanics as irrlicht's (on Win32 platforms)
Not setting timer cpu affinity to a single cpu resolves the choppiness a little bit for some reason (the way I update animation times both in my hacked irrlicht version and my own engine is completely dependent from task scheduling and execution)
It's not a showstopper bug or anything, it just gets annoying sometimes
I'll probably find a solution when I've finished my current main priorities
This happens in irrlicht too, probably since the timer class in my engine uses the same mechanics as irrlicht's (on Win32 platforms)
Not setting timer cpu affinity to a single cpu resolves the choppiness a little bit for some reason (the way I update animation times both in my hacked irrlicht version and my own engine is completely dependent from task scheduling and execution)
It's not a showstopper bug or anything, it just gets annoying sometimes
I'll probably find a solution when I've finished my current main priorities
-
- Posts: 1215
- Joined: Tue Jan 09, 2007 7:03 pm
- Location: Leuven, Belgium
You'll need to modify the engine slightly to let it handle things multithreaded, so a simple example is not really possibleFury. wrote:does someone put any example of multithreading with irrlicht (a working one, not a library that do that but don't use irrilcht)
And multithreading works transparent, meaning that you yourself won't have to keep in mind that the engine is multithreaded, since it will handle all of this on its own
-
- Posts: 1215
- Joined: Tue Jan 09, 2007 7:03 pm
- Location: Leuven, Belgium
A little update for those interested
I extended this system by implementing a timestep system, so tasks can be executed at a set interval, which did wonders for my framerate
I also got to implementing an OpenAL wrapper for my engine and I immediately made it work with the tasking system
Works like a charm
I extended this system by implementing a timestep system, so tasks can be executed at a set interval, which did wonders for my framerate
I also got to implementing an OpenAL wrapper for my engine and I immediately made it work with the tasking system
Works like a charm