@Stefan Werner (swerner) - I added you as reviewer here because I saw your work enabling MAC/arm builds. I hope that's O.K.

These patches enable both "make deps" and install_deps.sh script support for linux/arm64 architecture, and allow building linux/arm64 with embree-aarch64 support.
They were tested on ubuntu 20.10, for both x86 and arm64 architectures (install_deps.sh requires a small workaround in both arm64 and x86 to use clang-9 for OSL, but that seemed out-of-scope)

Please let me know if any clarification is needed.

Thank you!
Tsahi.

Thanks everyone for the responses!

In D9505#238694, @Sybren A. Stüvel (sybren) wrote:

disable by default usd, ispc, openimagedenoise

Why were these disabled?

All these libraries are intel-only, with specific intel-SSE usage that does not compile for arm64.
ispc and openimagedenoise are also disabled for MAC/arm64. USD only depends on intel for linux.. I'm hoping to change that soon.

In D9505#238574, @Bastien Montagne (mont29) wrote:

Am not especially thrilled to have to deal with two code paths in install_deps for a single lib... main question here for me is, if arm64 need Embree 3.12, can't we switch whole Blender deps to that version of Embree?

The embree-fork actualy builds from a different repository, not just a different version. I'll try to converge the build, as I did in the cmake-path.

In D9505#238640, @Ray Molenkamp (LazyDodo) wrote:

Overall there seems to be very little consideration for other platforms and various arbitrary changes.

Also i have to admit, I'm not entirely convinced that burdening this build script with platforms we our selves have no intention of shipping in the near future is a direction i'm particularly fond of

There are some arbitrary changes I'll remove, but package version changes were generally not arbitrary. quoting an in-code response:
I have upgraded any package which didn't support linux/aarch64 out of the box, when the new version does support it out-of-the-box (or close to it).
I realize this might seem arbitrary and messy. I did try to separate packages to their own commits, but I don't see a way to even browse the change by commit. Is there a better way to upload such a bunch of commits, that are mostly indipendant though all are working towards the same goal?

I hope arm64/linux will become important with the rise of arm/MAC on personal PCs and Graviton2 in AWS instances.
There is already work being done in blender for arm64/MAC, and my first goal in this patchset is to remove the underlying assumption that arm64 is MAC-only.

embree.diff is not included in the patch? If this is not too complicated, I'm still hoping we can contribute this upstream rather than maintain it ourselves.

As a general comment on this patch, I think it's up to platform maintainers to decide if they want to accept arm64 support here. Personally I think it's realistic that we will need to officially support arm64 on Linux/Windows at some point in the next few years, and making the code a bit more generic does not hurt, so it makes sense to have this working. But I also think that we are not in a rush, and can wait for upstream to get fixes rather than doing patching on our side, to keep the maintenance easier.

In D9505#240970, @Brecht Van Lommel (brecht) wrote:

As a general comment on this patch, I think it's up to platform maintainers to decide if they want to accept arm64 support here. Personally I think it's realistic that we will need to officially support arm64 on Linux/Windows at some point in the next few years, and making the code a bit more generic does not hurt, so it makes sense to have this working. But I also think that we are not in a rush, and can wait for upstream to get fixes rather than doing patching on our side, to keep the maintenance easier.

👍 That sounds very reasonable to me.

In D9505#241710, @Sybren A. Stüvel (sybren) wrote:

In D9505#240970, @Brecht Van Lommel (brecht) wrote:

As a general comment on this patch, I think it's up to platform maintainers to decide if they want to accept arm64 support here. Personally I think it's realistic that we will need to officially support arm64 on Linux/Windows at some point in the next few years, and making the code a bit more generic does not hurt, so it makes sense to have this working. But I also think that we are not in a rush, and can wait for upstream to get fixes rather than doing patching on our side, to keep the maintenance easier.

👍 That sounds very reasonable to me.

Seems reasonable to me as well. There was actually very little patching external dependencies other than just pulling up-to date versions.
As I said, my first goal is to remove the underlying assumption that only MACs can be ARM64, or that embree can only be in intel systems. I'd be happy to agree on what should go to such a patch.

I think these could be done to prepare for a future arm64/linux, without adding any maintenance burden:

• fixes in util_defines.h and bvh_embree.h
• the new ARCH_ARM64 cmake constant in dependencies (switching some APPLE AND ..)
• theora patch - theora does not seem like it will ever be updated. It curretly has a patch fixing config.guess/config.sub for arm64/MAC, I think it stands to reason to add arm64/linux support in the same place
• boost - removing architecture=x86 flag on arm
• install_deps scrupt - checking ARCH, fixing flags for LLVM and OSL
• sqlite update - just updates a version, and actually removes a now-unnecessary patch

These are less trivial, but the gain might justify the cost:

• ssl update - it does include patching a version for arm64 compatibility. However, the patch does come from upstream ssl and will be included in the next ssl version. Also, ssl.conf changes will be needed and I'd be happy to get them in early.
• embree-aarch64 fork - I should have an available M1 system finally, so I think I could deliver a patch for both linux and MAC.

I can leave out other fixes I did:

• pugixml on openimageio fixes
• tbb updates (inc. tbb harvest)

A partial patch will not be enough to add support for arm64, but it. will get us in the right direction. Which parts would you like to see on a partial patch? The entire first group? Anything else?

Thank you!
Tsahi.

does this build easily on a https://developer.nvidia.com/embedded/jetson-agx-xavier-developer-kit ?

In D9505#279899, @Jacob Merrill (blueprintrandom) wrote:

does this build easily on a https://developer.nvidia.com/embedded/jetson-agx-xavier-developer-kit ?

Hi. I have jetson nano and made a self build with v283, v292.
I had not used this build, but you would build easier with xavier too that disabling embree (WITH_CYCLES_EMBREE OFF in CMakeLists.txt) and usd-1.9.11 (install_deps.sh --skip-usd) (with blender-v2.83-release tag), disabling SSE2 of OIIO, OCIO and OSL in install_deps.sh,
and if when blender-v2.83-release tag, modify blender-deps/c-blosc-1.5.0/blosc/shuffule.h with below,

#about c-blosc, add in install_deps.sh
	sed -i "s/unsigned char\*/uint8_t*/g" $_src/blosc/shuffle.h
	sed -i "s/const uint8_t\*/uint8_t*/g" $_src/blosc/shuffle.h
	sed -i "s/\(\/\* Shuffle\/unshuffle routines \*\/\)/#include <stdint.h>\n#include <inttypes.h>\n\n\1/g" $_src/blosc/shuffle.h

and, after did install_deps.sh -t 4 --no-confirm --with-opencollada --skip-usd,

# with blender-v2.83-release tag
touch ./blender/release/datafiles/locale/languages # This is a skip. I don't know why I faced this.

before build bin/blender.
and do make following BUILD_NOTES.txt.

build result (in jetson nano):

takahiro@jetson:~/document/source/blender/blender-283-build-20210412/build_linux/bin$ uname -a
Linux jetson 4.9.140-tegra #1 SMP PREEMPT Tue Nov 5 13:43:53 PST 2019 aarch64 aarch64 aarch64 GNU/Linux

takahiro@jetson:~/document/source/blender/blender-283-build-20210412/build_linux/bin$ pwd
/home/takahiro/document/source/blender/blender-283-build-20210412/build_linux/bin

takahiro@jetson:~/document/source/blender/blender-283-build-20210412/build_linux/bin$ ls -l blender
-rwxrwxr-x 1 takahiro takahiro 79945304  4月 16 19:51 blender

takahiro@jetson:~/document/source/blender/blender-283-build-20210412/build_linux/bin$ file blender
blender: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=d727475416a34b3e3c714b4391eb552464d569cd, not stripped

note: cmake v3.18 later built from source.