TL;DR: AMD published HRX (HIP Runtime eXtended) Loom v0.1, an early-access alternative runtime and compiler living inside the ROCm org that targets Radeon/Ryzen/Instinct GPUs, XDNA NPUs and x86 CPUs from one programming model — with a HIP compatibility layer that routes existing HIP binaries through it without relinking.
The Catalyst
HRX is not a feature bolted onto ROCm; it is a parallel implementation of the runtime, compiler and library stack, built on IREE and shipped as two repos. ROCm/hrx-system provides libhrx plus a libamdhip64.so compatibility shim and the Loom compiler, which accepts Loom ASM and a customized C++ dialect. ROCm/hrx-solutions ships worked solutions: a loom-serve LLM stack carrying a Qwen3.5-0.8B pipeline bytecode module and Moonshine streaming ASR, wired to Pi, OpenCode 2 and Open WebUI, with a loom-control CLI and TUI. AMD states plainly that this is "not an official component within the ROCm stack" and is "being evaluated for inclusion in ROCm". Release artifacts are x86_64 Linux/Windows only, the native build is Bazel (a CMake lane covers the public SDK), PyPI publishing is still pending, and the sample build targets gfx942, gfx1151 and gfx1201.
The Blast Radius
On AMD hardware the NPU stops being an ONNX/XRT side channel and becomes a target in the same model as the iGPU and CPU — which is the case that matters on Strix Halo-class parts, where the NPU and the CPU contend for one memory controller. HIP compatibility is the adoption wedge: LD_PRELOAD=libamdhip64.so runs an existing HIP application through HRX unmodified, so the cost of evaluating it is one environment variable, not a port. A native llama.cpp ggml-hrx backend is already proposed (ggml-org/llama.cpp discussion #27219), and the "designed for agent authorship" positioning — explicit state and ownership, inspectable generated code, localized policy changes — is an explicit bet that agents rather than humans will be writing the kernels. Treat it as early access, not a capability swap: v0.1, not an official ROCm component, x86_64-only artifacts, no wheel yet, and no published benchmarks — the LLM path is a 0.8B Qwen demo, not a throughput claim.
Source: phoronix