Page 3 of 10

Re: CPU multithreading is working!

Posted: Tue Dec 23, 2014 12:29 pm
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);
	}

Re: CPU multithreading is working!

Posted: Tue Dec 23, 2014 7:51 pm
by lunkhound
I haven't used the GImpact shapes before. I'll take a look and report back.

Re: CPU multithreading is working!

Posted: Wed Dec 24, 2014 5:22 am
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?

Re: CPU multithreading is working!

Posted: Wed Dec 24, 2014 8:45 am
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.

Re: CPU multithreading is working!

Posted: Wed Dec 24, 2014 10:07 am
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

Re: CPU multithreading is working!

Posted: Wed Dec 24, 2014 6:38 pm
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?

Re: CPU multithreading is working!

Posted: Fri Dec 26, 2014 7:13 pm
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 ?

Re: CPU multithreading is working!

Posted: Fri Dec 26, 2014 8:12 pm
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).

Re: CPU multithreading is working!

Posted: Sat Dec 27, 2014 5:56 pm
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

Re: CPU multithreading is working!

Posted: Sun Dec 28, 2014 3:41 am
by Berezovsky
I need to multithread several completely-independent simulations in the same program. (Not the same simulation. Independent ones).

Is this possible?

Re: CPU multithreading is working!

Posted: Sun Dec 28, 2014 8:54 am
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!

Re: CPU multithreading is working!

Posted: Sun Dec 28, 2014 9:28 am
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.

Re: CPU multithreading is working!

Posted: Tue Dec 30, 2014 6:25 am
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.

Re: CPU multithreading is working!

Posted: Tue Jan 06, 2015 2:54 am
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...)

Re: CPU multithreading is working!

Posted: Thu Jan 08, 2015 3:33 am
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?