[FEATURE] Provide arm64 versions of the Docker images

[dmohns]

Is your feature request related to a problem? Please describe.
Currently, all KiBot docker images are provided for amd64 platform. For users on arm64 platforms this requires to run the docker images using emulation, i.e. QEMU or Rosetta2 (in case of MacOS). This does work most of the time, but is not very performant and occasionally run into strange errors related to architecture, which are hard to debug for the average developer and user of KiBot.

I understand that this is not very relevant for the CI/CD use-case right now, as almost all runners are on amd64 platform. However, arm64 is on the rise for Desktop environments and KiBot helps tremendously to reproducibly generate documentation and production files in projects with multiple contributors (using different OS'es).

Describe the solution you'd like
All Docker images are provided in amd64 as well as arm64 platform. When the Docker images are run on arm64 no emulation is needed and native performance can be utilised.

Describe alternatives you've considered
Running KiBot with emulation. See above

Additional context

• There is already a similar comment here: Add support for arm64 architecture kicad_auto#14 But I felt it would be better suited as a discussion in this repo. Please feel free to close my issue as duplicated, if the linked issue is enough to track the feature.
• I already did some experiments of building the Docker image chain on arm64. With a few modifications to the Docker files I was able to run everything expect for Blender. I can share results if this is insightful.

[set-soft]

Hi @dmohns !

At first sight it looks like too much work is needed. So I'm not sure about it.

The first step should be to add KiAuto packages for ARM64 arch. This means we must create Debian packages of KiAuto for both architectures. Without this KiAuto won't use the interposer and the KiCad GUI manipulation will be unreliable.

With the current KiAuto package I think the best will be to add a cross-compiled libinterposer.so. But again, a lot of work to just bust the speed on a minority of machines.

Even trying to make a "draft", that just uses the old GUI manipulation mechanism, it implies doubling the storage, bandwidth, etc. of the images build. Not to mention that buildx likes to need a lot more resources and complicate the setup a lot. This is because it uses docker images for things that the standard build just uses the OS installed tools.

If you are patient we could try to explore it and see the results. Did you build the "base_os" images for ARM?

[dmohns]

Hey @set-soft

Great! Thanks for the explanation. I wasn't even aware about the KiAuto dependency and libinterposer.so.

I understand that it takes a lot of effort and not gonna happen anytime soon, as it's super relevant right now (even for my own use-case Rosetta2 is decent enough).

None-the-less, I would be more than happy to support on exploring the idea of having arm images sometime in the future.

If you are patient we could try to explore it and see the results. Did you build the "base_os" images for ARM?

Yes, with a few modification the base images built. Essentially I needed remove/change all Debian packages that don't provide arm64

• Changed rar -> unrar here
• The Ubuntu PPA for KiCad doesn't provide arm64 either. However, I noticed that Debian Bookworm-Backport repo has arm64 version, so I changed to use that. Changing kicad to kicad/backport here

I struggled to get a working (up-to-date) version of Blender. Here is what I tried

• Using the Debian Bookworm version (3.4). Seems to outdated to proper function with some of the KiCad scripts
• Installing the Provided version by blender. Well... it's an amd64 so obviously it didn't work
• I even changed the entire build chain to use Debian-Sid instead of Debian-Bookworm. This did make KiCad scripts work, but it fails at a later step with some opague "Build without OpenDenoiser" warnings, which I figured was beyond my knowledge to debug 😉

I then postponed the attempt of getting Blender to run 🙈

[set-soft]

If you are patient we could try to explore it and see the results. Did you build the "base_os" images for ARM?

Yes, with a few modification the base images built. Essentially I needed remove/change all Debian packages that don't provide arm64

• Changed rar -> unrar here

Ok, we should see a mechanism to just skip it for ARM, unrar only uncompress, and what we need is to compress. But is completely optional.

• The Ubuntu PPA for KiCad doesn't provide arm64 either. However, I noticed that Debian Bookworm-Backport repo has arm64 version, so I changed to use that. Changing kicad to kicad/backport here

Interesting looks like Debian is catching-up.

I struggled to get a working (up-to-date) version of Blender. Here is what I tried

• Using the Debian Bookworm version (3.4). Seems to outdated to proper function with some of the KiCad scripts
• Installing the Provided version by blender. Well... it's an amd64 so obviously it didn't work
• I even changed the entire build chain to use Debian-Sid instead of Debian-Bookworm. This did make KiCad scripts work, but it fails at a later step with some opague "Build without OpenDenoiser" warnings, which I figured was beyond my knowledge to debug 😉

I then postponed the attempt of getting Blender to run 🙈

From what I understand the Debian packages are only usable with hardware acceleration, otherwise they are useless.

This is because the Debian maintainer has a strict understanding of Debian guidelines and refuses to include the Intel OpenDenoiser lib. I think he's wrong. The problem is like this: Intel people needed some functionality found in another lib, so they took this lib (free software) and heavily modified it for their own needs. The modifications can't be incorporated to the original lib because they are too specific to OpenDenoiser. So Intel people is including the code in the OpenDenoiser code base. As they don't plan to incorporate the changes to the upstream the Debian policy forbids the incorporation of OpenDenoiser. But the point is that the changes are changing the third party lib in a way that the upstream will never accept them. End result: OpenDenoiser can't be packaged according to the Blender Debian package maintainer. I see this ridiculous.

You may ask: is OpenDenoiser really important? Well just try to render something using the CPU, you'll need a lot of time per render pass. In 10 passes you'll get a very noisy image, you'll need something like 100 passes to get rid of the ray tracing noise. In a test I did with a simple board it took 40 minutes. But using OpenDenoiser you can just do 10 passes and then apply OpenDenoiser, you get a good approximation for the 100 passes result. Suddenly you went from 40 to 4 minutes. So yes, OpenDenoiser is critical if you don't have access to a hardware accelerator, which is the normal case for a regular CI/CD server.

This is why I'm not using the Debian package in the docker images, is a pity because I'm wasting around 640 MiB (from a 3.3 GiB total) because I'm forced to use the official Blender tarball.

All of this makes me wonder: What's the OS you are using? Are you using macOS? Perhaps we don't really need docker images for ARM64, but better native support for macOS. KiCad and Blender are available for macOS, and Darwin is a UNIX BSD system, so I don't see why KiBot couldn't run natively on macOS.

[dmohns]

Thanks for the long and detailed reply! It's is very insightful.

I wasn't expecting this to be license related 😢
I get their points, but it is a bit sad to see these causing issues.

All of this makes me wonder: What's the OS you are using? Are you using macOS? Perhaps we don't really need docker images for ARM64, but better native support for macOS. KiCad and Blender are available for macOS, and Darwin is a UNIX BSD system, so I don't see why KiBot couldn't run natively on macOS.

My reasoning for this is actually two-folded.

Running KiBot on MacOS (with newer Macs)

We would like our projects to be as open and easy to contribute to as possible (of course there will be some limits to that).
For this I would like them to be OS-agnostic.

My idea here was to provide Makefiles that does all the rendering, production files etc.. in a consistent way.
So developers can focus on PCB designs.
Using the docker images here is very tempting, developers can just use docker run and all the magic happens in the background. No need to fiddle with installation instructions.

I, personally, use MacOS on ARM64 (which is true for all newer Macs).
Running the AMD64 docker image using compatibility layer (Rosetta2) is good enough for me.
Having to run KiBot natively would be a nice to have, but isn't really required to gain all the massive benefits from KiBot.

Running KiBot on ARM in general

However, ARM seems to be picking up speed in the cloud computing world.
Major Cloud providers are already offering ARM-based instances at a much cheaper rated due to their increased energy efficiency.

People can use (and are already using) that to run Github Actions on Self-hosted runners.
Who knows, maybe one day, Github Actions will run on ARM by default.

TL;DR

(I think this applies for any project) If the project can be built and released in a infrastructure agnostic way without a major overhead, it's generally speaking a good and future proof idea to do that.

In our case it looks like the overhead is massive, so it is probably something to just keep in the back of our heads for now and post-pone to the future, when it's actually getting relevant.