Page 1 of 1
quickstep integration improvements!
Posted: Wed Oct 10, 2007 2:38 pm
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
Re: quickstep integration improvements!
Posted: Wed Oct 10, 2007 5:36 pm
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
Re: quickstep integration improvements!
Posted: Wed Oct 10, 2007 5:52 pm
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
Re: quickstep integration improvements!
Posted: Wed Oct 10, 2007 5:56 pm
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
Re: quickstep integration improvements!
Posted: Wed Oct 10, 2007 6:11 pm
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.
Re: quickstep integration improvements!
Posted: Wed Oct 10, 2007 6:37 pm
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
Re: quickstep integration improvements!
Posted: Thu Oct 11, 2007 1:44 pm
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
Re: quickstep integration improvements!
Posted: Fri Oct 12, 2007 8:58 am
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
Re: quickstep integration improvements!
Posted: Fri Oct 12, 2007 11:25 am
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.
Re: quickstep integration improvements!
Posted: Fri Oct 12, 2007 4:01 pm
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