Godot (Jolt) cannot be cross-compiled on Linux for ppc64 and rv64

[MBCX]

Tested versions

• Master branch as of (44dfa7e)

System information

Godot v4.4.dev (9ee41ad73) - Windows 10.0.26100 - Multi-window, 2 monitors - Vulkan (Forward+) - dedicated Radeon RX 580 Series (Advanced Micro Devices, Inc.; 31.0.21921.1000) - Intel(R) Core(TM) i5-9600K CPU @ 3.70GHz (6 threads)

Issue description

Since the merger of Jolt Physics (#99895), now Godot cannot be compiled nor cross-compiled for other architectures (PPC and RISC-V/RV64). It can only be compiled/cross-compiled for x86 and/or ARM.

For both, it does say that the architecture is unsupported:

In file included from thirdparty/jolt_physics/Jolt/RegisterTypes.cpp:5:
In file included from thirdparty/jolt_physics/Jolt/Jolt.h:8:
thirdparty/jolt_physics/Jolt/Core/Core.h:206:3: error: Unsupported CPU architecture
  206 |         #error Unsupported CPU architecture
      |          ^
BUILD: Elapsed time [00:02:34]
Compiling thirdparty/jolt_physics/Jolt/AABBTree/AABBTreeBuilder.cpp ...
In file included from thirdparty/jolt_physics/Jolt/AABBTree/AABBTreeBuilder.cpp:5:
In file included from thirdparty/jolt_physics/Jolt/Jolt.h:8:
thirdparty/jolt_physics/Jolt/Core/Core.h:206:3: error: Unsupported CPU architecture
  206 |         #error Unsupported CPU architecture
      |          ^
thirdparty/jolt_physics/Jolt/Core/Core.h:458:34: error: use of undeclared identifier 'JPH_CPU_ADDRESS_BITS'
  458 | static_assert(sizeof(void *) == (JPH_CPU_ADDRESS_BITS == 64? 8 : 4), "Invalid size of pointer" );
      |                                  ^
In file included from thirdparty/jolt_physics/Jolt/RegisterTypes.cpp:5:
In file included from thirdparty/jolt_physics/Jolt/Jolt.h:12:
In file included from thirdparty/jolt_physics/Jolt/Core/Array.h:7:
thirdparty/jolt_physics/Jolt/Core/STLAllocator.h:47:63: error: use of undeclared identifier 'JPH_CPU_ADDRESS_BITS'
   47 |         static constexpr bool   needs_aligned_allocate = alignof(T) > (JPH_CPU_ADDRESS_BITS == 32? 8 : 16);
      |                                                                        ^
# ......
# .....

But this is kind of a bummer, more so for rv64 users.

Steps to reproduce

1. Follow the instructions for setting up an rv64 cross-compiler.
2. Execute the build command there.
3. Wait for failure.

Minimal reproduction project (MRP)

N/A

[akien-mga]

CC @mihe @jrouwe
I don't know if there's any plans upstream to add support for more architectures eventually.

For now the simple solution for us is to disable the jolt_physics module on those architectures, I'll do that.

[mihe]

PowerPC support was brought up fairly recently: jrouwe/JoltPhysics#1377

I must admit I didn't realize either of those architectures were supported by Godot.

What kind of devices is RISC-V used for targeting mainly?

[bruvzg]

It supports WASM without any assembler optimizations, so it should be fairly easy to use the same code path for unsupported archs, something like (not tested on any actual devices):

diff --git a/thirdparty/jolt_physics/Jolt/Core/Core.h b/thirdparty/jolt_physics/Jolt/Core/Core.h
index a0ad97eeb6..b2c9de20e0 100644
--- a/thirdparty/jolt_physics/Jolt/Core/Core.h
+++ b/thirdparty/jolt_physics/Jolt/Core/Core.h
@@ -202,6 +202,22 @@
 	#if defined(__SSE__) && !defined(JPH_USE_SSE)
 		#define JPH_USE_SSE
 	#endif
+#elif defined(__powerpc__) || defined(_M_PPC)
+	#define JPH_CPU_OTHER
+	#if defined(__powerpc64__) || defined(_M_PPC64) || defined(__ppc64__)
+		#define JPH_CPU_ADDRESS_BITS 64
+	#else
+		#define JPH_CPU_ADDRESS_BITS 32
+	#endif 
+	#define JPH_VECTOR_ALIGNMENT 16
+	#define JPH_DVECTOR_ALIGNMENT 32
+	#define JPH_BREAKPOINT	__builtin_trap()
+#elif defined(__riscv) || defined(__loongarch64)
+	#define JPH_CPU_OTHER
+	#define JPH_CPU_ADDRESS_BITS 64
+	#define JPH_VECTOR_ALIGNMENT 16
+	#define JPH_DVECTOR_ALIGNMENT 32
+	#define JPH_BREAKPOINT	__builtin_trap()
 #else
 	#error Unsupported CPU architecture
 #endif
diff --git a/thirdparty/jolt_physics/Jolt/Core/FPControlWord.h b/thirdparty/jolt_physics/Jolt/Core/FPControlWord.h
index 0c8b3f1ff0..0f8b72343c 100644
--- a/thirdparty/jolt_physics/Jolt/Core/FPControlWord.h
+++ b/thirdparty/jolt_physics/Jolt/Core/FPControlWord.h
@@ -8,7 +8,7 @@
 
 JPH_NAMESPACE_BEGIN
 
-#if defined(JPH_CPU_WASM)
+#if defined(JPH_CPU_WASM) || defined(JPH_CPU_OTHER)
 
 // Not supported
 
diff --git a/thirdparty/jolt_physics/Jolt/Core/FPException.h b/thirdparty/jolt_physics/Jolt/Core/FPException.h
index 3083f05c05..82a6368f79 100644
--- a/thirdparty/jolt_physics/Jolt/Core/FPException.h
+++ b/thirdparty/jolt_physics/Jolt/Core/FPException.h
@@ -10,7 +10,7 @@ JPH_NAMESPACE_BEGIN
 
 #ifdef JPH_FLOATING_POINT_EXCEPTIONS_ENABLED
 
-#if defined(JPH_CPU_WASM)
+#if defined(JPH_CPU_WASM) || defined(JPH_CPU_OTHER)
 
 // Not supported
 class FPExceptionsEnable { };
diff --git a/thirdparty/jolt_physics/Jolt/Core/FPFlushDenormals.h b/thirdparty/jolt_physics/Jolt/Core/FPFlushDenormals.h
index 672a19dbec..5e45c98999 100644
--- a/thirdparty/jolt_physics/Jolt/Core/FPFlushDenormals.h
+++ b/thirdparty/jolt_physics/Jolt/Core/FPFlushDenormals.h
@@ -8,7 +8,7 @@
 
 JPH_NAMESPACE_BEGIN
 
-#if defined(JPH_CPU_WASM)
+#if defined(JPH_CPU_WASM) || defined(JPH_CPU_OTHER)
 
 // Not supported
 class FPFlushDenormals { };
diff --git a/thirdparty/jolt_physics/Jolt/Core/TickCounter.h b/thirdparty/jolt_physics/Jolt/Core/TickCounter.h
index 2b5410e3d9..d961e61077 100644
--- a/thirdparty/jolt_physics/Jolt/Core/TickCounter.h
+++ b/thirdparty/jolt_physics/Jolt/Core/TickCounter.h
@@ -37,7 +37,7 @@ JPH_INLINE uint64 GetProcessorTickCount()
 	return val;
 #elif defined(JPH_CPU_ARM)
 	return 0; // Not supported
-#elif defined(JPH_CPU_WASM)
+#elif defined(JPH_CPU_WASM) || defined(JPH_CPU_OTHER)
 	return 0; // Not supported
 #else
 	#error Undefined
diff --git a/thirdparty/jolt_physics/Jolt/Math/Math.h b/thirdparty/jolt_physics/Jolt/Math/Math.h
index 729d5403e3..24c5cbff7e 100644
--- a/thirdparty/jolt_physics/Jolt/Math/Math.h
+++ b/thirdparty/jolt_physics/Jolt/Math/Math.h
@@ -94,7 +94,7 @@ inline bool IsAligned(T inV, uint64 inAlignment)
 /// Compute number of trailing zero bits (how many low bits are zero)
 inline uint CountTrailingZeros(uint32 inValue)
 {
-#if defined(JPH_CPU_X86) || defined(JPH_CPU_WASM)
+#if defined(JPH_CPU_X86) || defined(JPH_CPU_WASM) || defined(JPH_CPU_OTHER)
 	#if defined(JPH_USE_TZCNT)
 		return _tzcnt_u32(inValue);
 	#elif defined(JPH_COMPILER_MSVC)
@@ -130,7 +130,7 @@ inline uint CountTrailingZeros(uint32 inValue)
 /// Compute the number of leading zero bits (how many high bits are zero)
 inline uint CountLeadingZeros(uint32 inValue)
 {
-#if defined(JPH_CPU_X86) || defined(JPH_CPU_WASM)
+#if defined(JPH_CPU_X86) || defined(JPH_CPU_WASM) || defined(JPH_CPU_OTHER)
 	#if defined(JPH_USE_LZCNT)
 		return _lzcnt_u32(inValue);
 	#elif defined(JPH_COMPILER_MSVC)

[akien-mga]

Based on jrouwe/JoltPhysics#1377, I expect @jrouwe isn't too keen on adding theoretical compilation support for devices which would likely not be powerful enough to decently run Jolt Physics. That's quite fair.

Most push for supporting these architectures comes in my experience mostly from Linux distros, notably Debian, that want to package Godot and still try to support all those architectures for legacy reasons. Like we have ppc32 and ppc64 theoretical support, I've never seen a user that actually used those. So while they probably compile fine on Debian, I'm not sure they can actually run any 3D project.

Usually it's more a theoretical "can it compile?" and not really an effort to actually test the compiled software and make sure it's useful to the theoretical users of those architectures. I've been there myself as a Linux packager so I can understand the rationale, but from an upstream library point of view it's totally to say "nope, not relevant for this lib".

RISC-V and LoongArch are newer systems though, and may (eventually?) be relevant for gaming/simulation purposes and warrant proper support in Jolt. But I think it's fine to disable the module for now on those platforms and wait for demand to actually be there for getting Jolt to run on such devices, with confirmation that it (and Godot itself) would actually run well.

[MBCX]

That's fair. In my case, I mostly compile these architecture for completeness sake (having a "complete" Godot installation), I myself probably won't export a game to those architectures, nor I expect them to work (I don't have hardware and software to test it), so pretty much what Akien said.

rv64 seems to be the most viable, because with the instructions above, a user was able to get the editor to boot up.

[hpvb]

I have a riscv machine that very much can run Godot now. :) It is based on the hifive unmatched (https://www.sifive.com/boards/hifive-unmatched) and mine has a radeon rx580 in it right now.

So, non-theoretical riscv systems do exist that can run Godot now.

[jrouwe]

So it looks like supporting RISC-V was not that difficult: jrouwe/JoltPhysics#1400. It even works with cross platform determinism (producing the same simulation results bit for bit when compared with x86/ARM/WASM).

I see that there's also a qemu-loongarch64 emulator so I'm guessing that it's not too hard to build and validate that one too.

Funny thing is that I looked at godot's supported platforms when discussing jrouwe/JoltPhysics#1377. I didn't see support for PPC, so I dismissed it as not being very important. The platform is a bit more problematic as it is a big-endian architecture. But if the requirements are that it compiles and does not need to run, then I guess that that can be done too.

[hpvb]

@jrouwe I think a risc-v port of Jolt would be useful, PPCLE might also be worth doing for the few millionaires that own a Raptor Thalos ][, I don't know if anyone runs ppcbe linux on those.