quickstep integration improvements!

Post Reply
Remotion
Posts: 22
Joined: Sat Sep 24, 2005 10:01 pm

quickstep integration improvements!

Post by Remotion »

Hello to all.

If you enable COMPARE_WITH_QUICKSTEP in appCcdPhysicsDemo and run it then you will get stack overflow Error!
The main problem is inside OdeConstraintSolver::solveGroup() function with wastes a lot of memory allocating huge static arrays.

I have modified the code to use btAlignedObjectArray, of course it is still not fully optimal but work now.

regards,
Remotion
Last edited by Remotion on Thu Oct 11, 2007 4:36 pm, edited 1 time in total.
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: quickstep integration improvements!

Post by Erwin Coumans »

Hi,

Thanks a lot for the improvements. I'll verify the contribution on various platforms and check it into Bullet's repository.

It would be great if we can cover all the various ODE constraints, limits and motors for this quickstep solver integration.

Thanks,
Erwin
Remotion
Posts: 22
Joined: Sat Sep 24, 2005 10:01 pm

Re: quickstep integration improvements!

Post by Remotion »

Hello,

Unfortunately there is still a problem with ALLOCA() in SorLcp.cpp witch can cause stack overflow if too many contacts are produced.
Probably it must be replaced with btPoolAllocator.
I will post code if this will be done.
It would be great if we can cover all the various ODE constraints, limits and motors for this quickstep solver integration.
Yes it would be great!

EDIT: btPoolAllocator need to support memory growing also to be more safe!

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

Re: quickstep integration improvements!

Post by Erwin Coumans »

You can consider using the btStackAllocator, which is available. The maximum stack size can be chosen by the user, when initializing the dynamics/collision world.

For better flexibility, the stackallocator will be moved to the btDefaultCollisionConfiguration.

Do you think you have time to look into support for other constraints/joints/motors for quickstep?
Thanks,
Erwin
Remotion
Posts: 22
Joined: Sat Sep 24, 2005 10:01 pm

Re: quickstep integration improvements!

Post by Remotion »

Thanks btStackAlloc seems to be more suitable for this purpose.
Do you think you have time to look into support for other constraints/joints/motors for quickstep?
Sorry probably not, but if then I will post it here.
Just wanted to compare default SI solver with quickstep and found this problems.
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: quickstep integration improvements!

Post by Erwin Coumans »

If you add support for the btStackAllocator, can you provide me with an updated version?
You can best re-use the existing stack allocator, here is some sample snippet how to use this:

Code: Select all

btBlock*                                        sablock;     
sablock = stackAlloc->beginBlock();

int memNeeded = numBytes;
if (memNeeded < stackAlloc->getAvailableMemory())
{
    void* memory = stackAlloc->allocate(memNeeded);
///do something useful with this memory
} else
{
//out of memory, either report an error or use the heap (btAlignedAlloc/btAlignedFree)
}

//endBlock releases the stack memory allocated during this 'block'.
stackAlloc->endBlock(sablock);
By the way, Bullet gets some improvements for both SI solver and better performance for collision detection (hashed pair caching) for next version.

Thanks,
Erwin
Remotion
Posts: 22
Joined: Sat Sep 24, 2005 10:01 pm

Re: quickstep integration improvements!

Post by Remotion »

Yes here is it with btStackAllocator and some other improvements.
It seems to work well in my test now.

I am also using this class to make beginBlock() , endBlock() more safe!

Code: Select all

class AutoBlockSa //Remotion: 10.10.2007
{
	btStackAlloc* stackAlloc;
	btBlock*	  saBlock;
public:
	AutoBlockSa(btStackAlloc* stackAlloc_)
	{
		stackAlloc = stackAlloc_;
		saBlock = stackAlloc->beginBlock();
	}
	~AutoBlockSa()
	{
		stackAlloc->endBlock(saBlock);
	}
};
regards,
Remotion
Attachments
Quickstep_Mod_Remotion_11Oct07.zip
(26.58 KiB) Downloaded 446 times
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: quickstep integration improvements!

Post by Erwin Coumans »

Thanks, it has been included in Bullet-2.63-RC1, please check it out here:

http://www.bulletphysics.com/Bullet/php ... =18&t=1567

I had to comment-out some SSE snippet, because it doesn't compile in double-precision mode. Can you add some #ifdef BT_USE_DOUBLE_PRECISION?

Thanks,
Erwin
Remotion
Posts: 22
Joined: Sat Sep 24, 2005 10:01 pm

Re: quickstep integration improvements!

Post by Remotion »

Yes of course.
This should working now.

SSE must work on Win32, Win64, Intel Mac and Linux (Intel CPU).
Can someone please test this on Linux?

Code: Select all

/// This macros are for MSVC and XCode compilers. Remotion.
#if  _MSC_VER   //Visual Studio Win32, Win64
	#include <xmmintrin.h> // SSE
	#include <emmintrin.h> // SSE2	
	#include <intrin.h>	   // SSE3
	
	#if defined(BT_USE_DOUBLE_PRECISION)
		#define __USE_DOUBLE_SSE__
	#else
		#define __USE_SSE__
	#endif
#elif  __GNUC__  // XCode GCC
	#if defined(__ppc__) || defined(__ppc64__) // Mac PPC
		///PPC or PPC64 Mac no SSE support
	#elif defined(__i386__)	// Intel Mac with SSE support 
		#include <xmmintrin.h> // SSE
		#include <emmintrin.h> // SSE2	
		#include <pmmintrin.h> // SSE3

		#if defined(BT_USE_DOUBLE_PRECISION)
			#define __USE_DOUBLE_SSE__
		#else
			#define __USE_SSE__
		#endif
	#endif
	#include <string.h>
#endif
Here are also some other changes.
I have replaced float in SolveInternal1() with btScalar now.
Attachments
Quickstep_Mod_Remotion_12Oct07.zip
(12.76 KiB) Downloaded 454 times
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: quickstep integration improvements!

Post by Erwin Coumans »

Hi,

It would be preferable to keep the Extras/quickstep solver as close the original ODE code as possible, except for bugfixes.

If you want SSE/SIMD, preferably we re-implement the quickstep solver entirely using Vector Math library (see Extras/vectormath), which uses SSE. And then we can add as many optimizations in that SSEquickstep as possible. This re-implemented SSEquickstep would be under the ZLib license, and native part of Bullet (not an Extra).

Then at startup, the simulation can create a SSEquickstep if the SIMD/SSE capabilities are available, and otherwise create another constraint solver.

Are you interested in such project?
Thanks,
Erwin
Post Reply