Calling `dCollide` from multiple threads, good or bad idea?

[Vaillancourt]

Hi all,

Has anyone attempted to run the dCollide function in parallel?

The quick look I gave on the code, it seems that only `o1->recomputePosr();` (and o2) would pose an issue to running multiple calls to dCollide at the same time (on the same geom). 

Has anyone tried this?

Thanks!

Alexandre Vaillancourt

[Oleh Derevenko]

\build\premake4.lua

-------------------------  
   ... 
  newoption {

    trigger     = "with-ou",

    description = "Use TLS for global caches (allows threaded collision checks for separated spaces)"

  }

This option is enabled by default, actually. 

So, you can run collision checks in parallel for separate spaces. It requires proper synchronization/protection in callbacks, of course.

Oleh Derevenko

-- Skype with underscore

 

---

From: ode-...@googlegroups.com <ode-...@googlegroups.com> on behalf of Vaillancourt <alexandre.vai...@gmail.com>
Sent: Friday, December 20, 2024 18:20
To: ode-users <ode-...@googlegroups.com>
Subject: [ode-users] Calling `dCollide` from multiple threads, good or bad idea?

 

--
You received this message because you are subscribed to the Google Groups "ode-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ode-users+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ode-users/7c35e477-67b1-4596-9e56-761a9957897fn%40googlegroups.com.

---

This e-mail may contain privileged and confidential information. If you are not the intended recipient, be aware that any use, disclosure, copying or distribution of this e-mail or any attachments is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you.

[Vaillancourt]

Thanks for the reply Oley,

I'm using CMake to generate the solution and it appears that this is not enabled by default.

Could you tell me more a bit about this feature? Do you mean that geom-geom checks can be done within a single space in parallel with geom-geom checks in another space?

Our space hierarchy is a bit like this:

- global space contains spaces and geoms (e.g. "trigger" box geoms )

- sub-space contain geoms (e.g. one sub-space per vehicle, one sub-space per obstacles, etc), but geoms within a sub-space are not checked for collisions against each other

- we check for collisions with geoms within a sub-space with the geoms from another sub-space or the global space

So most of our dCollide checks are performed on geoms that don't belong to the same "leaf" space.

Thanks!

Alexandre Vaillancourt

[Oleh Derevenko]

> Could you tell me more a bit about this feature? Do you mean that geom-geom checks can be done within a single space in parallel with geom-geom checks in another space?

Yes, correct.

[Vaillancourt]

Okay, so if I activate the with-ou option, it will do this by default and so I should make sure my code handles this correctly, or is there something different than what is in the demos that should also be done (e.g. activate a parameter or something)?

Thanks!

Alexandre Vaillancourt

[Oleh Derevenko]

There is no example for this in demos. You need to do it on your own.

You have a number of potentially colliding geometries and for them you need to execute corresponding collision check calls which will send you respective collision callbacks resulting in potentially new collision candidates. 

You can organize these calls in several threads making sure no two threads are calling collision checks in the same space at the same time. For example, this can be organized as a work queue with collision pairs in the same space maked as work items dependent on each other's results. Then, threads can be choosing and execution individual indepndent chains of work items.

Oleh Derevenko

-- Skype with underscore

 

---

From: ode-...@googlegroups.com <ode-...@googlegroups.com> on behalf of Vaillancourt <alexandre.vai...@gmail.com>

Sent: Sunday, December 29, 2024 2:22
To: ode-users <ode-...@googlegroups.com>
Subject: Re: [ode-users] Calling `dCollide` from multiple threads, good or bad idea?

 

--
You received this message because you are subscribed to the Google Groups "ode-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ode-users+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ode-users/74520d7a-6a8d-4efc-badf-e552278c1f79n%40googlegroups.com.

[Oleh Derevenko]

You see, typically, such code is tightly integrated with the program's custom classes and it makes it hardly ever possible to separate it into an example.

Oleh Derevenko

-- Skype with underscore

 

---

From: 'Oleh Derevenko' via ode-users <ode-...@googlegroups.com>
Sent: Sunday, December 29, 2024 12:48
To: ode-...@googlegroups.com <ode-...@googlegroups.com>

To view this discussion visit https://groups.google.com/d/msgid/ode-users/AS4PR07MB88992EA9A23DE210B34F2A11DD082%40AS4PR07MB8899.eurprd07.prod.outlook.com.

[Vaillancourt]

Okay, thanks for the answers.

So when I mentioned "Do you mean that geom-geom checks can be done within a single space in parallel with geom-geom checks in another space?", do we imply that spaces are also geoms in terms of this approach? (I know spaces are a subclass of geom, just wondering if they're handled the same here.)

For instance, given the following hierarchy

GSpace

- SpaceA

-- GeomA

-- SpaceAA

--- GeomAA

--- GeomAA2

- SpaceB

-- GeomB

-- SpaceBB

--- GeomBB

--- GeomBB2

I could call in parallel

- dSpaceCollide(  SpaceA ) || dSpaceCollide(  SpaceB )

- dSpaceCollide2( GeomA, SpaceAA ) || dSpaceCollide2( GeomB, SpaceBB )

- dCollide( GeomAA, GeomAA2) || dCollide( GeomBB, GeomBB2 )

?

Thanks!

Alexandre Vaillancourt

[Oleh Derevenko]

Yes, spaces are representatives of geoms as well.

Moreover, I'm not 100% sure at this time (it was very long ago I looked at it last time) but, according to OOP principles, each object is isolated and independent from other objects. That is, a collision call at upper level should not interfere with calls at nested levels. So, all there 6 calls could probably be possible to be called in parallel together.

Oleh Derevenko

-- Skype with underscore

 

---

From: ode-...@googlegroups.com <ode-...@googlegroups.com> on behalf of Vaillancourt <alexandre.vai...@gmail.com>

Sent: Sunday, December 29, 2024 16:19

To: ode-users <ode-...@googlegroups.com>
Subject: Re: [ode-users] Calling `dCollide` from multiple threads, good or bad idea?

Okay, thanks for the answers.

So when I mentioned "Do you mean that geom-geom checks can be done within a single space in parallel with geom-geom checks in another space?", do we imply that spaces are also geoms in terms of this approach? (I know spaces are a subclass of geom, just wondering if they're handled the same here.)

For instance, given the following hierarchy

GSpace

- SpaceA

-- GeomA

-- SpaceAA

--- GeomAA

--- GeomAA2

- SpaceB

-- GeomB

-- SpaceBB

--- GeomBB

--- GeomBB2

I could call in parallel

- dSpaceCollide(  SpaceA ) || dSpaceCollide(  SpaceB )

- dSpaceCollide2( GeomA, SpaceAA ) || dSpaceCollide2( GeomB, SpaceBB )

- dCollide( GeomAA, GeomAA2) || dCollide( GeomBB, GeomBB2 )

?

[Oleh Derevenko]

 > Moreover, I'm not 100% sure at this time (it was very long ago I looked at it last time) but, according to OOP principles, each object is isolated and independent from other objects. That is, a collision call at upper level should not interfere with calls at nested levels. So, all there 6 calls could probably be possible to be called in parallel together.

But maybe no. Probably, geometry calculation at upper and for members of the upper-level space would interfere with the need to update geometry in that nested sub-space when it would be called for collision checks in parallel.
You need to check with the sources if you would want to do such uncommon things

--
You received this message because you are subscribed to the Google Groups "ode-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ode-users+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ode-users/AS4PR07MB88999AB324E6A18E83C5E202DD082%40AS4PR07MB8899.eurprd07.prod.outlook.com.