How to build on multiple platforms

[pHySiQuE]

Building Newton on platforms other than Windows is perfectly doable, but takes a little extra work. Here's how.

(Since Julio has incorporated these changes into the source, you can disregard the following section):

First, you have to make some small changes to "core/dgTypes.h".

Find this code:

Code: Select all

#if !(defined (__USE_DOUBLE_PRECISION__) || defined (__ppc__))
   #define DG_BUILD_SIMD_CODE
#endif

Replace it with this:

Code: Select all

#if !(defined (__USE_DOUBLE_PRECISION__) || defined (__ppc__) || defined (ANDROID) || defined (IOS))
    #define DG_BUILD_SIMD_CODE
#endif

Find this code:

Code: Select all

#ifdef _POSIX_VER
   #include <unistd.h>
   #include <assert.h>
   // using SSE2
   extern "C"
   {
      // for SSE3 and up
      //   #include <pmmintrin.h>
      //   #include <immintrin.h>   
      //   #include <smmintrin.h>
      #include <emmintrin.h>
      #include <mmintrin.h>
   }
#endif

Replace it with this:

Code: Select all

#ifdef _POSIX_VER
   #include <unistd.h>
    #include <assert.h>
    #ifdef DG_BUILD_SIMD_CODE
   // using SSE2
   extern "C"
   {
      // for SSE3 and up
      //   #include <pmmintrin.h>
      //   #include <immintrin.h>   
      //   #include <smmintrin.h>
      #include <emmintrin.h>
      #include <mmintrin.h>
   }
    #endif
#endif

==BEGIN HERE==

Once you have made those changes, it's just a matter of defining the right preprocessor directives for each platform:

OSX
_MAC_VER
_MAC_VER_64
_POSIX_VER
_POSIX_VER_64
DG_THREAD_EMULATION (required as of now, or your application will stop in the NewtonUpdate() function)
_NEWTON_USE_LIB
_NEWTON_STATIC_LIB

iOS
_MAC_VER
_MAC_VER_64
_POSIX_VER
_POSIX_VER_64
DG_THREAD_EMULATION
_NEWTON_USE_LIB
_NEWTON_STATIC_LIB
IOS

Android
_POSIX_VER
_POSIX_VER_64
DG_THREAD_EMULATION
_NEWTON_USE_LIB
_NEWTON_STATIC_LIB
(ANDROID is automatically defined)

Windows
PTW32_STATIC_LIB
DG_USE_NORMAL_PRIORITY_THREAD
_NEWTON_USE_LIB
_NEWTON_STATIC_LIB

Add all Newton .cpp files in the "core", "meshutil", "newton", and "physics" folders to your project, except the file "dgVehicleConstraint.cpp". Add header search paths for each of the four subdirectories, and you're ready to go!

Windows Only
On Windows, there is one extra step. You also need to include the pthreads library, found in "packages/thirdparty/pthreads.2".
-Add "pthreads.c" to your project. You don't need to add any of the other .c files.
-Add the header include directory "packages/thirdparty/pthreads.2".

[Julio Jerez]

awesome, I added thoses change to the archive now.
Thnak you

[JoeJ]

Great, thx!

[carli2]

Wouldn't it be better to check for the CPU target?
There is also android for x86.

(offtopic: And why isn't there a fake emulation of the SSE intrinsics for non-SSE platforms or older SSE versions?)

[Julio Jerez]

check for cpu target is not as usuful as check for plattfoms. The only platform for whic that make sence was the OS10 on teh elrlei day when they supported G4, G5 and x86
but Apple discontinue all motorolas CPU.

as for sse , the fake emulation would be the c code.
it will be nice to have a ARM SSE, and I beleive there was one but it was for core 200.
To tell you the truth I am thinking to go the other way, Eliminate all intrisic code, after I have the OpenCL up an running.
intrisic code is becoming to much hardware specific with all the variances: SSE, SSE2, SSE3, AVX, ARM, etc

beside SSE code is only beneficial when usin Visual strution compiler in 32 bit,
VS in 64 bit and GCC use scaler and Vector SSE to generate code for C++ and thet result is within 2% to 5% of hand written intrisics code.

[pHySiQuE]

check for cpu target is not as usuful as check for plattfoms. The only platform for whic that make sence was the OS10 on teh elrlei day when they supported G4, G5 and x86
but Apple discontinue all motorolas CPU.

as for sse , the fake emulation would be the c code.
it will be nice to have a ARM SSE, and I beleive there was one but it was for core 200.
To tell you the truth I am thinking to go the other way, Eliminate all intrisic code, after I have the OpenCL up an running.
intrisic code is becoming to much hardware specific with all the variances: SSE, SSE2, SSE3, AVX, ARM, etc

beside SSE code is only beneficial when usin Visual strution compiler in 32 bit,
VS in 64 bit and GCC use scaler and Vector SSE to generate code for C++ and thet result is within 2% to 5% of hand written intrisics code.

Now you're thinking like a businessman. (I mean that in a good way.)

[Julio Jerez]

wow, the preliminary result of opencl are better than my best expectation

here is my hello world test programe

Code: Select all

__kernel void __attribute__((vec_type_hint(float8))) dgHelloOpenCl (__global const float8* const A, __global const float8* const B, __global float8* const out)
{
   int idx = get_global_id (0);
   out[idx] = A[idx] + B[idx];
}

this is the assemply compiled output in my icore 7

Code: Select all

   .def    _dgHelloOpenCl;
   .scl   2;
   .type   512;
   .endef
   .text
   .globl   _dgHelloOpenCl
   .align   16, 0x90
_dgHelloOpenCl:                         # @dgHelloOpenCl
# BB#0:
   push   EBX
   push   EDI
   push   ESI
   mov   EAX, -1
   mov   ECX, DWORD PTR [ESP + 44]
   mov   EDX, DWORD PTR [ESP + 20]
   mov   ESI, DWORD PTR [ESP + 16]
   .align   16, 0x90
LBB0_1:                                 # %SyncBB1
                                        # =>This Inner Loop Header: Depth=1
   mov   EDI, DWORD PTR [ECX]
   mov   EBX, DWORD PTR [ESP + 40]
   add   EDI, DWORD PTR [EBX]
   shl   EDI, 5
   vmovaps   YMM0, YMMWORD PTR [ESI + EDI]
   vaddps   YMM0, YMM0, YMMWORD PTR [EDX + EDI]
   mov   EBX, DWORD PTR [ESP + 24]
   vmovaps   YMMWORD PTR [EBX + EDI], YMM0
   add   ECX, 16
   inc   EAX
   cmp   EAX, DWORD PTR [ESP + 52]
   jb   LBB0_1
# BB#2:                                 # %SyncBB
   pop   ESI
   pop   EDI
   pop   EBX
   ret

as you can see the code is issues using the AVX instrutions set, if I set the data type to float4 then it uses xmm, and if I set it to float is issue scalar sse.
what this means is that I can safelly delete all the AVX code. The coolest thing is that this code also runs on my nvidia gforce 260 using cuda.
so by going to openCL we can have the best of everything.
I even beging to wonder if I can remove the SSE class and make the engine intrinsics free.
I am not doing that now, but in teh future depend of teh openCL results I migh do that.
It is so awesome that now with openCL we have floatn, intn types which are native to the language.

about 5 years ago I wrote a cuda solver than was doing a 100 x 100 pyramid stack at 60 fps (5000 boxes), but it was so contrived that I decided to pass until it became more matured.
Nvidia never paid attention to any of my request for atomics in CUDA, but now OpenCL they not only have atomics, they also have fences, barriers and everything that is needed for general porpuse programing.
I believe the nvida opencl driver is just a translator to CUDA, in fact the vendor string says "nvidia CUDA"


here is a question, do the mobile devices support openCL?

[carli2]

here is a question, do the mobile devices support openCL?

They're going to have.
As a fallback you can use clover which compiles OpenCL to multi threaded CPU code.

The good thing at OpenCL is that the code is compiled on the target platform which means the vendor of the platform will give you the compiler as a driver.

[pHySiQuE]

iOS does not. Google was pushing their "RenderScript" API a while ago, which seemed completely pointless to me.

--
Whoops, I guess RenderScript has been deprecated now.

[carli2]

iOS does not.

If iOS does not, you simply compile clover as a static library and hope that apple will not remove your app from the appstore, because it allows a "program in a app".

[Gaetan]

Anybody has a working set of built static libraries for Mac/Linux/Windows?
I've been trying to compile without success on OS X, even when following these instructions.

Thanks in advance!
Gaetan