Threading - Do I Need It?

Get answers to all your basic programming questions. No Ogre questions, please!
User avatar
bana
Greenskin
Posts: 132
Joined: Mon Aug 02, 2004 7:40 am
Location: Austin, Texas

Threading - Do I Need It?

Post by bana »

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?
A proud member of the OpenFrag Coding Team.
http://coolhands.blogspot.com/
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66

Post by sinbad »

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
User avatar
bana
Greenskin
Posts: 132
Joined: Mon Aug 02, 2004 7:40 am
Location: Austin, Texas

Post by bana »

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:
(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.
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?
A proud member of the OpenFrag Coding Team.
http://coolhands.blogspot.com/
alphabeta
Kobold
Posts: 34
Joined: Mon Jan 03, 2005 5:07 am

Post by alphabeta »

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 :)
qsilver
OGRE Community Helper
OGRE Community Helper
Posts: 198
Joined: Sat Oct 02, 2004 9:11 am
Location: San Francisco, California, USA

Re: Threading - Do I Need It?

Post by qsilver »

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.
User avatar
:wumpus:
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3067
Joined: Tue Feb 10, 2004 12:53 pm
Location: The Netherlands
x 1

Post by :wumpus: »

alphabeta wrote: BTW, hello all from the newest community moderator :)
Welcome to the team! :D
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.
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.
User avatar
pjcast
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2543
Joined: Fri Oct 24, 2003 2:53 am
Location: San Diego, Ca
x 2

Post by pjcast »

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/
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4

Post by tuan kuranes »

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 )
User avatar
epopov
Halfling
Posts: 85
Joined: Tue Jun 10, 2003 2:57 pm

Post by epopov »

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
alphabeta
Kobold
Posts: 34
Joined: Mon Jan 03, 2005 5:07 am

Post by alphabeta »

Now, 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.
Here comes the problem facing you as a developer :twisted:
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).
User avatar
bana
Greenskin
Posts: 132
Joined: Mon Aug 02, 2004 7:40 am
Location: Austin, Texas

Post by bana »

A proud member of the OpenFrag Coding Team.
http://coolhands.blogspot.com/
User avatar
eugen
OGRE Expert User
OGRE Expert User
Posts: 1422
Joined: Sat May 22, 2004 5:28 am
Location: Bucharest
x 8

Post by eugen »

i for example, create nodes and attach entities in another thread than ogre's but i only let ogre's thread to attach those nodes to its main nodes structure! is this thread safe?
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66

Post by sinbad »

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.
User avatar
eugen
OGRE Expert User
OGRE Expert User
Posts: 1422
Joined: Sat May 22, 2004 5:28 am
Location: Bucharest
x 8

Post by eugen »

tought so!
althought, i have no error using it :( i think is just luck!
qsilver
OGRE Community Helper
OGRE Community Helper
Posts: 198
Joined: Sat Oct 02, 2004 9:11 am
Location: San Francisco, California, USA

Post by qsilver »

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 ;))
User avatar
eugen
OGRE Expert User
OGRE Expert User
Posts: 1422
Joined: Sat May 22, 2004 5:28 am
Location: Bucharest
x 8

Post by eugen »

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!
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 535

Post by Kojack »

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).
User avatar
eugen
OGRE Expert User
OGRE Expert User
Posts: 1422
Joined: Sat May 22, 2004 5:28 am
Location: Bucharest
x 8

Post by eugen »

i just test the program with hyperthreading activated...i got the same results! (no error)
anyway..the change must be implemented, since de design is architecturaly incorect!
User avatar
Banania
Gremlin
Posts: 150
Joined: Wed Oct 20, 2004 2:35 pm
Location: Paris, France

Post by Banania »

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).
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.
Banania
squid
Gnoblar
Posts: 2
Joined: Mon Dec 11, 2006 7:14 pm

Threaded DX9 Render System

Post by squid »

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.
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99

Post by Wolfmanfx »

hi,
the link doesnt work for me.
Can u descripe what u made threaded in the rendersystem?
squid
Gnoblar
Posts: 2
Joined: Mon Dec 11, 2006 7:14 pm

threaded work done

Post by squid »

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.