AI & Compute

Install ROCm 7.14 on AMD Strix Halo / Ryzen AI Max+

Install and verify ROCm 7.14 with gfx1151 support on a Strix Halo (Ryzen AI Max+) laptop — repository, the amdrocm-core-dev package set, permissions, and rocminfo/HIP/llama.cpp verification.

Updated August 23, 2026Tested with Ubuntu 24.04.4 LTS (noble) · Radeon 8060S (gfx1151) · ROCm 7.14 (amdrocm-core-dev7.14-gfx1151 7.14.0-3) · 6.18.36-061836-generic

Strix Halo (Ryzen AI Max+) exposes its Radeon 8060S iGPU to ROCm through the gfx1151 target (RDNA 3.5). Installing ROCm itself is a normal AMD repository setup; the Strix-Halo-specific part is making sure the gfx1151 package suffixes are actually installed and that verification shows the right agent.

Prerequisites

  • A Strix Halo system with the Radeon 8060S iGPU (gfx1151).
  • Ubuntu 24.04 (noble). The tested machine ran Ubuntu 24.04.4 LTS.
  • The stock kernel amdgpu driver — do not install AMD’s DKMS driver for this workflow. The tested machine used the distro kernel driver as-is (6.18.36-061836-generic); no newer kernel was required or claimed as a minimum.
  • Your user must be in the video and render groups — check with id. If you are missing one: sudo usermod -aG render $USER (same for video), then log out and back in. The tested user was already a member of both.
  • No BIOS changes were needed for this install. The tested machine boots with pre-existing kernel command-line parameters (iommu=pt, amdgpu.gttsize=131072, TTM limits); ROCm installed and ran without touching them. See Strix Halo memory & GTT reference before changing any of those.
  • Disk: the measured 7.13 → 7.14 transition changed used disk space by about 2 GB net (measured with df -h / before and after). A first-time install is larger than a same-size upgrade.

Migrating from an older ROCm (tested: 7.13 → 7.14)

If you previously installed ROCm 7.x through AMD’s repo or the amdgpu-install helper, remove it before adding the new repository — otherwise the old repo files and pins keep interfering.

# Remove the old package roots, then let apt clean up
sudo apt autoremove

# Verify nothing 7.13 remains (both should print nothing):
apt list --installed 2>/dev/null | grep -E 'amdrocm.*7\.13'
apt-mark showmanual | grep -E '^amdrocm.*7\.13'

# Remove leftover generated cache directory from the old install
sudo rm -rf /opt/rocm/core-7.13

# Remove old AMD/ROCm repo configuration and pins
sudo rm -f /etc/apt/sources.list.d/amdgpu.list
sudo rm -f /etc/apt/sources.list.d/rocm.list
sudo rm -f /etc/apt/sources.list.d/rocm.list.dpkg-dist
sudo rm -f /etc/apt/preferences.d/repo-radeon-pin-600
sudo rm -f /etc/apt/preferences.d/rocm-pin-600

# Remove the helper that installed them
sudo apt purge -y amdgpu-install

# Reset apt state
sudo rm -rf /var/cache/apt/*
sudo apt clean
sudo apt update

The important decision in this section: keep the existing amdgpu kernel driver and avoid amdgpu-dkms.

Repository configuration

Add AMD’s GPG key and the Ubuntu 24.04 repository (commands in the Quick answer). Then confirm the package set is visible before installing:

apt-cache policy amdrocm7.14-gfx1151

Observed candidate on the tested machine: 7.14.0-3.

Install

One package is the entry point; apt pulls the rest of the set as dependencies:

sudo apt install amdrocm-core-dev7.14-gfx1151
sudo reboot

The installed amdrocm-* set on the tested machine (measured with dpkg -l, all at 7.14.0-3):

amdrocm-amdsmi7.14                    7.14.0-3
amdrocm-base7.14                      7.14.0-3
amdrocm-blas-dev7.14                  7.14.0-3
amdrocm-blas-host7.14                 7.14.0-3
amdrocm-blas7.14-gfx1151              7.14.0-3
amdrocm-ccl-dev7.14                   7.14.0-3
amdrocm-ck7.14                        7.14.0-3
amdrocm-core-dev7.14-gfx1151          7.14.0-3
amdrocm-core7.14-gfx1151              7.14.0-3
amdrocm-debugger7.14                  7.14.0-3
amdrocm-decode-dev7.14                7.14.0-3
amdrocm-decode7.14                    7.14.0-3
amdrocm-dnn-dev7.14                   7.14.0-3
amdrocm-dnn-host7.14                  7.14.0-3
amdrocm-dnn7.14-gfx1151               7.14.0-3
amdrocm-fft-dev7.14                   7.14.0-3
amdrocm-fft-host7.14                  7.14.0-3
amdrocm-fft7.14-gfx1151               7.14.0-3
amdrocm-hipblas-common-dev7.14        7.14.0-3
amdrocm-hipfile-dev7.14               7.14.0-3
amdrocm-hipfile7.14                   7.14.0-3
amdrocm-hipify7.14                    7.14.0-3
amdrocm-jpeg-dev7.14                  7.14.0-3
amdrocm-jpeg7.14                      7.14.0-3
amdrocm-llvm-dev7.14                  7.14.0-3
amdrocm-llvm7.14                      7.14.0-3
amdrocm-math-common7.14               7.14.0-3
amdrocm-opencl-dev7.14                7.14.0-3
amdrocm-opencl7.14                    7.14.0-3
amdrocm-profiler-base7.14             7.14.0-3
amdrocm-rand-dev7.14                  7.14.0-3
amdrocm-rand-host7.14                 7.14.0-3
amdrocm-rand7.14-gfx1151              7.14.0-3
amdrocm-rccl-dev7.14                  7.14.0-3
amdrocm-rccl-host7.14                 7.14.0-3
amdrocm-rccl7.14-gfx1151              7.14.0-3
amdrocm-rocshmem-dev7.14              7.14.0-3
amdrocm-rocshmem7.14                  7.14.0-3
amdrocm-runtime-dev7.14               7.14.0-3
amdrocm-runtime7.14                   7.14.0-3
amdrocm-solver-dev7.14                7.14.0-3
amdrocm-solver-host7.14               7.14.0-3
amdrocm-solver7.14-gfx1151            7.14.0-3
amdrocm-sparse-dev7.14                7.14.0-3
amdrocm-sparse-host7.14               7.14.0-3
amdrocm-sparse7.14-gfx1151            7.14.0-3
amdrocm-sysdeps7.14                   7.14.0-3

Notes from the tested machine:

  • Layout. ROCm installs to a versioned root with compatibility links — use the generic paths for everyday commands:

    /opt/rocm/core-7.14            actual install
/opt/rocm/core-7 -> /etc/alternatives/core-7
/opt/rocm/bin    -> /etc/alternatives/rocm-bin
/opt/rocm/lib    -> /etc/alternatives/rocm-lib

  • Unrelated package present. The tested machine also carries Ubuntu’s own rocm-opencl (the noble OpenCL ICD loader). It is not part of the amdrocm-* set and was left in place; ROCm verification does not depend on it.

Shell environment

Add to ~/.bashrc (or your shell equivalent) so rocminfo, hipconfig, hipcc etc. resolve without full paths:

# ROCm 7.x
export ROCM_PATH=/opt/rocm
export HIP_PLATFORM=amd
export PATH="$ROCM_PATH/bin:$PATH"
export LD_LIBRARY_PATH="$ROCM_PATH/lib:${LD_LIBRARY_PATH:-}"

Two things to keep out of ~/.bashrc:

  • The per-project compiler wiring (HIPCXX, HIP_PATH) belongs in the build script of the project that needs it.
  • GPU_TARGETS is a CMake argument for the build, not an environment variable — pass it to CMake per build instead of exporting it globally.

Verification

rocminfo — GPU agent present with gfx1151

/opt/rocm/bin/rocminfo | grep -A12 -B5 gfx1151

Observed (trimmed):

  Name:                    gfx1151
  Marketing Name:          AMD Radeon 8060S Graphics
  Feature:                 KERNEL_DISPATCH
  Profile:                 BASE_PROFILE
  Device Type:             GPU
  ISA:                     amdgcn-amd-amdhsa--gfx1151

The CPU node (AMD RYZEN AI MAX+ 395) and the NPU node (aie2p / RyzenAI-npu5) also appear in rocminfo; the agent you care about for ROCm compute is the gfx1151 GPU entry above.

HIP runtime and compiler

/opt/rocm/bin/hipconfig --version
/opt/rocm/bin/hipcc --version

Observed:

7.14.60850-0000000

HIP version: 7.14.60850-0000000
AMD clang version 23.0.0git
Target: x86_64-unknown-linux-gnu
InstalledDir: /opt/rocm/core-7.14/lib/llvm/bin

These version checks confirm the toolchain is in place; the first real compile-and-run is the llama.cpp build below, which is the stronger proof.

Kernel driver still in use

ROCm on Linux rides on the kernel amdgpu driver — confirm you did not end up on a DKMS variant:

lspci -nnk | grep -A4 -Ei 'display|vga'

Observed:

Kernel driver in use: amdgpu
Kernel modules: amdgpu

llama.cpp with HIP

Build llama.cpp against this ROCm install (full build script and flags in Run llama.cpp on Strix Halo). Dependencies installed for the tested build:

sudo apt install -y build-essential cmake git ninja-build pkg-config libssl-dev libgomp1

After building, confirm two things with the CLI itself: which devices it sees and which build it is.

./build-rocm/bin/llama-cli --list-devices
./build-rocm/bin/llama-cli --version

Observed output on the tested machine:

$ ./build-rocm/bin/llama-cli --list-devices
Available devices:
  ROCm0: AMD Radeon 8060S Graphics (131072 MiB, 83680 MiB free)

$ ./build-rocm/bin/llama-cli --version
version: 0.2.0-dev (build 10603, commit c060ca974)
built with GNU 14.2.0 for Linux x86_64

Two things to read out of that output:

  • Device: ROCm0 is the Radeon 8060S. The 131072 MiB figure is the shared-memory (GTT-aperture) view of system RAM, not discrete VRAM — and the free number varies with whatever else is running. What these figures mean on this hardware: RAM, GTT and GPU memory.
  • Build: 10603 / c060ca974 matches the retained benchmark JSONs exactly (build_commit, build_number) — this is provably the same binary that produced the ROCm vs Vulkan numbers.

End-to-end check: run a real benchmark

The commands below are what was executed on the tested machine to produce the ROCm numbers on the ROCm vs Vulkan page — and they double as the reproduction recipe. MODEL is the path from the tested machine; point it at any GGUF you have and keep everything else byte-identical:

MODEL="/home/user/models/Qwen3.8/Qwen3.8-27B-Q8_0.gguf"

mkdir -p benchmark-results

./build-rocm/bin/llama-bench \
  -m "$MODEL" \
  -ngl 999 \
  -p 512,2048,8192 \
  -n 128 \
  -b 2048 \
  -ub 512 \
  -fa on \
  -r 5 \
  -o json \
  > benchmark-results/rocm-7.14.json

./build-rocm/bin/llama-bench \
  -m "$MODEL" \
  -ngl 999 \
  -pg 2048,256 \
  -b 2048 \
  -ub 512 \
  -fa on \
  -r 5 \
  -o json \
  > benchmark-results/rocm-7.14-pg2048-256.json

Each invocation self-exits and writes one JSON per test set (per-test timings, 5 repetitions). Both completed without error on the tested machine; the retained files are on record via the benchmark page. For byte-identical numbers, build from llama.cpp at commit c060ca974.

Common failures

Not encountered during testing: the documented 7.13 → 7.14 migration, install, and verification steps completed without failure on the tested machine.

Sources and upstream documentation