Fw: is ODE multi-threaded?

"David Black" <[email protected]>
Newsgroups gmane.comp.lib.ode
Message-ID <8CBE7739668E4DA497AB8B09D13C6085@dblackPC>
(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
>> [email protected]
>> http://ode.org/mailman/listinfo/ode
>>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.