[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