Closed akien-mga closed 2 years ago
The issue you see should be limited to changes made in commits f11aaa37 and/or ae0e7eb44d. Code paths should be properly guarded in the remaining cases (which are the majority both code- and performance-wise). You may check if this is indeed the case and just fix these few #ifdefs, falling back to scalar code.
We use etcpak in the Godot editor, and the Godot editor can be compiled for ARMv7 with NEON for Linux, Windows and Android.
For the Android build at least, using NDK 21.4, we're running into a build issue in etcpak due to the use of AArch64 NEON intrinsics in
ProcessRGB.cpp
, which are not guarded with#if defined(__aarch64__)
:You have such guards in
ProcessDxtc.cpp
with versions for both AArch64 and ARMv7, but not inProcessRGB.cpp
: https://github.com/wolfpld/etcpak/blob/14dfc2b8d935a71c9ae5772119520d00fe8e2eac/ProcessDxtc.cpp#L277-L281 https://github.com/wolfpld/etcpak/blob/14dfc2b8d935a71c9ae5772119520d00fe8e2eac/ProcessRGB.cpp#L2592-L2596Would it be possible to add checks to
ProcessRGB.cpp
so that it only uses AArch64 specific intrinsics when__aarch64__
is defined?AFAICT I'm fine if it falls back to a slow path on ARMv7+NEON, I don't expect it to be a very relevant use case for using etcpak in production, but it would be good if it could compile nevertheless (otherwise that means we can't ship the Godot editor on ARMv7 platforms, unless we disable VRAM compression which is pretty important for our use case).
BTW, the fallback path doesn't seem to be functional, as this hack:
Leads to these errors: