Compiling for Arm64?

Feature request - can you guys compile it for arm64 (aka, Mac M1) architecure as well? I don’t know if this is feasible, but as docker now has at least a M1 beta it might be something relatively easy to implement.


I personally don’t have a M1 Mac to test with. Maybe you can help us by opening a pull request?

1 Like

New to github and your compiling scheme, I do have a M1 to test though. Basically it seems docker pulls the amd64 and then it fails on trying to run a job (likely simd instruction stuff).

I’ll try to figure it out when I have some more time, though - thanks!

looks like Getting started with Docker for Arm on Linux - Docker Blog is the relevant documentation so adding another architecture to the build is via that.

1 Like

I’m a beginner.
Have you tried to use docker’s experimental function buildx to build images? This seems to support multi-architectured platforms.

1 Like

I haven’t tried. Perhaps you could try and report back your findings?

1 Like

A great (small?) place to start might just be NodeODM. I am able to start NodeODM on docker and my Intel Mac is able to connect to the Node but when I try to process something I get Unsupported CPU.

I am a beginner but a few things I have seen:

When starting NodeODM in docker:

% docker run -d -p 3000:3000 opendronemap/nodeodm WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested 2d253154d76e12f325ec9f7c819cfbe47ae5acaf85e1d70a599563e49a90b94c

What is visible in Docker:

`info: Authentication using NoTokenRequired`
`info: Listening on UDP for progress updates`
`info: No tasks dump found`
`info: Checking for orphaned directories to be removed...`
`info: Server has started on port 3000`
`info: About to run: /code/ --ignore-gsd --pc-quality high --dsm --dem-resolution 2 --orthophoto-resolution 2 --project-path /var/www/data 08a7de42-b6dd-42c4-8f59-f46156080915`
`warn: undefined {"errno":-2,"code":"ENOENT","syscall":"open","path":"data/08a7de42-b6dd-42c4-8f59-f46156080915/images.json"}`

What WebODM returns from an Intel machine connecting to an M1 node:

qemu: uncaught target signal 4 (Illegal instruction) - core dumped
/code/ line 5:   184 Illegal instruction     python3 $RUNPATH/ "$@"

Happy to support in testing but afraid I am very much a beginner as well.

1 Like

What I learned so far:

  1. The postgres container in WebODM/db is based on postgres 9.5. Back then there weren’t any multi-arch containers, so the DB container won’t run on Apple Silicon. Updating it to postgres 13 and also increasing the POSTGIS_MAJOR release from 2.3 to 3 seems to work, though. Unfortunately, the database somehow changed, so that the combination of the new database and the used PROJ release don’t match. There is still some work to do to figure out what causes the incompatibilities between them.
    See Running WebODM on Apple Silicon M1 fails · Issue #997 · OpenDroneMap/WebODM · GitHub for details on that.
  2. OpenSfM, which is used by NodeODM, is also not ready for Apple Silicon. It relies on SSE2 instruction.
    See Build fails on M1 Mac · Issue #766 · mapillary/OpenSfM · GitHub for details.
    1. One way is to disable SSE2 completely for OpenSfM, which, however, will result in performance losses.
    2. The alternative is to adapt the SSE2 calls to NEON.
      Unfortunately, clang and gcc have a different interpretation of the SSE2 standard. With gcc, it’s not just replacing emmintrin.h by sse2neon.h, because some SSE2 intrinsics are called with non-constant values, which gcc rejects. clang on the other hand is not that picky with SSE2 intrinsics. But this behavior reduces performance, as the one-cycle sse2 ops need a three-cycle load op when they are called with a variable. At least that is what I learned today. Nevertheless, using clang can result in still faster code than disabling SSE2 completely.

I opted for disabling SSE2 completely to make progress on finding more things that need to be addressed. There is still time for optimization once it is running at all :wink:



That’s incredible detective work!

Could you do me a solid, and feel 100% free to just ignore me because I have no right to ask anything of you :rofl:, but would using GeoPackage as our datastore help with the PGSQL issues you’ve noted above?

For background, I think it’s an incredible product, and I like the idea of dropping heavy/big dependencies, and I figure since we use it elsewhere and SQLite runs on toasters now it may make further ports easier.

Take this with a truckload of salt since I can’t program worth anything.

Hmm, I don’t think I can form an opinion about this. I’m pretty new to ODM, digging around for just a few days, and I even don’t know GeoPackage at all. So I fear I’m not the one who could share any meaningful insights on that topic.