Hi there i'm just sharing a graph i made to understand the tutorial about multithreading.
It shows how function call are organizes in the tutorial: Tutorial06_Multithreading.
It may help beginnerg like me.
https://github.com/screwt/quickplate/tr ... graph-call
I have a question, if you'd have to start a project (Video game) would you use this multithreading approach?
Sharing understanding - Tutorial06 Multithreading - ogre 2
-
screwt
- Kobold
- Posts: 29
- Joined: Wed Feb 28, 2007 9:18 am
- x 2
-
dark_sylinc
- OGRE Team Member
- Posts: 5511
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1379
Re: Sharing understanding - Tutorial06 Multithreading - ogre 2
Hi!
I'm the one who wrote this code so I'm biased and my answer is obviously going to be "yes", and not just for games. This multithreading approach is often called 'render split multithreading'.
This method is also explained by a Kraken Empire blog post.
If you're asking 'are there other/better multithreading approaches?' the answer is also yes. For example Destiny Multithreaded Rendering Architecture uses job based multithreading. You will find the talk descibres several concepts which are also taught by our tutorial such as decoupling simulation and rendering, and having game objects separated from their visibility (i.e. the position & orientation at which the object is being rendered does not necessarily have to be in sync with the transform the physics simulation is currently processing).
Naughty Dog also has a talk named Parallelizing the Naughty Dog engine using Fibers which also uses a lot of jobs.
These two other approaches should scale much better to many cores than the render split method (which by design scales to two cores, maybe three or with luck four if physics has internal multithreaded parts, or if you decouple some systems into other threads, like networking or sound but I doubt those two could keep a whole CPU busy unless you're doing HRTF 3D audio).
But task/job based approaches IMO are harder to develop for unless you're already well experienced in simulation, rendering and multithreading.
Render split method is simple and easy because it takes a simple serial approach (see Tutorial03 & Tutorial04) and effortlessly turns it into 2 threads. And if you suspect of a race condition, you can always switch to serial simulation (i.e. what Tutorial04 does) to see if the bugs still happen.
Cheers
Matias
I'm the one who wrote this code so I'm biased and my answer is obviously going to be "yes", and not just for games. This multithreading approach is often called 'render split multithreading'.
This method is also explained by a Kraken Empire blog post.
If you're asking 'are there other/better multithreading approaches?' the answer is also yes. For example Destiny Multithreaded Rendering Architecture uses job based multithreading. You will find the talk descibres several concepts which are also taught by our tutorial such as decoupling simulation and rendering, and having game objects separated from their visibility (i.e. the position & orientation at which the object is being rendered does not necessarily have to be in sync with the transform the physics simulation is currently processing).
Naughty Dog also has a talk named Parallelizing the Naughty Dog engine using Fibers which also uses a lot of jobs.
These two other approaches should scale much better to many cores than the render split method (which by design scales to two cores, maybe three or with luck four if physics has internal multithreaded parts, or if you decouple some systems into other threads, like networking or sound but I doubt those two could keep a whole CPU busy unless you're doing HRTF 3D audio).
But task/job based approaches IMO are harder to develop for unless you're already well experienced in simulation, rendering and multithreading.
Render split method is simple and easy because it takes a simple serial approach (see Tutorial03 & Tutorial04) and effortlessly turns it into 2 threads. And if you suspect of a race condition, you can always switch to serial simulation (i.e. what Tutorial04 does) to see if the bugs still happen.
Cheers
Matias