Make FP16 support optional on ARM64

[stephengold]

The README.md says that on ARM64 the library uses FP16. That's a barrier to using Jolt Physics on many older ARM-based systems.
I propose making FP16 on ARM64 a build option, similar to F16C on X64.

[jrouwe]

Yes, it is super easy to turn off. Just make sure it doesn't execute this (but the next line instead):

JoltPhysics/Jolt/Math/HalfFloat.h

Line 200 in 072675b

return vcvt_f32_f16(vreinterpret_f16_u32(vget_low_u32(inValue.mValue)));

The reason why I made it the default is that I thought that nearly all armv8 processors support this. E.g. it works on my Raspberry Pi 4 which is using old A72 hardware. Do you have specific examples where it doesn't work?

[stephengold]

Thanks for your reply to my suggestion.

I haven't yet seen a crash caused by Jolt's use of 16-bit floating point. Like you, I tested on a Raspberry Pi with an A72 processor.

I'm not 100% sure why this code runs on the Pi. I find the ARM documentation both confusing and cryptic. Apparently NEON is a marketing term for the AdvSIMD feature, which includes hw conversions between 16-bit floating point and other data types. But AdvSIMD doesn't include arithmetic on 16-bit floating point values; that was added with the FP16 feature in Armv8.2-A.

I haven't disassembled to see what instructions are actually generated for line 200. But documentation for the 3 intrinsics there indicates they generate DUP, NOP, and FCVTN instructions. FCVTN requires the AdvSIMD feature, not the FP16 feature. There's no 16-bit arithmetic in line 200, just copies and conversions. So perhaps Jolt doesn't use the FP16 feature at all. That would be nice since many CPUs (including the A72) implement Armv8.0-A but not Armv8.2-A.

The fact that Jolt runs on the A72 in 64-bit mode also suggests that Jolt doesn't need the FP16 feature. So maybe there's no need for a build option; just change the documentation in README.md .

Another possibility would be that Linux traps unimplemented instructions and emulates them.

[jrouwe]

I've done a bit of digging and I think FCVTN is indeed supported on Armv8-A, so I've updated the README.md.

The Armv8-A reference states for e.g. FADDP that it tests for FP16:

And in the table overview it lists requiring FEAT_FP16:

For FCVTN there are no such requirements listed.

[stephengold]

I agree. Thank you for the followup!