[walcz-de]

feat(build): make the hipblas ROCm package list a build argument

Refs #13109

What

A first, small step towards the ROCm 10 variant discussed in #13109. Nothing changes for existing builds.

For BUILD_TYPE=hipblas the ROCm release already comes from BASE_IMAGE, which is a build argument. What could not be changed was the package list: hipblas-dev hipblaslt-dev rocblas-dev was hardcoded in four places. Those are the ROCm 7.x names. ROCm 10.x ships from AMD's new repository (stable.repo.amd.com/rocm/core), where hipBLAS, rocBLAS and hipBLASLt headers are in one package, amdrocm-blas-dev10.1. So an image on ROCm 10 could not be built without editing the Dockerfiles.

This PR adds a ROCM_PACKAGES build argument. Its default is the current list.

How

• Dockerfile, backend/Dockerfile.python, backend/Dockerfile.golang: ARG ROCM_PACKAGES="hipblas-dev hipblaslt-dev rocblas-dev", used in the existing hipblas apt-get install.
• .docker/install-base-deps.sh: installs ${ROCM_PACKAGES-hipblas-dev hipblaslt-dev rocblas-dev}. If the variable is unset, the default applies. This covers callers that don't forward it.
• The builders that run install-base-deps.sh declare the same ARG and forward it into their existing ENV block, the same way AMDGPU_TARGETS is forwarded: base-grpc-builder, llama-cpp, ik-llama-cpp, turboquant, bonsai and privacy-filter.
• An empty ROCM_PACKAGES installs nothing. This is for a base image that already ships the ROCm development packages, for example rocm/dev-ubuntu-24.04:10.1.0-full. Unlike skipping the whole driver step, the main image still writes amd to /run/localai/capability, so meta backends resolve to their ROCm variants.
• Docs: a short section "Choosing the ROCm release for hipblas builds" in docs/content/getting-started/build.md.

No CI matrix changes are included. See the proposal below.

How tested

I could not run a Docker build for this PR, so all checks are static:

• I extracted the hipblas RUN from the old and new Dockerfile, Dockerfile.python and Dockerfile.golang and ran it under /bin/sh with stubbed apt-get/ldconfig, using the ARG default from the new file. The apt-get calls are identical, and so is the capability file for the main image:
  apt-get update | apt-get install -y --no-install-recommends hipblas-dev hipblaslt-dev rocblas-dev | apt-get clean | ldconfig | capability=amd
• I ran section 6 of install-base-deps.sh (old and new) the same way under bash, with the variable unset and with it set to the default (the ENV path). The output is identical to the old script in both cases.
• An override (amdrocm-blas-dev10.1) shows up in the install call. An empty value gives an install with no packages, followed by ldconfig (and capability=amd in the main image).
• In each changed Dockerfile, the ARG is declared in the same build stage as its use, before the ENV/RUN that reads it.
• As a counter-check, I changed the ARG default in Dockerfile. The comparison then fails.
• bash -n .docker/install-base-deps.sh passes.

On the ROCm 10 side, I read AMD's repository index (stable.repo.amd.com/rocm/core/packages/ubuntu2404). amdrocm-blas-dev10.1 exists and is described as headers for hipBLAS, rocBLAS, hipBLASLt and hipSPARSELt. The rocm/dev-ubuntu-24.04:10.1.0-full image config shows it is built with TheRock's install_rocm_packages.sh (meta packages amdrocm10.1 + amdrocm-core-sdk10.1, apt source left configured).

Downstream, we run LocalAI and its backends on ROCm 10.1 on gfx1151 and gfx1103. That build uses our own base image, not this exact recipe.

Breaking changes

None. Default builds install the same packages in the same order. The only metadata difference: the base-grpc-builder and the llama.cpp-family builder-fromsource stages now carry one more ENV entry (ROCM_PACKAGES), like AMDGPU_TARGETS. The final backend images are FROM scratch and are unaffected. The main image only uses an ARG, so it gets no new ENV.

Not in this PR (follow-ups, if you want the variant)

A ROCm 10 build needs more than the package list. I found these points but did not change them, to keep this PR small:

1. ln -s /opt/rocm-**/lib/llvm/lib/libomp.so /usr/lib/libomp.so (main and python Dockerfiles): ROCm 10 installs under /opt/rocm/core-<version>/. If the glob does not match, ln -s succeeds silently and leaves a dangling link.
2. backend/cpp/llama-cpp/Makefile uses $(ROCM_HOME)/llvm/bin/clang++. TheRock's fallback symlinks cover bin lib include libexec share, but not llvm. Whether the ROCm 10 packages create /opt/rocm/llvm themselves is not verified. Our downstream base adds that symlink.
3. backend/Dockerfile.audio-cpp has its own list (hipblas-dev rocblas-dev hipcub-dev) and is not covered here.
4. Python backends install ROCm PyTorch wheels from their own index. Those bundle their own ROCm, independent of the base image.

Proposal for the matrix (not part of this PR): an additional entry next to -gpu-hipblas in image.yml, and a base-grpc-rocm10-amd64 entry in base-images.yml for the llama.cpp backends:

- build-type: 'hipblas'
  platforms: 'linux/amd64'
  tag-latest: 'auto'
  tag-suffix: '-gpu-hipblas-rocm10'
  base-image: "rocm/dev-ubuntu-24.04:10.1.0-full"
  rocm-packages: ""   # new input of image_build.yml, passed as ROCM_PACKAGES
  runs-on: 'ubuntu-latest'
  makeflags: "--jobs=3 --output-sync=target"
  ubuntu-version: '2404'
  ubuntu-codename: 'noble'

We would bring this in a separate PR, once points 1–2 are sorted out, and only if you want the variant.

Questions

• Is ROCM_PACKAGES a good name, or would you prefer something like HIPBLAS_PACKAGES?
• Would you rather have a version argument (e.g. ROCM_VERSION=10.1) that derives the package names? That needs a branch on the major version in four places. A plain list keeps the Dockerfiles free of version logic.
• If you want the variant: should it cover only the main image and the llama.cpp backend at first?

AI assistance: prepared with Claude Code (see the Assisted-by trailer); reviewed and signed off by me.