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 >> >