Threading - Do I Need It?
-
- Greenskin
- Posts: 132
- Joined: Mon Aug 02, 2004 7:40 am
- Location: Austin, Texas
Threading - Do I Need It?
I have heard some how Ogre is currently not 'thread-safe'. Do most fully fleshed out projects require threading to spread the load between the sound, physics, AI, graphics, filesystem etc.. or is it possible to remain threadless and still have a smoothly runninng, load distributed AAA application?
Also links and howtos would be good too like this one http://www.linuxselfhelp.com/HOWTO/C++P ... TO-18.html
Also, are pthreads a related topic?
Also links and howtos would be good too like this one http://www.linuxselfhelp.com/HOWTO/C++P ... TO-18.html
Also, are pthreads a related topic?
-
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
You should thread things that naturally fall into the background, ie to be spread over multiple frames. That's AI, buffering of streaming data, but probably not physics (because you need to keep it in sync with the frame rate if it's not going to look weird). None of these things are Ogre itself. Due to the fact that the graphics are the most noticeable thing, and that the GPU is asynchronous anyway, rendering processes are rarely farmed out to the background, so there's generally no need for thread safety. Projects which use threading thread non-graphical things.
The one case where it might be useful is background loading using the resource system. In Azathoth the resource system is (experimentally) thread safe if you set OGRE_THREAD_SUPPORT to 1, allowing you to load things in a background thread if you want. But that's only the resource system, nothing else is thread safe, and in my opinion has no need to be. We use boost::threads for this, personally it seemed a much better solution than anything else I've seen (it reminds me of Java threads).
I also talk about it here: http://www.ogre3d.org/phpBB2/viewtopic.php?t=7043
The one case where it might be useful is background loading using the resource system. In Azathoth the resource system is (experimentally) thread safe if you set OGRE_THREAD_SUPPORT to 1, allowing you to load things in a background thread if you want. But that's only the resource system, nothing else is thread safe, and in my opinion has no need to be. We use boost::threads for this, personally it seemed a much better solution than anything else I've seen (it reminds me of Java threads).
I also talk about it here: http://www.ogre3d.org/phpBB2/viewtopic.php?t=7043
-
- Greenskin
- Posts: 132
- Joined: Mon Aug 02, 2004 7:40 am
- Location: Austin, Texas
Do you think in terms of the most important process (probably graphics) or the one that updates the most frequently (physics)? I was talking to some developers of two racing sims Motorsport and TORCS about physics and they said that there physics ran about 300hz in game time:
So would Graphics be technically be running slower (over many 'frames') than the physics and need to be threaded? Or would you more likely run your physics algorithm several frames during one graphics frames?(18:54:56) berniw: In TORCS the physics runs with 500Hz in game time which is usually much faster than real time, so if the physics caught up the real time we can spit out a frame.
-
- Kobold
- Posts: 34
- Joined: Mon Jan 03, 2005 5:07 am
Keep in mind you don't need threads to run systems at varying rates (keep countdowns, if time is up step the system, if not move on).
If you're using ogre for a game threading isn't really necessary (like sinbad said, graphics are already asynchronous).
For things like physics, multi-steps are often done (instead of updating the physics simulation 30 milliseconds, you might have it do 15 milliseconds 2 times. Physics simulations get less accurate with bigger updates, which doesn't apply to most other systems).
You wouldn't want to simply run a physics update multiple times for each graphics one, you should work it out with timers and countdowns.
Hope this helps.
BTW, hello all from the newest community moderator
If you're using ogre for a game threading isn't really necessary (like sinbad said, graphics are already asynchronous).
For things like physics, multi-steps are often done (instead of updating the physics simulation 30 milliseconds, you might have it do 15 milliseconds 2 times. Physics simulations get less accurate with bigger updates, which doesn't apply to most other systems).
You wouldn't want to simply run a physics update multiple times for each graphics one, you should work it out with timers and countdowns.
Hope this helps.
BTW, hello all from the newest community moderator
-
- OGRE Community Helper
- Posts: 198
- Joined: Sat Oct 02, 2004 9:11 am
- Location: San Francisco, California, USA
Re: Threading - Do I Need It?
I should point out that even though Ogre is not thread-safe, there is no reason why your application cannot use threads. It just means that you cannot have multiple threads which deal with Ogre.
As long as you make sure that only a single thread handles all your Ogre-related tasks, you are free to run your sound engine or AI scripts in other threads.
As long as you make sure that only a single thread handles all your Ogre-related tasks, you are free to run your sound engine or AI scripts in other threads.
-
- OGRE Retired Team Member
- Posts: 3067
- Joined: Tue Feb 10, 2004 12:53 pm
- Location: The Netherlands
- x 1
Welcome to the team!alphabeta wrote: BTW, hello all from the newest community moderator
Or keep a global OGRE-lock. But your approach is cleaner, I always try to keep threads as seperate as possible to prevent nasty untracable bugs.As long as you make sure that only a single thread handles all your Ogre-related tasks, you are free to run your sound engine or AI scripts in other threads.
-
- OGRE Retired Team Member
- Posts: 2543
- Joined: Fri Oct 24, 2003 2:53 am
- Location: San Diego, Ca
- x 2
I use threads in the video plugin, and I use the Ogre Frame events to ensure Ogre graphics calls are done in the main thread. Works quite nicely.
Have a question about Input? Video? WGE? Come on over... http://www.wreckedgames.com/forum/
-
- OGRE Retired Moderator
- Posts: 2653
- Joined: Wed Sep 24, 2003 8:07 am
- Location: Haute Garonne, France
- x 4
I used to have physics and graphics in separated threads but I now have them in a single thread due to several problems (timestep integrator problems, network synchro, hard-debugging, etc..)
For physics and threads, read the articles here:
http://69.55.229.29/articles/Timestep.html
( Author could even give some answers here : http://www.ogre3d.org/phpBB2/viewtopic. ... 1526#51526 )
For physics and threads, read the articles here:
http://69.55.229.29/articles/Timestep.html
( Author could even give some answers here : http://www.ogre3d.org/phpBB2/viewtopic. ... 1526#51526 )
-
- Halfling
- Posts: 85
- Joined: Tue Jun 10, 2003 2:57 pm
I agree Ogre does not need to be multi-threaded itself.
But multi-threading / concurrency seems to be the next big thing in software development (with those new chips being multi-cores), so you should better have a look to it now (if not already). Read what Herb Sutter has to say about that:
http://www.gotw.ca/publications/concurrency-ddj.htm
But multi-threading / concurrency seems to be the next big thing in software development (with those new chips being multi-cores), so you should better have a look to it now (if not already). Read what Herb Sutter has to say about that:
http://www.gotw.ca/publications/concurrency-ddj.htm
-
- Kobold
- Posts: 34
- Joined: Mon Jan 03, 2005 5:07 am
Here comes the problem facing you as a developerNow, not all applications (or, more precisely, important operations of an application) are amenable to parallelization. True, some problems, such as compilation, are almost ideally parallelizable.
Threads on a single core cpu is nothing you couldn't emulate in software, but taking advantage of multiple cores is. This doesn't mean that every application will need multiple threads, just that they've finally found their use.
If you get the opportunity to send a thread on its jolly way working with data not directly required by other threads, then you should consider taking it. As sinbad said, graphics and physics should probably be kept in the same thread for this reason (what good is a high frame rate if your game isn't actually changing? On the other hand, graphics don't depend on immediate updates from the AI to look right). Buffering and loading are good ones because they don't need to directly work with other threads. Sure, the other systems will eventually need the data being loaded, but if it comes down to it they could simply wait until the thread is finished (at least some of the work will have been done, and you're not really wasting time as the other systems would have had to wait longer in a single thread application anyway).
These all place a big challenge on the programmer (debugging with multiple threads is generally a pain), and add alot of chances for a bug or logic error to occur. Consider the costs and benefits to your choice, and approach the problem with a plan.
To answer your question, yes, it's possible to remain threadless and have a smoothly running application (it's pretty rare to see a multithreaded game, but that may change rather rapidly).
-
- Greenskin
- Posts: 132
- Joined: Mon Aug 02, 2004 7:40 am
- Location: Austin, Texas
-
- OGRE Expert User
- Posts: 1422
- Joined: Sat May 22, 2004 5:28 am
- Location: Bucharest
- x 8
-
- OGRE Retired Team Member
- Posts: 19269
- Joined: Sun Oct 06, 2002 11:19 pm
- Location: Guernsey, Channel Islands
- x 66
No, because creating nodes and entities requires access to the internal SceneManager state. Thread safety is all about shared data - if you access shared data in more than one thread, you have the potential for a race condition.
The overhead of creating nodes and entities (whose meshes are already loaded) is trivial anyway, not worth passing off to another thread. It's loading times which are the most cumbersome, hence why resource loading is the main target for thread safety.
The overhead of creating nodes and entities (whose meshes are already loaded) is trivial anyway, not worth passing off to another thread. It's loading times which are the most cumbersome, hence why resource loading is the main target for thread safety.
-
- OGRE Expert User
- Posts: 1422
- Joined: Sat May 22, 2004 5:28 am
- Location: Bucharest
- x 8
-
- OGRE Community Helper
- Posts: 198
- Joined: Sat Oct 02, 2004 9:11 am
- Location: San Francisco, California, USA
If you have only one CPU, and it has only one core, many multithreading mistakes will go unnoticed. Since only one thread can physically run at a time, your code can get away with murder.
But when that application runs on a multi-core CPU, like a Pentium 4 with HyperThreading, you'll suddenly get weird errors or crashes. And then you'll probably blame that particular computer instead of your own code!
Creative Labs got /burned/ by this with their Sound Blaster Live! drivers. When they were released (and probably still to this day) the Creative Labs drivers would bluescreen randomly on multi-CPU or multi-core systems. The solution was to buy a different sound card. (Which is a good idea anyway; the real-life signal/noise and sample-rate-support specs on the Live and Audigy/Extigy series could put Creative Labs in jail for false advertising )
But when that application runs on a multi-core CPU, like a Pentium 4 with HyperThreading, you'll suddenly get weird errors or crashes. And then you'll probably blame that particular computer instead of your own code!
Creative Labs got /burned/ by this with their Sound Blaster Live! drivers. When they were released (and probably still to this day) the Creative Labs drivers would bluescreen randomly on multi-CPU or multi-core systems. The solution was to buy a different sound card. (Which is a good idea anyway; the real-life signal/noise and sample-rate-support specs on the Live and Audigy/Extigy series could put Creative Labs in jail for false advertising )
-
- OGRE Expert User
- Posts: 1422
- Joined: Sat May 22, 2004 5:28 am
- Location: Bucharest
- x 8
u know i actually have a Pentrum4 cpu but i disabled the hyperthreading since all other team members dont have this luxury...in order to test it right (since concurent threads work on my machine, different threads at the same time worked fine, but never worked as expected on single threded machine) ...
i never thought that the problem could be both ways!
i never thought that the problem could be both ways!
-
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 535
Actually, Pentium 4 with hyperthreading isn't multi core.
Intel and AMD haven't released multi core cpus yet, earliest expected seems to be june for amd and september for intel.
Hyperthreading allows 2 different execution units in a cpu to run at the same time, as a simulated dual core system. But that only happens ocassionally, intel say the maximum performance boost is around 25%. It's different to a multi core system which is 2 or more actual cpus in the one package (sharing cache on intel or with cache each on amd).
Intel and AMD haven't released multi core cpus yet, earliest expected seems to be june for amd and september for intel.
Hyperthreading allows 2 different execution units in a cpu to run at the same time, as a simulated dual core system. But that only happens ocassionally, intel say the maximum performance boost is around 25%. It's different to a multi core system which is 2 or more actual cpus in the one package (sharing cache on intel or with cache each on amd).
-
- OGRE Expert User
- Posts: 1422
- Joined: Sat May 22, 2004 5:28 am
- Location: Bucharest
- x 8
-
- Gremlin
- Posts: 150
- Joined: Wed Oct 20, 2004 2:35 pm
- Location: Paris, France
It's really dependent on what you do. I tried some heavy rendering with maya on P4 with HyperThreading activated and the performance boost was way over 25%. However, it is the only case I could see this kind of results.Kojack wrote:But that only happens ocassionally, intel say the maximum performance boost is around 25%. It's different to a multi core system which is 2 or more actual cpus in the one package (sharing cache on intel or with cache each on amd).
Banania
-
- Gnoblar
- Posts: 2
- Joined: Mon Dec 11, 2006 7:14 pm
Threaded DX9 Render System
These posts are old but I figured I should just continue them.
I created a proof-of-concept threading of the DX9 render system plug-in just to prove that Ogre can benefit from having the DX system run on a separate thread. I was able to get some decent speedups on some of the demos even when running on a threaded driver.
I don’t believe this whole exercise will be moot since DX10 is already threaded. It will depend on the threading performance of DX10 and how an app intends to use the threading. Also, a DX10 dependency might not be desired either.
Remember that this is just a proof-of-concept and is not necessarily the ideal implementation for Ogre. It isn’t perfect either since I found an additional speedup after having this published (a small change but a potentially big impact depending on the app). We can discuss here if anyone is interested.
You can get to the article and source code (based on 1.2.0) here: http://www.intel.com/cd/ids/developer/a ... 331359.htm.
I created a proof-of-concept threading of the DX9 render system plug-in just to prove that Ogre can benefit from having the DX system run on a separate thread. I was able to get some decent speedups on some of the demos even when running on a threaded driver.
I don’t believe this whole exercise will be moot since DX10 is already threaded. It will depend on the threading performance of DX10 and how an app intends to use the threading. Also, a DX10 dependency might not be desired either.
Remember that this is just a proof-of-concept and is not necessarily the ideal implementation for Ogre. It isn’t perfect either since I found an additional speedup after having this published (a small change but a potentially big impact depending on the app). We can discuss here if anyone is interested.
You can get to the article and source code (based on 1.2.0) here: http://www.intel.com/cd/ids/developer/a ... 331359.htm.
-
- OGRE Team Member
- Posts: 1525
- Joined: Fri Feb 03, 2006 10:37 pm
- Location: Austria - Leoben
- x 99
-
- Gnoblar
- Posts: 2
- Joined: Mon Dec 11, 2006 7:14 pm
threaded work done
That's odd it worked for me. Maybe the premissions got messed up so that external viewers can see it.
I essentially placed the majority of DX calls into their own thread. The goal is to have the DX runtime execute on a separate thread. So when the render system makes a call to DX it's actually calling classes I had created which queue the call to DX to be executed in a separate thread.
I essentially placed the majority of DX calls into their own thread. The goal is to have the DX runtime execute on a separate thread. So when the render system makes a call to DX it's actually calling classes I had created which queue the call to DX to be executed in a separate thread.