Open melMass opened 4 years ago
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 WIN32
s without equivalents for other platforms; removing the #ifdef
won't help since the functions depend on Windows.h
.
I've been working on portability in my Unreal Engine 4.24 PR: https://github.com/GPUOpenSoftware/UnrealEngine/pull/14
@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.
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).
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.
I haven't implemented everything for portability so it's possible there's still some non-portable code. Did you complete the implementation?
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.
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?
@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
Any luck making this work on Linux or OSX? With no updates in almost 2 years, has FEMFX been abandoned?
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