Task-based Threading and Ogre

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
Post Reply
Fritznorm
Kobold
Posts: 26
Joined: Mon Aug 02, 2010 5:36 pm

Task-based Threading and Ogre

Post by Fritznorm »

Sort of an architectural question, which is complicated by my lack of understanding of how Ogre threads itself in 2.1.

So on the non-graphics side, I'm trying to use task-based techniques (specifically TBB, but it could be anything of this nature) because my world models are quite computation-heavy. I think Ogre 2.1 still needs the graphics to have its own thread, though I know some parts of this are multithreaded (this causes some confusion!).

What I'm trying to avoid is oversubscription - is it enough to reserve a thread for Ogre and let the task scheduler allocate the rest, or do I need to do something more complex, or perhaps overload some of the Ogre components to make them use the underlying task scheduler for the program? I'd rather not be dominated by how Ogre chooses to implement threading.

Any thoughts on the best approach?
User avatar
MadWatch
Halfling
Posts: 64
Joined: Sat Jul 06, 2013 11:25 am
x 4

Re: Task-based Threading and Ogre

Post by MadWatch »

AFAIK, if you compiled Ogre without thread support, then the SceneManager is the only thing that use threads. When you create a scene manager you decide how many threads it will use and those threads will only be used while you're rendering a frame (while inside the Root::renderOneFrame() method, the rest of the time they're sleeping).

If you have several scene managers, they will all create their own threads but only one will use them at a time. Also, it seems that when a scene manager use its threads the main thread is doing nothing (it waits for the threads to complete their job).

So, if you don't need Ogre to be threaded, you can just create all your scenes managers by passing 1 for the second parameter of Root::createSceneManager() so Ogre won't use any threads at all. If you want Ogre to be threaded then pass N for the second parameter of Root::createSceneManager() and keep in mind that Ogre can use up to N threads while in Root::renderOneFrame().

Also, you could probably implement your own scene manager to make it use your thread pool (maybe I will try that one day).

Regards
Fritznorm
Kobold
Posts: 26
Joined: Mon Aug 02, 2010 5:36 pm

Re: Task-based Threading and Ogre

Post by Fritznorm »

Ok, so I have to:
  • Determine the number of cores in the system
  • Assign a proportion of those (based on some heuristic?) to the scenemanager
  • Assign the rest to the task scheduler to use in its internal threadpool.
Is this something other people are doing? Do I still need to make sure I only update Ogre from a single thread - for example, if I thread my model of the world and use it to update positions that need to be reflected in Ogre, so I need to do any locking? Not sure what the thread-safety guarantees are in 2.1
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Task-based Threading and Ogre

Post by dark_sylinc »

Fritznorm wrote:Ok, so I have to:
  • Determine the number of cores in the system
  • Assign a proportion of those (based on some heuristic?) to the scenemanager
  • Assign the rest to the task scheduler to use in its internal threadpool.
Yes. Experimentation will be needed as oversubscription (caused by your threadpool threads) may yield better or worse performance depending on overall load balancing.
Fritznorm wrote:Do I still need to make sure I only update Ogre from a single thread - for example, if I thread my model of the world and use it to update positions that need to be reflected in Ogre, so I need to do any locking? Not sure what the thread-safety guarantees are in 2.1
There's two tutorials called Tutorial05_MultithreadingBasics and Tutorial06_Multithreading explaining exactly this. We don't do any locking internally, and it is your job to ensure Ogre doesn't end up inside SceneManager::updateSceneGraph (i.e. inside Root::renderOneFrame) while you're updating the nodes from another thread.
Also it's your job to ensure you don't call _getDerived*Updated variations of the nodes (i.e. _getDerivedUpdated) while you're updating a node from another thread.
Also renderOneFrame must happen in the thread you've initialized Ogre due to API reasons (OpenGL does not like at all being migrated to another thread)
Fritznorm
Kobold
Posts: 26
Joined: Mon Aug 02, 2010 5:36 pm

Re: Task-based Threading and Ogre

Post by Fritznorm »

I've looked briefly at the tutorials but couldn't see much in the way of detailed explanation within or without the code - will take another look later on. Assume it must be some set of comments somewhere in the sample...

But thanks for the basic outline - I think I understand. Looks like the render step will be a bit of a pinch point, but suspect that's unavoidable in any sane architecture.
Post Reply