Parallel computing?

Discuss issues specific the Java port of Box2D
FrancescoITA
Posts: 12
Joined: Wed Jan 06, 2010 4:57 pm

Parallel computing?

Postby FrancescoITA » Mon Jan 11, 2010 3:47 pm

I was wondering how much box2d would benefit from parallel computing, especially after I ran into this http://code.google.com/p/javacl/. (click on the Particle Test Demo to see a web applet manage 1Million particles. You need a fairly new GPU). :shock:
Just wondering...

toucansam
Posts: 356
Joined: Mon Jun 08, 2009 12:21 pm
Contact:

Re: Parallel computing?

Postby toucansam » Sun Jan 17, 2010 1:14 am

The way this engine is set up, it would be a little bit tricky to turn it into a multi-thread machine. Sometime in the future a multithreaded version of JBox2d might be made, I know ewjordan was thinking about it, but nothing (that i know of) was ever tried.

short answer, I don't see box2d doing too much with parallel computing as it was built as a single threaded engine, and all that parallel computing would do is add a whole bunch of synchronization issues.

But definitely cool, and something to ponder about.....maybe one could split up the collision detection and the solver....or do something with having a thread specifically for island and contact point resolution...hmm

HughPH
Posts: 8
Joined: Thu Jul 20, 2017 7:19 am

Re: Parallel computing?

Postby HughPH » Thu Aug 10, 2017 7:48 am

7 & a half years later and I'm using LiquidFun and wondering the same thing. After a few thousand particles, everything starts to grind although my CPU usage is low (under 15% - so yes, that means I have an 8 (logical) core CPU and have some parallelisation in my non-Box2D code.)

I do wonder if some of the calculation could be offloaded to the GPU. Right now I just have one shader to turn particles into watery metaballs. There's plenty of spare resource there.

I realise LiquidFun is not Box2D, but it's my use case and it is based on Box2D.

LF, for each time step, calls a series of methods that each spin through all the particles. ComputeDepth for all particles, then UpdatePairsAndTriadsWithReactiveParticles for all particles, SolveForce for all particles, SolveViscous for all particles, and so forth.

The greatest issue with all of these is that if they're small (and some really are,) the cost of pushing the data to the GPU and pulling it back could be expensive because we have to do it many times.

Box2D itself has the opposite issue in that it's more coarse-grained - the Solve method on b2World has one huge loop that uses a great deal of data from all over the world. We could load that into a huge texture, but then you have to 'decode' it back out of the texture, and re-encode the results into another texture which then has to be parsed back in CPU land. That said, the pipe between GPU memory and main memory is fairly broad so maybe it would be a case of using a texture behind the b2BlockAllocator. Even then, that is a massive redesign and requires a lot of porting. Coding for the way Shader code runs requires a different mindset, too. It would be a not-insignificant challenge, although I imagine it could be a lot of fun for someone with the right mindset and enough spare time.


Return to “Java”



Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 1 guest