search

KhronosGroup / KTX-Software

KTX (Khronos Texture) Library and Tools
Other
874 stars 229 forks source link

macOS Apple Silicon (ARM64) support #362

Closed atteneder closed 3 years ago

atteneder commented 3 years ago

I tried to build and tests Universal libraries/apps (supporting both Intel and Apple Silicon architectures) on macOS.

After some necessary changes ( see branch apple_silicon ) I could get it to build and run, partially.

This is how I configured:

cmake -GXcode -Bbuild-macos \
-DKTX_FEATURE_DOC=OFF \
-DCMAKE_OSX_ARCHITECTURES=arm64 \
-DKTX_FEATURE_LOADTEST_APPS=OFF \
-DXCODE_CODE_SIGN_IDENTITY="" \
-DVULKAN_INSTALL_DIR="${VULKAN_INSTALL_DIR}"

I went on and tried it in an application (in Unity via KtxUnity). Transcoding basis files still works, but trying to load and transcode a KTX2 file leads to brief visual artifacts (sometimes) and crashes (every time).

Running in x86_64(Intel) mode via Rosetta2 works on an M1 Mac Mini though.

Some work left to do. First of all to get the unittests and transcodetests running again. Not sure if and when I have time to continue, so I documented it in this issue. Hopefully somebody can help me out.

Regards, Andi

alecazam commented 3 years ago

I hit this in my own encoder, and had to isolate all static initializers and run them inside function calls after main() is initialized. It seems like pre-init C++ code breaks the Rosetta 2 interpreter.

atteneder commented 3 years ago

Hi @alecazam,

Thanks for reporting your results.

Running x86_64 binaries on an M1 Mac Mini (via Rosetta2, presumably) does work for me. Only running native arm64 did leads to crashes. Can you confirm this or did you face a different problem?

Any chance your changes to get it running can be viewed somewhere?

Regards, Andi

alecazam commented 3 years ago

Sorry, I misspoke since I've hit two pre-init problems. One with work code with an allocation at pre-init and Rosetta2 crashing on startup (not resolved), and the other with personal code on arm64 with pre-init (resolved).

I was building up a C++ table of formats in pre-init which ran fine in x64, but not in arm64. Moving that call into the function calls themselves (moving the allocation out of pre-init) solved my universal build issue on arm64.

I've only built libktx and the apps for x64, and don't yet call libktx from kram. I run ktx2ktx2 and ktxsc through Rosetta2 for now. So I haven't had to fix the crash issue. I don't know how many pre-init initializers that libktx has, but that was my solution. It was rather troublesome when the crash occurred, since the app dies at init on arm64 without much to go on.

Look at https://github.com/alecazam/kram/KTXImage.cpp and the following commit hash where I moved the calls. The comment title is wrong about fixing Rosetta2, it's fixing the arm64 build. da808e7d5d25d4cf4fc5e01795b4e194c3f3a542

atteneder commented 3 years ago

So you ran into this assert, I guess. Not sure yet how this relates, but we'll see if I or someone faster can figure it out.

Thanks for the info!

alecazam commented 3 years ago

No, I didn't hit any assert IIRC. It was the app crashing on launch in pre-init only on arm64 universal builds, without a lot to go on. But I'd had it working before some of those table changes, so I kind of knew where to look. If you can isolate the static global init code in libktx, then that might be what is causing your arm64 failure.

BeastLe9enD commented 3 years ago

I wanted to inquire if there is progress, as it still does not work

MarkCallow commented 3 years ago

I'm afraid not. @atteneder who created this PR, and was working on it, is on paternity leave. I do not have a machine with Apple Silicon. Volunteers welcome.

atteneder commented 3 years ago

Indeed. I'll try to give it another shot some time in April (in case no one else got it to run)

MarkCallow commented 3 years ago

PR #415 with macOS Apple Silicon support has been merged. Sorry for the delay in pointing it out here.

The only known issue currently is that vkloadtests & gl3loadtests cannot be built as we don't have an Apple Silicon version of libassimp. I've attempted to build it but there are problems with the cmake set up that I do not have time to delve into.