Repository navigation
ci: add linux/arm64 to buildx matrix for Dockerfile.vulkan #116
Description
Activity
shipped in b6fb04d (initial wire-up) + 60c4a75, 0e2e302, 33e4fca (ubuntu 24.04 deps drift fixups).
what's wired:
- new
llama-vulkanentry in the build-images.yml matrix, buildsDockerfile.vulkanand publishes toghcr.io/itigges22/atlas-llama-vulkan. - conditional platforms:
linux/amd64on dev/main pushes (fast iteration),linux/amd64,linux/arm64on tag pushes (release matrix). - QEMU setup step that only fires for the arm64 build, gated on
startsWith(github.ref, 'refs/tags/v')... amd64-only dev pushes don't pay the QEMU registration cost. - registry-based cache (same pattern as the CUDA llama since GHA cache caps at 10GB total and the vulkan image is several GB).
free-disk-spaceaction now triggers for both llama and llama-vulkan jobs (vulkan image is similarly large during build).
what the fixups untangled (in order):
- 60c4a75: ubuntu 22.04 default vulkan-headers (1.3.204) was too old for current llama.cpp which uses VkPhysicalDevicePipelineRobustnessFeaturesEXT + friends from Vulkan 1.3.246+. Bumped UBUNTU_TAG to 24.04.
- 0e2e302: glslc moved out of glslang-tools into its own package on ubuntu 24.04. Added
glslc. - 33e4fca: SPIR-V namespace (
'spv' has not been declared) neededspirv-headers+spirv-toolsas separate packages on 24.04.
each round took ~5min of CI to surface the next issue... overall lesson:
docker buildx build --checkvalidates Dockerfile syntax but not the actual package availability or compiler header versions. The first real-cold publish IS the only complete test for distro deps drift.validated end-to-end in CI run 26318234746 (all 6 services green including the new llama-vulkan).
on the next tag push (vX.Y.Z) the arm64 image will publish for the first time... mac users on Apple Silicon, Snapdragon X Elite folks, Pi 5 users, arm64 Linux workstation users can pull
ghcr.io/itigges22/atlas-llama-vulkan:X.Y.Zdirectly instead of building locally.closing was auto from the commit trailer in b6fb04d, just adding the actual green-build confirmation here for the record.
- new
Why
#115 added arm64 code paths (arch detection, AMD-on-aarch64 -> vulkan fallback, doctor check_arch) but CI still only runs on
ubuntu-latestwhich is x86_64. Means any future regression in the arm64 code path (a strayif arch == 'x86_64'somewhere, an apt package that doesn't exist on arm64, a python wheel without arm64 build) won't be caught until someone with arm64 hardware reports it.The Dockerfiles that work on arm64 today:
Dockerfile.vulkan— ubuntu + mesa, fully multi-arch readyDockerfile.v31— needs the sbsa/l4t base image swap, harder to test in CI without paying for arm64 runnersDockerfile.rocm— permanently x86_64 only (no AMD arm64 release)so the right scope is: add
linux/arm64to the buildx matrix forDockerfile.vulkanonly, leaving the others alone.Scope
platforms: linux/amd64,linux/arm64to the build-push-action call for the llama service in.github/workflows/build-images.ymlIF a separateDockerfile.vulkanjob exists (currently it doesn't... build-images.yml only builds Dockerfile.v31)atlas-llama-vulkan:dev/:latesttag, then make THAT one multi-archubuntu-24.04-arm, fast but paid)docs/SETUP.md#arm64to point at the prebuilt arm64 image once it's publishedTradeoffs
Dependencies
docs/SETUP.md#arm64