Multithreaded Overlapping Pair Processing/OpenMP?

[GoogleCodeExporter]

Hi,

We have been working on a multithreaded version of 
btOverlappingPairCache::processAllOverlappingPairs, 
primarily to accelerate processing of scenes with 
lots of compound objects.

In order to avoid lots of intrusive code, we based 
the implementation on OpenMP. So while a few changes 
outside of btOverlappingPairCache were necessary to 
avoid data races, most of the code is limited to 
pragmas. 

Before submitting a patch for review, I was just
wondering if OpenMP was even acceptable in the 
code base.

Thanks,
Peter  

Original issue reported on code.google.com by peter.me...@gmail.com on 13 Jun 2011 at 4:10

[GoogleCodeExporter]

That would be very interesting to test !

Do you use bullet as a standalone or as a plugin ?
We're getting some trouble with openMP and maya at the moment on another tool...

if you can post a patch here i'd be more than happy to try it out ! :)

Original comment by majestik...@gmail.com on 14 Jun 2011 at 2:19

[GoogleCodeExporter]

If it is not too intrusive we could add it, behind a #define.
Can you share a patch?

Have you checked out this issue?
http://code.google.com/p/bullet/source/browse/#svn%2Fbranches%2FStackAllocation

Is also deals with memory handling to allow parallel collision dispatch.

Original comment by erwin.coumans on 14 Jun 2011 at 6:37

[GoogleCodeExporter]

Attached the patch relative to 2.78.

The majority of the changes are in OverlappingPairCache, where
we reorder the overlapping pairs to avoid concurrent updates of 
the same objects. 

The other changes are mainly critical sections to avoid race 
conditions.

I just realized that including of omp.h should be guarded by a 
test for OPENMP_ to make the code compile without OpenMP. Will
do that in the next version of the patch.

Also, thanks for the pointer to the stack allocation branch. This 
could certainly help to reduce the number critical sections we need.

Anyway, let me know if there are any issues or if you have any suggestions
on how to extract more concurrency.

Thanks!
Peter

Original comment by peter.me...@gmail.com on 16 Jun 2011 at 3:27

Attachments:

• bullet-omp-patch.tar.gz

[GoogleCodeExporter]

Hi all, 

Just curious, was anybody able to get this patch to work in Bullet? 
Or if not, please let me know if there was a major problem and we'll
try to address it.

Thanks,
Peter

Original comment by peter.me...@gmail.com on 16 Sep 2011 at 8:35

[GoogleCodeExporter]

I haven't tried it yet. We have been very busy doing research and development 
for GPU acceleration, using OpenCL.

See https://github.com/erwincoumans/experiments/downloads and
http://www.youtube.com/erwincoumans

I hope to find some time after GDC to check out your work!

Original comment by erwin.coumans on 29 Feb 2012 at 5:34

[GoogleCodeExporter]

Thanks for the update Erwin. Do you have any more information about your OpenCL 
work posted somewhere? Initially when we had investigated the GPU solvers they 
did not generally work for our use of Bullet. Has they ability to generally use 
the GPU for Bullet simulations changed?

Original comment by mc...@iastate.edu on 29 Feb 2012 at 2:15

[GoogleCodeExporter]

I had a look at the patch, but the usage of STL (list/map) is a no-go for 
Bullet. Bullet is not using STL (or boost etc), but only has a vector 
(btAlignedObjectArray) and hash map (btHashMap) as container class.

Still, someone out there might want to try it out.

I make sure to have all this fixed for Bullet 3.x anyway. Thanks for the patch!

(in case someone rewrites it without STL, we can reconsider applying it)

Original comment by erwin.coumans on 1 Mar 2012 at 5:15

• Changed state: WontFix