Page MenuHome

macOS: changes to build library dependencies for arm64

Authored by Stefan Werner (swerner) on Jul 7 2020, 3:51 PM.



The changes necessary to build Blender on a Mac with arm64 CPU, using the same steps as build on a x86_64 Mac.
Except for OIDN, this will result in a feature complete but untested and most likely buggy build of Blender.

This is still work in progress - it needs a little bit more cleanup before we can commit this IMHO.

The original patches sent by Apple are archived below and are not necessary or included in this new patch:

These patches were provided by Apple.

Note this patch does not apply on latest master, it is from 5/29/2020.

There is a patch for Blender, and patches for various library dependencies attached below.

Diff Detail

rB Blender

Event Timeline

Brecht Van Lommel (brecht) requested review of this revision.Jul 7 2020, 3:51 PM
Brecht Van Lommel (brecht) created this revision.

OpenImageDenoise naturally doesn’t have an ARM port. There is however a denoiser that Apple includes in the Metal framework that we could use instead.

Brecht Van Lommel (brecht) planned changes to this revision.Jul 7 2020, 5:17 PM

Setting this as plan changes after code review. It doesn't mean I personally will make those changes, another developer is welcome to pick up the work here.


This should be if (NOT BUILD_APPLE_ARM64).


It's rather surprising to me that this would be arm64 specific, maybe is just needed for all architectures or not needed at all.


These changes to the Windows build should be removed.

31 ↗(On Diff #26589)

This hardcoded path should be fixed.


Commented out code is to be removed.


Commented out code to be either used or removed.

300 ↗(On Diff #26589)

Embree is disabled in this patch, so the hash should also not be changed.

Presumably this was from an unfinished test.

37–39 ↗(On Diff #26589)

We don't support OpenXR on Apple yet. But I assume the test needs to change to just if (APPLE) since -DXR_OS_APPLE does not seem arm64 specific.

Certainly needs some work before committing. Ideally, I'd like all scripts to obey CMAKE_OSX_ARCHITECTURES/OSX_ARCHITECTURES so that we can cross-compile.

macOS: Port to arm64.

All dependencies with the exception of OIDN (requires SSE4.1) now build
on arm64/macOS. With the exception of OIDN, a feature complete Blender
can build and run on the DTK.

Other developers with access to arm64 Mac hardware can now help with
testing and bug fixes. Patches are very welcome. Please respect the NDA
and do not publish benchmarks.

In my tests, make deps on Linux and macOS/x86_64 were not broken by this change and work as before. @Ray molenkamp (LazyDodo), can you check if this patch breaks Windows builds?

Stefan Werner (swerner) edited the summary of this revision. (Show Details)Tue, Jul 14, 1:03 PM
Stefan Werner (swerner) edited the summary of this revision. (Show Details)Tue, Jul 14, 1:08 PM

Do the tests pass?


Remove indent.

22–26 ↗(On Diff #26788)

How does this work, can you simply use SSE2 instructions somehow on macOS arm64 and it gets emulated?


Is this a backported patch from a newer Python version?

If so, would be good to mention it somewhere.

Stefan Werner (swerner) marked 4 inline comments as done.Tue, Jul 14, 1:45 PM
Stefan Werner (swerner) added inline comments.

This change may not be specific to the architecture but macOS 11.

Stefan Werner (swerner) edited the summary of this revision. (Show Details)Tue, Jul 14, 1:47 PM
Stefan Werner (swerner) marked an inline comment as not done.Tue, Jul 14, 2:15 PM
Stefan Werner (swerner) added inline comments.
22–26 ↗(On Diff #26788)

This is using the Embree port for ARM from or more precisely, a mirror that has a 3.10.0 release archive. See versions.cmake.

I'm not too excited about pulling from completely separate repositories for different architectures, but I don't expect Intel to add official ARM support to Embree.


It is back ported from a PR by Apple for the latest Python. I mentioned this in the commit logs of the mac_arm64 branch, but yes, it would help a lot if I documented this in the code as well.

Stefan Werner (swerner) marked an inline comment as not done.EditedTue, Jul 14, 8:53 PM
94% tests passed, 3 tests failed out of 52

Total Test time (real) = [redacted] sec

The following tests FAILED:
	 21 - constraints (Failed)
	 32 - cycles_denoise_animation (Failed)
	 52 - ffmpeg (Failed)

Did a clean build of the deps, no build issues on windows, but have yet to run the unit tests.

No other dependency or general build issues on the DTK from the studio. Nice to see it running!
Just noticed some linker warnings for Mantaflow - the simulation source files might need to be preprocessed differently.

Sebastián Barschkis (sebbas) retitled this revision from macOS: changes to build library dependences for arm64 to macOS: changes to build library dependencies for arm64.Wed, Jul 15, 4:30 PM
22–26 ↗(On Diff #26788)

Ok, we can ask Intel about their positions on this at least (CC @Sergey Sharybin (sergey)), I'm still hoping there will be ARM support in the official Embree repo at some point.

For the initial commit of this patch I'd rather build without Embree then.

We might end up having to maintain the changes ourselves, but then maybe it should be in the form of a patch or we host the Embree repo with modifications on

Windows checks out, i had to merge master to fix of some failing tests (modifiers, constraints) but beyond that no issues.

Your failing ffmpeg test is probably an indication of one or more of the libs not being picked up, it's a pretty basic sanity check that ffmpeg has all the codecs blender counts on being there it doesn't even run them, just tests if it can instance them.

This revision is now accepted and ready to land.Wed, Jul 15, 5:36 PM
22–26 ↗(On Diff #26788)

I'll leave Embree out then for now. We can still turn it on later if we need to.

Without giving absolute numbers, the difference of Embree vs BVH2 is significant. I'll have to try the ARM SIMD patch next to see what that gains us.

This revision was automatically updated to reflect the committed changes.

I think we should ship with Embree on Arm64 in the end. My only concern is that we host the code in a place where any Blender developer can edit it, and that we check the diff compared to Embree to ensure it can be trusted.

But maybe it's easiest to first check with Intel before we do the work.