Closed waywardmonkeys closed 2 weeks ago
Since the macOS CI is using macos-latest
, it can be either macos-12
(Intel) or macos-14
(Apple Silicon) as they are rolling out the update over some weeks.
I think I encountered this on the neon branch (on a Raspberry Pi 4). If you have a Mac, could you possibly try the neon branch or just this change and see if it fixes it? https://github.com/bitshifter/glam-rs/pull/379/files#diff-bfee85a55d20e3f570066acdc78e0bc38a8ec04a57198d681bdac80cad3c06f5L39-L47
Both that one change to reduce the precision required for the tests to pass as well as using the neon
branch work and pass all tests on my M3 Mac.
That's a pretty big variation in precision though ...
Worth noting then that this also fails (on my Mac):
cargo test --no-default-features --features libm
Yes I get the same thing with libm on my raspberrypi, but not on x86_64. It is a bit surprising, I would have thought that libm would give the same results on different architectures.
I don't have an x86_64 machine handy to compare on (!) at the moment, but I wonder if it is always using the CPU instructions while we have software approximations elsewhere.
The libm
sources are derived from musl libc, which is what is used in Emscripten as well. The comments in the files indicate that at least parts of them come from FreeBSD, so they may well be similar to what's in the macOS standard library, but I didn't check further.
There are some very old bugs in the libm repo about needing to do tests for precision and other things. Seems like this might be a corner of the Rust world that needs some love, but well outside the scope of this.
On my Raspberrypi cargo test --no-default-features --features libm,scalar-math
passed. This is pretty odd, on the main
branch there is no neon implementation so I think the only real difference would be Quat
and Vec4
are 16 byte aligned, the scalar-math
feature turns that off. I will try look at the generated assembly some time.
Ah scalar-math
lowers the precision of the test :) (I didn't write this, it was contributed, not that I remember everything I write either).
Given this precision is lowered in the test with scalar-math
or wasm
, I think probably the sse2 implementation of quat mul quat must have slightly better precision than the scalar implementation. I think that is the only part of the Euler conversion code that would be any different between x86_64 and arm. On arm it will be using the scalar code because there is no neon implementation on main
. So it's probably not a libm issue either.
I've submitted the tolerance change so this test passes. I'm still investigating if there is anything in particular that makes scalar-math less precise than the SSE2 implementation.
Changed the implementation which improves precision #537
When running the tests on
main
on an M3 laptop: