Set Up Vulkan Compute on AMD Strix Halo / Radeon 8060S

On Strix Halo, graphics Vulkan works out of the box — compute is where you check things properly, because llama.cpp’s Vulkan backend depends on compute pipelines and on the shared-memory/GTT path rather than discrete VRAM. This page separates what is normal driver behavior from what needs verification, and it documents the exact userspace stack that was tested.

The stack, layer by layer

Install

Steps 1–3 of the Quick answer, with what was observed on the tested machine:

sudo apt update
sudo apt install -y software-properties-common
sudo add-apt-repository -y ppa:kisak/kisak-mesa
sudo apt update

sudo apt install -y mesa-vulkan-drivers
sudo apt install -y libvulkan-dev vulkan-tools glslc spirv-tools spirv-headers

Observed after install: mesa-vulkan-drivers 26.1.7~kisak1~n from https://ppa.launchpadcontent.net/kisak/kisak-mesa/ubuntu. Stock Ubuntu 24.04 had an older Mesa package available at the same time — the PPA is what makes this a current RADV build. Because the PPA supersedes stock for all of its Mesa packages, the whole GL/Vulkan stack on the machine is at the same 26.1.7~kisak1~n revision (libgl/libegl/mesa-libgallium et al.).

The supporting dev/tooling packages (libvulkan-dev, libvulkan1, vulkan-tools, glslc, spirv-tools, spirv-headers) came from normal Ubuntu repositories, not the PPA. Observed versions:

mesa-vulkan-drivers   26.1.7~kisak1~n        (kisak-mesa PPA)
libvulkan-dev         1.3.275.0-1build1      (Ubuntu)
libvulkan1            1.3.275.0-1build1      (Ubuntu)
vulkan-tools          1.3.275.0+dfsg1-1      (Ubuntu)
glslc                 2023.8-1build1         (Ubuntu)
spirv-tools           2025.1~rc1-1~ubuntu0.24.04.2
spirv-headers         1.6.1+1.4.309.0-1~ubuntu0.24.04.2

Confirm the source with:

apt-cache policy mesa-vulkan-drivers

Expect Installed/Candidate at the PPA version with the kisak-mesa launchpad URL in the origin list.

Verification

vulkaninfo — device visible under RADV

vulkaninfo --summary

Observed (trimmed):

GPU0:
	apiVersion         = 1.4.354
	driverVersion      = 26.1.7
	deviceName         = Radeon 8060S Graphics (RADV STRIX_HALO)
	driverID           = DRIVER_ID_MESA_RADV
	driverName         = radv
	driverInfo         = Mesa 26.1.7 - kisak-mesa PPA

A second device, llvmpipe (Mesa’s CPU software Vulkan implementation), also appears in vulkaninfo. That is normal — it is not the device you want; llama.cpp benchmarking must run on the Radeon GPU.

Compact re-check without the full dump:

vulkaninfo 2>/dev/null | grep -E 'deviceName|driverName|driverInfo|apiVersion' | head -30

The device’s memoryHeaps (captured 2026-08-24): two heaps — 43.00 GiB (no flags) and 86.00 GiB (one flag, name not yet recorded) — with live budget/usage fields that move with system load. The heap sizes sum to 129 GiB, which reconciles exactly with the kernel’s 128 GiB GTT + 1 GiB visible VRAM aperture: same physical memory, re-sliced by RADV. Full explanation alongside the other measured figures in RAM, GTT and GPU memory on Strix Halo.

Kernel driver unchanged

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

Observed — proves the PPA changed the userspace stack, not the kernel:

Kernel driver in use: amdgpu
Kernel modules: amdgpu

Build llama.cpp with Vulkan

Tested build script (build-vulkan.sh at the root of a cloned llama.cpp):

#!/usr/bin/env bash
set -euo pipefail

# Run from the root of the llama.cpp repository.

rm -rf build-vulkan

cmake -S . -B build-vulkan   -G Ninja   -DGGML_VULKAN=ON   -DCMAKE_BUILD_TYPE=Release

cmake --build build-vulkan -j"$(nproc)"

No extra flags were needed for this hardware. The same-commit requirement for the benchmark is satisfied: the retained Vulkan llama-bench JSON reports build_commit c060ca974 (build_number 10603) — identical to the ROCm build — and confirms the device it ran on.

Runtime device selection

With one real GPU plus llvmpipe, selection is automatic — confirmed from the retained benchmark JSON: devices: auto, with the run attributed to Radeon 8060S Graphics (RADV STRIX_HALO) on the Vulkan backend. No flag or environment variable was needed to force the device on this machine.

Shared/GTT memory behavior

llama.cpp will report the device’s “VRAM” as a large shared-memory figure. That is the GTT aperture, not discrete RAM — allocate with headroom for the OS and other processes, and remember reported capacity is not usable capacity. Full explanation and measured examples: RAM, GTT and GPU memory on Strix Halo.

Common failures

Not encountered during testing: the documented PPA install, verification, and driver-state checks completed without failure on the tested machine. If vulkaninfo shows no AMD device at all, the first things to check are the kernel amdgpu module state (lsmod | grep amdgpu) and that the kernel is a recent distro release rather than a custom build without iGPU support.

Sources and upstream documentation

• Kisak Mesa PPA — the repository the tested mesa-vulkan-drivers packages come from.
• Mesa RADV driver documentation — the Vulkan driver this machine runs.
• llama.cpp repository — GGML_VULKAN build options and Vulkan prerequisites.