ROCm vs vulkan_radv
knowledge base · runtime & backends·reviewed 2026-08-09·suggest an edit ↗
A Strix Halo box can serve the same model two different ways: through
ROCm (AMD’s compute stack) or through vulkan_radv (Mesa’s
open-source Vulkan driver). hal0 picks a lane per slot, and which one is
right depends on what you’re optimizing for.
The short version
Section titled “The short version”- ROCm is faster on prefill and generally the better default when it builds cleanly for your kernel/driver combination.
vulkan_radvneeds nothing beyond the in-tree Mesa driver — no userspace ROCm stack to install or pin — at the cost of slower prefill on long contexts.- Both lanes read from the same GTT pool and the same model weights on disk; switching lanes doesn’t change what’s resident.
Telling which one you’re on
Section titled “Telling which one you’re on”hal0 slots --verboseThe lane column reports rocm or vulkan_radv per slot. The
leaderboard also breaks out
decode/prefill by lane per model, so you can see the actual gap for your
model rather than trusting a rule of thumb.
When to reach for Vulkan
Section titled “When to reach for Vulkan”ROCm’s kernel and firmware requirements move faster than distro
packaging. If a ROCm build won’t come up on your kernel version, hal0
falls back to vulkan_radv rather than failing to serve — that fallback
is deliberate, not a bug. It’s also the simpler starting point if you’re
still validating that the iGPU is visible at all before debugging a
ROCm-specific issue.
Related
Section titled “Related”- Unified memory is not VRAM
- Benchmarks leaderboard — the measured decode/prefill gap per model and lane, not a rule of thumb.