[ODE] Ideas for threading ODE...

[Alen Ladavac]

[a few short, mostly on-topic, rambles]

If talking about physics only, ideal solution would be to use the
fork-and-join model, because the load is more evenly balanced between
threads. We did some experiments with the solve and integrate part in this
way, and it is relatively easy to do. I imagine it would not be very
complicated to do that in the collision part as well. If those are both
parallelized in this way, one can expect nearly 100% use of all available 
cores (as long as there is enough object islands to keep all cores busy).

Downside is that you now have fully parellized physics but still have only 
single core working on the rendering while others are idling during that 
time.

Now, if there was a nice solution for fork-and-join processing of rendering 
algorithms, then this system would be great for games. Until then, 
everything is rather shady...

On the other hand, if you do rendering on one and physics on the other 
thread then: (a) you can only use 2 cores and (b) you are assuming that 
rendering and physics are equally CPU-heavy. Both of which are not very 
scaleable choices.

On more than one core, one might try to use one core for rendering and 
remainder for physics, perhaps....

(This all assumes we are talking about how to efficiently multithread in a 
multi-core environment. When considering multithreading for performance 
reasons on a single core, the answer is simply: don't.)

Just my 2 cores,
Alen

----- Original Message ----- 
From: "Jaroslav Sinecky" <jsinecky at tiscali.cz>
To: "ode" <ode at q12.org>
Sent: Saturday, August 20, 2005 07:31
Subject: RE: [ODE] Ideas for threading ODE...


> In fact in our ODE-based game I tried to put physics in a separate thread
> expecting we could gain some performance even on single-core processors
> simply because during rendering it's GPU who works more, isn't it? Or at
> least there is high possibility that CPU gets idle when GPU task queue
> gets
> full or while waiting to finish rendering the frame and swap buffers. But
> we
> didn't notice any gain at all :-(
>
> Has some else tried this? Is my assumption about CPU possible idle during
> rendering wrong?
>
> We use DirectX for rendering, but in some other little OpenGL based
> project
> some time ago, I put some application stage code (precomputing for next
> frame) in between last rendering command and swapBuffers call and got
> really
> cool fps increase. (This was all on just one thread though)
>
> Jaroslav
>
>
>> -----Original Message-----
>> From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf
>> Of Jon Watte (ODE)
>> Sent: Friday, August 19, 2005 8:21 PM
>> To: Tyler Streeter
>> Cc: ode
>> Subject: Re: [ODE] Ideas for threading ODE...
>>
>>
>>
>> > Using OpenMP (http://www.openmp.org) would make it easy to add support
>> > for multiple threads.  OpenMP is great for data parallelism, which I
>>
>> I think OpenMP is not the right solution for PC architectures and game
>> algorithms.
>>
>> You could multi-thread ODE by putting the entire stepper in a different
>> thread, and have the application do other useful work in the meanwhile.
>> You can provide double-buffering or snapshotting of body state
>> (position/orientation) to make it easy to do rendering in the
>> non-physics thread.
>>
>> The collision callbacks have to be carefully structured to not interlock
>> with the main world update and AI, but that's a reasonable restriction.
>>
>> Any finer-grain threading than that is unlikely to lead to performance
>> gains for PC games. In fact, may lead to lower performance.
>>
>> Cheers,
>>
>>                   / h+
>>
>> _______________________________________________
>> ODE mailing list
>> ODE at q12.org
>> http://q12.org/mailman/listinfo/ode
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>