[ODE] Fw: is ODE multi-threaded?

David Black dblack at fastmail.fm
Wed Oct 3 16:54:26 MST 2007


(Sorry defunct reply to address on my last email)

>> What I do is put all of ODE in one thread, and then all of rendering,
>> application logic, etc in one or more other threads. If your simulation
>> needs more power than a full CPU core gives you, ODE might not be the
>> right choice anyway. (Hint: there exist hardware accelerators)
>
> I believe there can be value splitting the physics further than a seperate 
> thread for just physics, although mainly if you are (un)lucky enough to be 
> developing for a platform with more than two cores(I guess this will 
> include PC in the next year or two as well).
>
> But this is dependant on the size and type of physics load, the 
> scheduling/threading requirements of other parts of the system, what you 
> want to spend cores on etc etc. ie it is probably something to decide on a 
> case by case basis.
>
> Even if there is sufficient physics load it also needs to be in the parts 
> of the pipeline which are paralized. I have seen scenes which get nearly 
> linear speedup as the number of cores increase vs scenes which get next to 
> no speedup. ie profiling which parts of the physics engine is being 
> stressed and how the work can be split up into packets is very important, 
> such things can be difficult to judge and balance well.
>
> As for physics hardware, the same considerations apply, but you have less 
> control over how the paralization is done so you have to stick to the 
> optimal usage patterns for the hardware, which may or may not fit your 
> application... Plus the problem of getting the paralization right may 
> become harder as the hardware likely consists of more, but less powerful 
> processing elements.
>
> David
>>
>> Cheers,
>>
>>          / h+
>>
>>
>>> However, you would end up with a 2-stage pipeline, where the solver
>>> for frame N uses collisions from frame N-1.
>>> Not sure if you would encounter race-conditions though.
>>> You would at minimum need to use two different joint-groups for 
>>> contacts.
>>> It would make an interesting experiment.
>>> Anyone here got some profile stats lying around that can be shared?
>>> I'm interested in the comparision between dSpaceCollide() and
>>> dWorldQuickStep()
>>
>> _______________________________________________
>> ODE mailing list
>> ODE at ode.org
>> http://ode.org/mailman/listinfo/ode
>>
> 



More information about the ODE mailing list