CPU multithreading is working!

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

Re: CPU multithreading is working!

Post by Granyte »

Alright so after fixing my issue with Bullet I found an issue when using the GIimpact mesh


It crash on this method btGimpactShape.h line 846

Code: Select all

virtual void getBulletTriangle(int prim_index,btTriangleShapeEx & triangle) const
	{
		m_primitive_manager.get_bullet_triangle(prim_index,triangle);
	}
lunkhound
Posts: 99
Joined: Thu Nov 21, 2013 8:57 pm

Re: CPU multithreading is working!

Post by lunkhound »

I haven't used the GImpact shapes before. I'll take a look and report back.
c6burns
Posts: 149
Joined: Fri May 24, 2013 6:08 am

Re: CPU multithreading is working!

Post by c6burns »

Granyte wrote:Alright so after fixing my issue with Bullet I found an issue when using the GIimpact mesh
Have you confirmed that issue is specific only to lunkhound's fork?
lunkhound
Posts: 99
Joined: Thu Nov 21, 2013 8:57 pm

Re: CPU multithreading is working!

Post by lunkhound »

I was able to replicate the issue. There were some un-threadsafe things going on with the GImpactMeshShapePart class.

Specifically the lockChildShapes and unlockChildShapes methods were being called from multiple threads on the same object in the narrowphase.

I pushed a change that leaves the original behavior alone unless you compile with the threadsafe option, in which case it just locks once in the constructor.
Understand -- these aren't thread-locks, they are just virtual functions called lock and unlock that don't seem all that useful.

Anyway that seemed to fix it for me.
Granyte
Posts: 77
Joined: Tue Dec 27, 2011 11:51 am

Re: CPU multithreading is working!

Post by Granyte »

The latest patch seem to have fixed it good work

Also when my simulation consist of only 10-12 rigid bodies isolated by huge distances (talking millions of units here) this seem about 10% slower but as soon as it gets crowded around one of these base island this version seem to take the upper hand again
i'm gonna test some more scenario soon good work
lunkhound
Posts: 99
Joined: Thu Nov 21, 2013 8:57 pm

Re: CPU multithreading is working!

Post by lunkhound »

Glad to hear that fixed it for you!

With only 10-12 bodies, and likely very few contacts and constraints there just isn't that much work to make it worth splitting up into separate tasks. The island manager will merge islands that have less than 32 bodies to keep the number of islands manageable when there are thousands of bodies (and each is an island).

For things like the narrowphase, if you are using the code from MultithreadedDemo, the "grain size" is set to 40. That means each task is going to do collision detection on 40 different overlapping pairs. If you have less than 40 pairs to work on, then it won't create any tasks and it will just do the work on the main thread. There is a certain amount of overhead to coordinating the threads, so the tasks need to be doing a certain amount of work to overcome this overhead.
So you can tweak the grain size to change the number of tasks that get generated and how much work each does.

So I'm not too surprised that it runs slower with just a handful of bodies in the simulation -- there isn't enough work to do anything in parallel. Which version of Bullet are you doing the comparison with?
Granyte
Posts: 77
Joined: Tue Dec 27, 2011 11:51 am

Re: CPU multithreading is working!

Post by Granyte »

with the one in your fork without threading included


I did not notice any significant speed difference when going from the latest trunk to your version when threading is not enabled

EDIT in this version is it possible to ray cast from multiple thread ?
lunkhound
Posts: 99
Joined: Thu Nov 21, 2013 8:57 pm

Re: CPU multithreading is working!

Post by lunkhound »

Granyte wrote:EDIT in this version is it possible to ray cast from multiple thread ?
Yes, I fixed a threadsafe issue (here) in the DbvtBroadphase rayTest. Raytests are used in createPredictiveContacts which runs in parallel now.

There may be (and probably are) more code paths that aren't threadsafe (like the GImpact one you reported). I'll try to fix any that get found (and reported here).
Granyte
Posts: 77
Joined: Tue Dec 27, 2011 11:51 am

Re: CPU multithreading is working!

Post by Granyte »

Very nice

I encountered an other issue with the Gimpact mesh where they can send the game in an infinite loop or something like it when two of those are colliding

it does not happen every time i'm trying to get a scenario that reproduce it every time
Berezovsky
Posts: 14
Joined: Tue Oct 14, 2014 9:32 pm

Re: CPU multithreading is working!

Post by Berezovsky »

I need to multithread several completely-independent simulations in the same program. (Not the same simulation. Independent ones).

Is this possible?
lunkhound
Posts: 99
Joined: Thu Nov 21, 2013 8:57 pm

Re: CPU multithreading is working!

Post by lunkhound »

Berezovsky wrote:I need to multithread several completely-independent simulations in the same program. (Not the same simulation. Independent ones).

Is this possible?
Well you could run them in separate processes, and that would surely work.

For running in the same process, I have doubts. If there is any code being used that reads and writes a static or global data structure, then it likely won't work. The dbvt broadphase ray-test was doing this, but that is now fixed in my fork. The MLCP solver is also doing it (but should be fixed soon). I would be (pleasantly) surprised if those were the only instances in Bullet of modifying static or global data!

If you try it I would love to know how it works out!
c6burns
Posts: 149
Joined: Fri May 24, 2013 6:08 am

Re: CPU multithreading is working!

Post by c6burns »

Berezovsky wrote:I need to multithread several completely-independent simulations in the same program. (Not the same simulation. Independent ones).

Is this possible?
This is the third thread in which you are asking the same question. Take it easy, man. Also in only 1 of the threads do you explain you are trying to multi-thread the entire demo application (including the OpenGL parts and window creation and everything). Just have some patience and await replies in your other threads.
Berezovsky
Posts: 14
Joined: Tue Oct 14, 2014 9:32 pm

Re: CPU multithreading is working!

Post by Berezovsky »

lunkhound wrote: Well you could run them in separate processes, and that would surely work.
Yep! I went ahead and wrote a dispatcher in python. It calls the bullet simulations as processes from the command line. It works like a charm.
Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: CPU multithreading is working!

Post by Basroil »

lunkhound wrote:
Berezovsky wrote:I need to multithread several completely-independent simulations in the same program. (Not the same simulation. Independent ones).

Is this possible?
For running in the same process, I have doubts. If there is any code being used that reads and writes a static or global data structure, then it likely won't work. The dbvt broadphase ray-test was doing this, but that is now fixed in my fork. The MLCP solver is also doing it (but should be fixed soon). I would be (pleasantly) surprised if those were the only instances in Bullet of modifying static or global data!

If you try it I would love to know how it works out!
I've been doing it for a bit now (optimization stuff on 8 cores, single process), and after the tweaks I described before it works without issues on both single and dual processor systems with 8 threads ( wish I had a dual processor 12 core HT system to test 48 threads, but my research budget was blown on motors that are $300/each...)
lunkhound
Posts: 99
Joined: Thu Nov 21, 2013 8:57 pm

Re: CPU multithreading is working!

Post by lunkhound »

Basroil wrote:
lunkhound wrote:
Berezovsky wrote:I need to multithread several completely-independent simulations in the same program. (Not the same simulation. Independent ones).

Is this possible?
For running in the same process, I have doubts. If there is any code being used that reads and writes a static or global data structure, then it likely won't work. The dbvt broadphase ray-test was doing this, but that is now fixed in my fork. The MLCP solver is also doing it (but should be fixed soon). I would be (pleasantly) surprised if those were the only instances in Bullet of modifying static or global data!

If you try it I would love to know how it works out!
I've been doing it for a bit now (optimization stuff on 8 cores, single process), and after the tweaks I described before it works without issues on both single and dual processor systems with 8 threads ( wish I had a dual processor 12 core HT system to test 48 threads, but my research budget was blown on motors that are $300/each...)
These tweaks you mention, are those the fixes for the MLCP solver to not use static data?
Post Reply