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
quickstep integration improvements!
-
- Posts: 22
- Joined: Sat Sep 24, 2005 10:01 pm
quickstep integration improvements!
Last edited by Remotion on Thu Oct 11, 2007 4:36 pm, edited 1 time in total.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: quickstep integration improvements!
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
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
-
- Posts: 22
- Joined: Sat Sep 24, 2005 10:01 pm
Re: quickstep integration improvements!
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.
EDIT: btPoolAllocator need to support memory growing also to be more safe!
regards,
Remo
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.
Yes it would be great!It would be great if we can cover all the various ODE constraints, limits and motors for this quickstep solver integration.
EDIT: btPoolAllocator need to support memory growing also to be more safe!
regards,
Remo
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: quickstep integration improvements!
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
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
-
- Posts: 22
- Joined: Sat Sep 24, 2005 10:01 pm
Re: quickstep integration improvements!
Thanks btStackAlloc seems to be more suitable for this purpose.
Just wanted to compare default SI solver with quickstep and found this problems.
Sorry probably not, but if then I will post it here.Do you think you have time to look into support for other constraints/joints/motors for quickstep?
Just wanted to compare default SI solver with quickstep and found this problems.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: quickstep integration improvements!
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:
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
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);
Thanks,
Erwin
-
- Posts: 22
- Joined: Sat Sep 24, 2005 10:01 pm
Re: quickstep integration improvements!
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!
regards,
Remotion
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);
}
};
Remotion
You do not have the required permissions to view the files attached to this post.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: quickstep integration improvements!
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
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
-
- Posts: 22
- Joined: Sat Sep 24, 2005 10:01 pm
Re: quickstep integration improvements!
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?
Here are also some other changes.
I have replaced float in SolveInternal1() with btScalar now.
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
I have replaced float in SolveInternal1() with btScalar now.
You do not have the required permissions to view the files attached to this post.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: quickstep integration improvements!
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
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