Compatibility with Linux or OSX ?

[melMass]

Hi,

Before digging into the code I wanted to know if there is a known limitation on OSX or Linux, does the code depend on windows specific libraries?

Thanks

[Newbytee]

Hi,

Before digging into the code I wanted to know if there is a known limitation on OSX or Linux, does the code depend on windows specific libraries?

Thanks

I'm not from AMD, but it does not currently build on Linux as-is. It uses some Visual C/C++ specific compiler directives and gets stuck on functions not declared in the current scope. This is due to that the function definitions they sit within #ifdef WIN32s without equivalents for other platforms; removing the #ifdef won't help since the functions depend on Windows.h.

[mastercoms]

I've been working on portability in my Unreal Engine 4.24 PR: https://github.com/GPUOpenSoftware/UnrealEngine/pull/14

[w23]

@mastercoms Have you got it working?
I've made a very crude and dumb and uninformed attempt to port it and made FEMFXViewer compile and link just fine (https://github.com/w23/FEMFX/tree/linux-port). However, it reliably crashes at init:

$ ./build/gmake2/x86_64/Debug/FEMFXViewer_d
AddressSanitizer:DEADLYSIGNAL
=================================================================
==940==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000001e4 (pc 0x0000004d9db4 bp 0x7ffc006ebc10 sp 0x7ffc006ebba0 T0)
==940==The signal is caused by a WRITE memory access.
==940==Hint: address points to the zero page.
    #0 0x4d9db3 in FmVectormath::Vector3::operator=(FmVectormath::Vector3 const&) /home/w23/src/FEMFX/samples/FEMFXViewer/../../amd_femfx/inc/Vectormath/vec_aos.h
    #1 0x4ff233 in FmVectormath::Matrix3::operator=(FmVectormath::Matrix3 const&) /home/w23/src/FEMFX/samples/FEMFXViewer/../../amd_femfx/inc/Vectormath/mat_aos.h:163:18
    #2 0x9f3b7f in AMD::FmStoreUpdatedTetState(AMD::FmTetMesh*, unsigned int, AMD::FmUpdateTetStateOutput const&, bool) /home/w23/src/FEMFX/amd_femfx/src/Simulation/FEMFXUpdateTetState.cpp:1180:54
    #3 0x9f80c7 in AMD::FmUpdateTetsRange(bool*, unsigned int*, AMD::FmTetMesh*, unsigned int, unsigned int, FmVectormath::Vector3 const&, bool, bool, bool, bool) /home/w23/src/FEMFX/amd_femfx/src/Simulation/FEMFXUpdateTetState.cpp:1335:17
    #4 0x9f9caa in AMD::FmUpdateTetStateAndFracture(AMD::FmScene*, AMD::FmTetMesh*, bool, bool, AMD::FmAsyncTaskData*) /home/w23/src/FEMFX/amd_femfx/src/Simulation/FEMFXUpdateTetState.cpp:1521:13
    #5 0x9c2342 in AMD::FmFinishTetMeshInit(AMD::FmTetMesh*) /home/w23/src/FEMFX/amd_femfx/src/Simulation/FEMFXTetMesh.cpp:1815:9
    #6 0x5d1a02 in InitScene(char const*, char const*, int, int) /home/w23/src/FEMFX/samples/FEMFXViewer/../common/TestScenes.cpp:2353:9
    #7 0x4e22d4 in main /home/w23/src/FEMFX/samples/FEMFXViewer/FEMFXViewer.cpp:1746:5
    #8 0x7f5d80652f1a in __libc_start_main /var/tmp/portage/portage/sys-libs/glibc-2.29-r7/work/glibc-2.29/csu/../csu/libc-start.c:308:16
    #9 0x41ee99 in _start (/home/w23/src/FEMFX/samples/FEMFXViewer/build/gmake2/x86_64/Debug/FEMFXViewer_d+0x41ee99)

I've only briefly looked at it and it would seem that there's a decoherence between FmTetMesh::tetsPlasticity being nullptr and FmUpdateTetStateOutput::updatePlasticity being not zero, and that not zero value seems to be read from simd (?!), which suggest that I've incorrectly implementated of all these m128_i32 and other unportable friends.

So will have to dig deeper and spend a non-trivial amount of time on this.

It's a bit unfortunate that there are no tests to guide the porting effort.

[mastercoms]

I haven't finished my porting of it (been a bit busy!), but you need to recreate the unions which are included by the MSVC SIMD libraries:

typedef union __declspec(align(16)) vec4 {
     __m128              v;
     float               m128_f32[4];
     uint64_t            m128_u64[2];
     int8_t              m128_i8[16];
     int16_t             m128_i16[8];
     int32_t             m128_i32[4];
     int64_t             m128_i64[2];
     uint8_t             m128_u8[16];
     uint16_t            m128_u16[8];
     uint32_t            m128_u32[4];
} vec4;

typedef union __declspec(align(16)) vec4i {
    __m128i             v;
    int8_t              m128i_i8[16];
    int16_t             m128i_i16[8];
    int32_t             m128i_i32[4];
    int64_t             m128i_i64[2];
    uint8_t             m128i_u8[16];
    uint16_t            m128i_u16[8];
    uint32_t            m128i_u32[4];
    uint64_t            m128i_u64[2];
} vec4i;

typedef union __declspec(align(16)) vec4d {
    __m128d             v;
    double              m128d_f64[2];
} vec4d;

typedef union __declspec(align(32)) vec8 {
    __m256 v;
    float m256_f32[8];
} vec8;

typedef union __declspec(align(32)) vec8d {
    __m256d v;
    double m256d_f64[4];
} vec8d;

typedef union __declspec(align(32)) vec8i {
    __m256i v;
    int8_t              m256i_i8[32];
    int16_t             m256i_i16[16];
    int32_t             m256i_i32[8];
    int64_t             m256i_i64[4];
    uint8_t             m256i_u8[32];
    uint16_t            m256i_u16[16];
    uint32_t            m256i_u32[8];
    uint64_t            m256i_u64[4];
} vec8i;

Then it should just be a matter of creating a union, using the SIMD object (like of type m128_i32) and assigned it to the v member, and then accessing the other union members (or the reverse, where appropriate).

[w23]

I also tried this (blatantly copying stuff from your branch/pr :D and patching declspec-align thing), but the result is the same, so it's either something else, or both of our impls are wrong.

[mastercoms]

I haven't implemented everything for portability so it's possible there's still some non-portable code. Did you complete the implementation?

[w23]

I completed it in a sense that I got it to build and link successfully without leaving any unimplemented stubs behind or making any significant shortcuts. There are a few warnings remaining.
It is very likely that I made a mistake somewhere (or many of them :D), though.

[erwincoumans]

I completed it in a sense that I got it to build and link successfully without leaving any unimplemented stubs behind or making any significant shortcuts. There are a few warnings remaining.
It is very likely that I made a mistake somewhere (or many of them :D), though.

Does it work on Linux or OSX and do you have a fork?

[w23]

@erwincoumans it crashes early at startup, which makes it hard to say it works :). This is what I got: https://github.com/w23/FEMFX/tree/linux-port

[CrazyCat22]

Any luck making this work on Linux or OSX? With no updates in almost 2 years, has FEMFX been abandoned?