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 the intent of automated ROCm-from-source enablement and the state of AMD GPU support today. Concrete versions, package names, and commands for the compute stack are pending and are flagged as such below; this page will state them as current only once they ship in a build.
Status. This is InterGenOS 1.0-dev (build id
v1.0-dev1). Automated ROCm-from-source is the AMD compute backend we are building toward, not part of a current release. What ships today for AMD hardware is the graphics and diagnostics stack described under What ships today. Do not read the compute sections as describing installed software.
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 is the goal that a user with supported AMD hardware does not hand-assemble a compute toolchain. The system detects the GPU, and the ROCm backend is made available through the standard package path — the same pinned, reproducible, signed-mirror path every other package takes — without manual driver surgery. The ambition is that enabling AMD compute is a deliberate install action, not a build project the user has to run themselves.
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 (in the extra
tier) 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 (
radeontopandamdgpu_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. As of 2026-06-15 the tree spans six tiers — toolchain, core, base, desktop, ai, and extra — for roughly 857 packages in total. 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
When the compute stack ships, it 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. You verify the software you are running rather than trusting an unverified claim about it.