Hello!

1. please see my related work for arm64-linux: https://developer.blender.org/D9505. I'd be happy to see a solution that will work for both mac and linux.
2. embree-arm64 did add a release that can be downloaded and used in a way more compatible with most cmake files here.. https://github.com/lighttransport/embree-aarch64/releases/tag/v3.12.1-aarch64
3. I would be happy to get the opinion of someone with a wide view on blender if it's better to treat embree-aarch64 as a separate library (like in this patch) or as the same one (like in mine). I went with treating it as the same library as it makes the differences very clear, and easier to update e.g. configuration for both, but there are good arguments both ways.

I couldn't test things for OSX/arm64 beause I don't currently have access to that HW. Specifically for cmake, I'd be happy if there's some good way for a unified architecture test.
OSX_ARCHITECTURE certainly only works on MAC. The linux way is to test:

if( ${CMAKE_SYSTEM_PROCESSOR} STREQUAL "aarch64")

which is how I end up with weird things like:

if((APPLE AND ("${CMAKE_OSX_ARCHITECTURES}" STREQUAL "arm64"))
  OR (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "aarch64"))

if((APPLE AND ("${CMAKE_OSX_ARCHITECTURES}" STREQUAL "arm64")) OR (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "aarch64"))

Suggest creating a utility macro for that. Or declare a global boolean variable/property in top level CMakeLists.txt and set it to true there itself once and for all.

Suggest creating a utility macro for that. Or declare a global boolean variable/property in top level CMakeLists.txt and set it to true there itself once and for all.

done in my patch (https://developer.blender.org/D9505?vs=30873&id=31170) please take a look.
Thank you!

We should not rely on an unofficial repository for Embree, see discussion in D8236.

I've heard from Intel that they are open to having ARM in the upstream Embree library, so making that happen is the preferable solution.

As a stopgap solution until that happens, I think it's better to have a patch for this in our own repo, if it's not too big.

In D9527#238207, @Brecht Van Lommel (brecht) wrote:

We should not rely on an unofficial repository for Embree, see discussion in D8236.

I've heard from Intel that they are open to having ARM in the upstream Embree library, so making that happen is the preferable solution.

As a stopgap solution until that happens, I think it's better to have a patch for this in our own repo, if it's not too big.

The embree-fork seems well maintained to me. It is kept by a company called light-transport, which I don't really know. However, when I asked them to create a github release to ease integration with blender, they were quick to comply. (github issue: https://github.com/lighttransport/embree-aarch64/issues/47 my Linux version using it: https://developer.blender.org/D9505)
What the fork does is use sse2neon headers to convert c-code sse instruction to use the NEON SIMD engine on arm64. This is not a trivial change, and should not be done by a separate patch kept in blender, IMHO.
On linux/arm64 - the performance difference is drastic. I've seen at least 2x faster render with embree. I'm all in favor of Intel adding official arm64/neon support to their repo, but there is a long way between "open to the idea" and actually doing it.

Anyone can try contributing the patch to Embree as well. I'd rather someone makes an effort to solve that technical debt now, rather than having diverging Embree versions and assuming someone else will do it in the future.