CPU multithreading is working!

Tinos
Posts: 10
Joined: Thu Jul 23, 2015 10:29 pm

Re: CPU multithreading is working!

Post by Tinos » Mon Jul 27, 2015 1:41 pm

lunkhound wrote:Thanks for those fixes!

I haven't merged the determinism one yet because I want to see what the performance implications are. I'll have a look at it later.
You're welcome!

During my tests there was close to no difference in performance, but your mileage may vary.
As for the other fix, there are still two const_casts in there that aren't needed. I don't remember why I added those in the first place, but I'm sure I needed a non const reference for some reason during testing.

Granyte
Posts: 77
Joined: Tue Dec 27, 2011 11:51 am

Re: CPU multithreading is working!

Post by Granyte » Sat Aug 22, 2015 5:16 pm

So did the kinematic get fixed?

benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

Re: CPU multithreading is working!

Post by benelot » Mon Aug 24, 2015 10:10 am

Hello guys,

I see that you could get Bullet to run with multithreading :) I thought about this some time ago because the GPU pipeline is not ready yet. So what I would like to ask is if it is possible to merge the multithreading abilities that lunkhound added to his bullet version into the original bullet3 repository? I think that would be an interesting feature for Bullet3 as long as the GPU pipeline is not working yet.

Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: CPU multithreading is working!

Post by Basroil » Tue Aug 25, 2015 3:08 am

benelot wrote:Hello guys,

I see that you could get Bullet to run with multithreading :) I thought about this some time ago because the GPU pipeline is not ready yet. So what I would like to ask is if it is possible to merge the multithreading abilities that lunkhound added to his bullet version into the original bullet3 repository? I think that would be an interesting feature for Bullet3 as long as the GPU pipeline is not working yet.
Too many unknowns on how it'll affect others using their own forks. For my own use, the full implementation will break my project (well, my primary one at least) into a million pieces. Just fork off of lunkhound's fork and you'll be fine :wink:

lunkhound
Posts: 99
Joined: Thu Nov 21, 2013 8:57 pm

Re: CPU multithreading is working!

Post by lunkhound » Tue Aug 25, 2015 10:03 pm

Granyte wrote:So did the kinematic get fixed?
The version with the fix for kinematic objects is here: https://github.com/lunkhound/bullet3/tree/kinematic-fix

I have kept that change in a separate branch because it likely causes trouble for the featherstone multi-body point-to-point constraint. The MultiBody dynamics world isn't threadable anyway, so it's no loss if you want to use threads.

nickak2003
Posts: 7
Joined: Thu Mar 04, 2010 10:35 pm

Re: CPU multithreading is working!

Post by nickak2003 » Fri Jan 01, 2016 1:14 am

I have just started using bullet. Is this thread related to the master's multithreaded examples?

kermado
Posts: 20
Joined: Tue Jan 12, 2016 11:20 am

Re: CPU multithreading is working!

Post by kermado » Wed Aug 10, 2016 1:34 pm

I don't know if this project is active anymore, but I sometimes get crashes when using constraints that can be constrained against the world. In such cases, Bullet actually constrains the rigid body against what it calls a "fixed body" - see btTypedConstraint::getFixedBody(). The fixed body does not appear to get added to the world and so m_uniqueId is uninitialized.

lunkhound
Posts: 99
Joined: Thu Nov 21, 2013 8:57 pm

Re: CPU multithreading is working!

Post by lunkhound » Wed Sep 28, 2016 12:11 am

kermado wrote:I don't know if this project is active anymore, but I sometimes get crashes when using constraints that can be constrained against the world. In such cases, Bullet actually constrains the rigid body against what it calls a "fixed body" - see btTypedConstraint::getFixedBody(). The fixed body does not appear to get added to the world and so m_uniqueId is uninitialized.
Thanks for reporting that. I've added a fix for that case.

https://github.com/lunkhound/bullet3/tree/kinematic-fix

lunkhound
Posts: 99
Joined: Thu Nov 21, 2013 8:57 pm

Re: CPU multithreading is working!

Post by lunkhound » Sun Oct 16, 2016 3:14 am

I have updated my fork with a new branch based on the latest bullet code (2.85 as of this writing). This new branch is a complete refactor of the previous changes with the goal of minimizing changes to core bullet classes so that merging changes from upstream is easier. This new branch incorporates all of the fixes from the "kinematic-fix" branch.

https://github.com/lunkhound/bullet3/tree/thread-work4

A few additions in the latest:
  • - Faster raycasts. The previous version introduced a dynamic allocation with every raycast (which is bad for performance) in order to make it threadsafe, that is now fixed so multithreaded raycasts should be the same performance as original bullet
    - The benchmarks app in the example browser can now be run multithreaded (press 'm' key to toggle between multithreaded dynamics world and normal). This includes:
    • - "benchmarks/3000 boxes"
      - "benchmarks/1000 stack"
      - "benchmarks/ragdolls"
      - "benchmarks/convex stack"
      - "benchmarks/prim vs mesh"
      - "benchmarks/convex vs mesh"
      - "benchmarks/raycast"
    - The raycast example (part of benchmark demo) has been modified to do raycasts in parallel
New classes added:
  • - btSimulationIslandManagerMt-- new subclass of btSimulationIslandManager. The original simulation island manager class is untouched and all multithreading changes are now contained in this new class.

    - btDiscreteDynamicsWorldMt-- new subclass of btDiscreteDynamicsWorld containing multithreading changes. The original class has a few minor changes to internal functions but is functionally unchanged.
By encapsulating the changes in subclasses, it should be much easier to merge in upstream changes going forward.

Notes for converting from previous multithreading to thread-work4 branch:
  • Replace references to btSimulationIslandManager with the "Mt" version
    Replace references to btDiscreteDynamicsWorld with the "Mt" version
    In your DynamicsWorld class, if you've overridden createPredictiveContacts(), add a call to releasePredictiveContacts() at the start of it
I think that's about it.

[edited to remove references to btSequentialImpulseConstraintSolverMt which was dropped from the latest]
Last edited by lunkhound on Sun Oct 30, 2016 10:51 pm, edited 2 times in total.

Mako_energy02
Posts: 171
Joined: Sun Jan 17, 2010 4:47 am

Re: CPU multithreading is working!

Post by Mako_energy02 » Mon Oct 17, 2016 7:21 pm

Any chance of a pull request to the main repo with the refactored code? I see the old request on the Bullet repo as failing to build, but if this build compiles/works and the actual changes are smaller I don't understand maintaining your own repo for this.

lunkhound
Posts: 99
Joined: Thu Nov 21, 2013 8:57 pm

Re: CPU multithreading is working!

Post by lunkhound » Tue Oct 18, 2016 2:40 am

Mako_energy02 wrote:Any chance of a pull request to the main repo with the refactored code? I see the old request on the Bullet repo as failing to build, but if this build compiles/works and the actual changes are smaller I don't understand maintaining your own repo for this.
Possibly. The old pull request is not going to be accepted, the only reason it is still open is to allow people to discover this fork, and the fact that it has some useful commentary. I'm not sure that the reasons Erwin had for not accepting the existing pull request have been addressed in this latest branch. In that case I don't want to clutter up his repo with multiple pull requests for the same thing. I think the best thing to do is to merge these latest changes into the branch of the existing PR. That should update the pull request.

User avatar
Erwin Coumans
Site Admin
Posts: 4178
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: CPU multithreading is working!

Post by Erwin Coumans » Tue Oct 18, 2016 5:12 am

please create a new fresh pull request, I consider a merge. Thanks for the work!

lunkhound
Posts: 99
Joined: Thu Nov 21, 2013 8:57 pm

Re: CPU multithreading is working!

Post by lunkhound » Tue Oct 18, 2016 5:37 am

Erwin Coumans wrote:please create a new fresh pull request, I consider a merge. Thanks for the work!
OK, will do. I just need to do a bit more testing on it first.

lunkhound
Posts: 99
Joined: Thu Nov 21, 2013 8:57 pm

Re: CPU multithreading is working!

Post by lunkhound » Sun Oct 30, 2016 10:33 pm

OK, I created a new pull request:
https://github.com/bulletphysics/bullet3/pull/847

I used a virtual machine to test it on Ubuntu/Cmake/GCC. So that configuration should be working now.

I made some changes to the example browser so it's more user-friendly (for the multi-threading part).
Once it is compiled to be multithreaded, the demos which support multithreading have a button to switch into multithreading mode. You then have to restart that demo by double-clicking, at which point various other buttons and a slider widget will appear, allowing you to change between the various available threading APIs and the number of threads to use. Also there is a button to toggle the display of basic profiling info.

All of the actual multithreading stuff was moved into examples/CommonInterfaces/CommonRigidBodyBase.cpp so that it could be shared among the other demos.

User avatar
Erwin Coumans
Site Admin
Posts: 4178
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: CPU multithreading is working!

Post by Erwin Coumans » Thu Nov 03, 2016 4:15 pm

Thanks for all the work and the community discussion related to this. I accepted and merged the latest version of lurkhound here:
https://github.com/bulletphysics/bullet3/pull/847

I reviewed the files and the single-threaded version seems to still work fine, need to do some more tests on the multithreaded parts,
and may re-organize the files in 'CommonInterfaces' later.

Also, it would be nice to support multithreading of a single island in the future, as used in the old (removed) BulletMultiThreading, and in Bullet3 OpenCL.
It uses graph coloring to split batches of constraints that can be solved in parallel. Then at each iterations, the results are merged.

Thanks!

Post Reply