ARM Neon Support and Android x86

A place to discuss everything related to Newton Dynamics.

Moderators: Sascha Willems, walaber

Re: ARM Neon Support and Android x86

Postby Julio Jerez » Mon Oct 01, 2018 2:17 pm

should I with until there was one that build form more than one person?
Julio Jerez
Moderator
Moderator
 
Posts: 11039
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: ARM Neon Support and Android x86

Postby execomrt » Mon Oct 01, 2018 2:21 pm

I've downloaded the latest snapshot. It seemed that a lot of functions were renamed like CrossProduct3 to CrossProduct. I was using a snapshot from last week but I need to fix to the latest changes.
execomrt
 
Posts: 8
Joined: Fri Sep 21, 2018 8:41 am

Re: ARM Neon Support and Android x86

Postby Julio Jerez » Mon Oct 01, 2018 2:47 pm

yes, I am removing all of the legacy operations that operate on 3 elements.
the only one left is the DotProduct3, which is in progress.

the dgVector class start out from the dVector which is a vector3 class embedded in a vecor4 primarily,
therefore for many years it has two set of function, but in reality the vector 3 is quite inefficient since it has to mask the w component in each operation and the client of the class is in better position to decide when to do that. The change aren't many, since is basically removing functions.

the important one for ARM system are MulAdd and MulSub, which are new to the dgVector and is where cpu like arm and modern x86 get more floatps
Julio Jerez
Moderator
Moderator
 
Posts: 11039
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: ARM Neon Support and Android x86

Postby Dave Gravel » Mon Oct 01, 2018 3:36 pm

Ok, Like I have say my project already use neon and it is already actived.
I use it for my visual with glm math lib, I know it working because I can see the difference with and without neon active.
My newer devices seen to gain more from it, My old one is a bit slower but it seen to work too.

I have active neon with the same method for compile newton lib but I get multiple error for compile the neon change.
Surely it coming from last newton change.
I wait for test with updated files.
https://sites.google.com/site/orionx3d/neon2.png

Here I can build the libs under linux gcc with android toolchain or I can build it with visual studio 2017 and the android plugin.
I don't use clang because it cause problem for me with newton.
I have try many configuration but with clang I get strange crash with joint.
I have change for gcc4.9 under visual studio.
With gcc VS I use similar configuration that I use with linux android toolchain and all seen to work good for now.

I retry it again later, thanks.
You search a nice physics solution, if you can read this message you're at the good place :wink:
OrionX3D Projects & Demos:
https://www.facebook.com/dave.gravel1
http://orionx3d.googlepages.com/
https://www.youtube.com/user/EvadLevarg/videos
User avatar
Dave Gravel
 
Posts: 713
Joined: Sat Apr 01, 2006 9:31 pm
Location: Quebec in Canada.

Re: ARM Neon Support and Android x86

Postby execomrt » Tue Oct 02, 2018 1:16 pm

The new optimizations works best with ARM64 (fast dot product function in two instructions) or ARM with FMA supports (better precision for MulAdd). That's why it is better on newer ARM processors (you should try ARM64 for better boost, because it has also more Neon registers).

The patch also enable SSE on Android x86 and x64_x86 (was not enabled).

The crash might be an alignment problem ? if you can post the problem, anyway, you can disable ARM Neon on old compiler.
execomrt
 
Posts: 8
Joined: Fri Sep 21, 2018 8:41 am

Re: ARM Neon Support and Android x86

Postby Dave Gravel » Tue Oct 02, 2018 1:44 pm

I think it is about buffer allocation or something like this.
The crash is a segmentation fault when newton update the world and you have a joint in the scene.
If newton is not updated no error happen.
With clang something is not assigned correctly or something about buffer allocation go wrong.
Maybe it need a special processor flag or different memory alignment yes, I have try many configurations and nothing have work.
I can reproduce the same error if I call a null body.
Without joint in the scene all seen to work ok.
I can get it working for some secs by removing the stack-protection but it crash after some secs.

With gcc4.9 it work normally and pretty good.
I can use my multibody vehicle and other joints and more without problem.
https://www.youtube.com/watch?v=sKiOgV5Dw6A

I have currently test my project in a old sm-t530nu tablet, samsung s7 and s9+
I use my old samsung sm-t530nu tablet for test my projects I can see more about speed diff and the screen size help for test.

The s7 work pretty good and with the s9+ the result is very impressive about the speed.
I don't have try my others android devices because other models is similar to my 32bit arm model.

Do you have already get a newton scene working with joints by using clang3.8, 5.0 compiler ?
You search a nice physics solution, if you can read this message you're at the good place :wink:
OrionX3D Projects & Demos:
https://www.facebook.com/dave.gravel1
http://orionx3d.googlepages.com/
https://www.youtube.com/user/EvadLevarg/videos
User avatar
Dave Gravel
 
Posts: 713
Joined: Sat Apr 01, 2006 9:31 pm
Location: Quebec in Canada.

Re: ARM Neon Support and Android x86

Postby Julio Jerez » Tue Oct 02, 2018 2:38 pm

I now think is memory alignment, there are two class alignment

DG_MSC_VECTOR_ALIGMENT for visual studio
DG_GCC_VECTOR_ALIGMENT for GCC

we need to fin out the macro for class alignment with clang and change the define
Julio Jerez
Moderator
Moderator
 
Posts: 11039
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: ARM Neon Support and Android x86

Postby execomrt » Fri Oct 05, 2018 1:19 pm

Newton uses 'new' for allocator (see dNewtonJoint). But some compilers (old ones) doesn't returns page aligned (16 bytes) memory space.

You could fix by redefining globally the new / delete
void * operator new(size_t size)
{
return memalign , posix_memalign ....
}

This would fix your problem.
New compiler like clang knows the required alignment.
execomrt
 
Posts: 8
Joined: Fri Sep 21, 2018 8:41 am

Re: ARM Neon Support and Android x86

Postby Dave Gravel » Fri Oct 05, 2018 1:36 pm

Thanks for the infos, I can try tonight and see if my demo run with the joints + clang.
I currently get the hexapode working with gcc, It seen to use the joint and the engine intensively.
https://www.youtube.com/watch?v=dRADAxC3Ivs
You search a nice physics solution, if you can read this message you're at the good place :wink:
OrionX3D Projects & Demos:
https://www.facebook.com/dave.gravel1
http://orionx3d.googlepages.com/
https://www.youtube.com/user/EvadLevarg/videos
User avatar
Dave Gravel
 
Posts: 713
Joined: Sat Apr 01, 2006 9:31 pm
Location: Quebec in Canada.

Re: ARM Neon Support and Android x86

Postby Dave Gravel » Fri Oct 05, 2018 8:11 pm

Hum, I'm not so sure about this part I prefer let's it to Julio or a more experimented user.
It use dNewtonAlloc and dgMemory and a lot of things is in relation with it.
The strange thing is the collision and body use it too, If i'm not wrong.
The simulation with only collision and body seen to run ok without problem.
The crash happen only when I add a joint and when this joint is updated by newton.
Maybe it have something to do with the memory alignment like Julio saying before.

Currently for me use gcc is not so critical because all work ok with good speed,
Many people talk about gcc is slower or it need some features.

I use gcc in linux and in windows I have test my applications compiled from clang and gcc.
The applications compiled with gcc seen to run better on my tests.

I don't talk about all version clang and gcc, I have only test with clang3.8, 5.0 and gcc 4.9
In linux I don't remember the exact version but it is around 4.x
Maybe with a different code implementation the app compiled with clang can run better no idea.

Thanks for have share the info, I wait later when Julio get time for look at this.

Edited:
Julio I don't know if it can help to find the problem.
When I try to use the custom joint with clang It crashing, I have try with socketball, hinge, and the hexapode construction.
If I use my multibody vehicle joint the application don't crash and it seen to work normally.
I'm not so sure about what cause the problem with other joints because my joint is inherited from the customjoint.
I'm going to try all joint type one by one and see if a other type working too.
You search a nice physics solution, if you can read this message you're at the good place :wink:
OrionX3D Projects & Demos:
https://www.facebook.com/dave.gravel1
http://orionx3d.googlepages.com/
https://www.youtube.com/user/EvadLevarg/videos
User avatar
Dave Gravel
 
Posts: 713
Joined: Sat Apr 01, 2006 9:31 pm
Location: Quebec in Canada.

Re: ARM Neon Support and Android x86

Postby Dave Gravel » Sat Oct 06, 2018 12:31 am

Hi Julio:
I have make more tests about the Clang error with joint.

The error happen when I set the Joint.SetSolverModel(0);
If I use solver 1 or 2 the application don't crash.

With gcc I can set solver 0 without problem.
You search a nice physics solution, if you can read this message you're at the good place :wink:
OrionX3D Projects & Demos:
https://www.facebook.com/dave.gravel1
http://orionx3d.googlepages.com/
https://www.youtube.com/user/EvadLevarg/videos
User avatar
Dave Gravel
 
Posts: 713
Joined: Sat Apr 01, 2006 9:31 pm
Location: Quebec in Canada.

Re: ARM Neon Support and Android x86

Postby Dave Gravel » Sat Oct 06, 2018 1:12 am

Me again :)

Inside void dgWorld::UpdateSkeletons()

Code: Select all
// For Clang crash : With this part of code commented out.
// It remove the crash when the solver is set to 0,
// And the joint seen to work ok.

/*if (constraint->IsBilateral() && (constraint->m_solverModel < 2) && (constraint->m_dynamicsLru != lru)) {
    constraint->m_dynamicsLru = lru;
    jointList[jointCount] = (dgBilateralConstraint*)constraint;
    jointCount++;
}*/


With this code commented out my cradle demo work it use hinge,socketball,vectorupjoint, but when I test the hexapode demo it crash again.
Something is strange with clang and the solver.
You search a nice physics solution, if you can read this message you're at the good place :wink:
OrionX3D Projects & Demos:
https://www.facebook.com/dave.gravel1
http://orionx3d.googlepages.com/
https://www.youtube.com/user/EvadLevarg/videos
User avatar
Dave Gravel
 
Posts: 713
Joined: Sat Apr 01, 2006 9:31 pm
Location: Quebec in Canada.

Re: ARM Neon Support and Android x86

Postby JernejL » Thu Aug 22, 2019 11:16 am

execomrt wrote:Here the new patch (tested against latest snapshot from 1st October)
- Changed DotProduct4 to DotProduct, and CrossProduct
- Added MulAdd/MulSub (two version, with FMA or regular, FMA has more precision).
- Removed dgVectorSSE.h (doing an include).


ATTACHMENTS
ARM PATCH 2.zip
(22.55 KiB) Downloaded 74 times

download/file.php?id=574

I think changes from his attachment were not yet merged in.

There is also the issue of _MM_SET_FLUSH_ZERO_MODE here ( https://github.com/MADEAPPS/newtondynamics/issues/121 ) that still breaks ARM platform.

I suggest changing that to:

Code: Select all
      #if (defined(__arm__) || defined(__aarch64__))
         // this is not ok for arm - call clearfp?
      #else
         _MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON);
      #endif


Could arm improvements be merged?
Help improving the Newton Game Dynamics WIKI
User avatar
JernejL
 
Posts: 1492
Joined: Mon Dec 06, 2004 2:00 pm
Location: Slovenia

Previous

Return to General Discussion

Who is online

Users browsing this forum: No registered users and 5 guests