Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

ROCm for AMD (automated from-source)

ROCm is AMD’s open compute stack: the runtime, the HIP programming layer, and the math and acceleration libraries that let AMD Radeon and Instinct GPUs run compute workloads. On InterGenOS, ROCm is the opt-in vendor-tuned backend for AMD hardware, the higher-throughput alternative to the vendor-neutral Vulkan default for local AI inference.

The InterGenOS approach to ROCm is the same approach that runs through the rest of the system: build it from source, pin and checksum every input, and ship something you can verify rather than a vendor binary you have to trust on faith. This page describes automated ROCm-from-source enablement and the state of AMD GPU support today. The compute stack ships now: ROCm 7.2.4, the named HIP/ROCm packages, and llama-cpp-hip (b8796), installed on demand from the mirror.

Status. ROCm 7.2.4 is built from source and available today as the opt-in compute tier — every package in it mirror-only. Nothing in the compute tier is on the installed image; you install it deliberately, and llama-cpp-hip (b8796) is the ROCm inference binary that comes with it. AMD graphics is a separate matter and is on by default — see What ships today.

Why from source

A precompiled compute stack is exactly the kind of opaque shortcut InterGenOS rejects. ROCm is large, it reaches deep into the kernel driver interface, and a binary drop hides how it was built and against what. Building it from source serves the two things that matter here: it keeps the user in control of a machine they understand, can modify, and can trust; and it removes a class of silent failure, because every input is pinned, checksum-verified, and built in deterministic order rather than taken on a vendor’s word.

The same discipline that governs the rest of the build applies. When a compute component fails to build, the cause is fixed in the source tree, not worked around: no disabling a feature to dodge a missing dependency, no stub that pretends to work, no package quietly moved to a different tier to sidestep a wiring problem. A component is trusted only when a clean build reproduces it with zero manual steps, and validation happens on real AMD hardware that reproduces the behavior, never on a hand-patched development box.

What “automated” means

Automated enablement means a user with supported AMD hardware does not hand-assemble a compute toolchain. The system detects the GPU, and the ROCm backend is available through the standard package path — the same pinned, reproducible, signed-mirror path every other package takes — without manual driver surgery. Enabling AMD compute is a deliberate install action, not a build project you have to run yourself.

Because a vendor runtime enlarges the trusted surface of an install, this backend is opt-in and off by default. The default install reasons on the Vulkan backend, which runs across AMD, Intel, and NVIDIA open drivers without a vendor SDK. You choose to add ROCm; you do not have to remove it.

The kernel side of AMD support is already in place. The amdgpu kernel driver and AMD firmware ship in the base image, so the hardware is driven from first boot. The compute stack layers on top of that foundation.

What ships today for AMD GPUs

AMD graphics support is current and on by default. The amdgpu kernel driver and AMD firmware are part of the base image, and Mesa provides the radeonsi OpenGL driver and the radv Vulkan driver for GCN-generation hardware and newer.

Beyond the baseline, InterGenOS provides an amdgpu meta-package (extra tier, mirror-only, so sudo pkm install amdgpu when you want it) that pulls in the user-facing AMD diagnostic and translation tools Mesa does not install on its own:

  • VA-API capability reporting (vainfo)
  • Vulkan capability reporting and a test renderer (vulkaninfo, vkcube)
  • Live GPU monitoring (radeontop and amdgpu_top)
  • VDPAU-to-VA-API translation for legacy applications (libvdpau-va-gl)

This meta-package is a single, transparent install surface for AMD graphics tooling. It does not provide ROCm; the compute stack is a separate concern and is the subject of the rest of this page.

How to read versions and counts

Package counts and tier contents drift between builds. The tree spans seven tiers — toolchain, core, base, desktop, extra, compute, and ai — for over 1,100 package definitions, of which roughly three quarters ship on the installed image and the rest are mirror-only. Treat any number here as a snapshot derived live from the tree, not a permanent figure, and check the current release notes for the authoritative state.

How it is built

The build of the AMD compute stack follows the same lifecycle as every other InterGenOS artifact: pinned, checksum-verified sources compiled in an isolated, reproducible environment, in a fixed phase order, with no silent failures and no stubs. The contributor-facing mechanics of the compute build live in the ROCm-from-Source Build Pipeline reference.

Verification

The compute stack inherits the trust properties of every InterGenOS artifact: pinned and checksum-verified sources, a reproducible build, delivery through a signed package mirror whose index is signed as a whole, and a system image sealed by a signed Secure Boot chain with integrity verification. Because it arrives as ordinary packages, pkm verify re-hashes its installed files exactly as it does for anything else. You verify the software you are running rather than trusting an unverified claim about it.

See also