Documentation · Get the SDK · Build from source
Loom is a language and compiler for native programs on CPUs, GPUs, and NPUs. Its microsecond-scale JIT, runtime, and inference server fit in a megabyte-scale SDK, with no LLVM or ROCm dependency. LibHRX is a C API for graph-based heterogeneous compute with an optional HIP compatibility layer.
This repository contains the compiler, execution libraries, native AMD device
support, and loom-serve: an inference engine that hosts multiple models and
modalities together. The pieces can be embedded independently, from compiling
one program for an existing runtime to running a shared model server.
Tip
To run models or troubleshoot a model, start at loom-dev. Loom skills help your agent set up, run, and adapt models; the Loom docs cover installation, serving, and authoring.
hrx-system is the engineering repository for Loom's compiler, runtime, and tools.
Note
This is a tech preview. Interfaces and target coverage are evolving; see the target guide for current support. The project is not an official component of the ROCm stack.
This project has been engineered with the assistance of agents.
Programs can be written in a subset of C++ or directly in Loom IR. Functions, kernels, command programs, and pipelines share a compiler that can link and specialize them using shapes, configuration, and target capabilities. The same compiler runs ahead of time or inside an application. Kernels compile in microseconds to milliseconds, making specialization practical when the application has the information it needs.
Model packages
bundle source or bytecode, weights, and a JSON descriptor. The model supplies its
implementation; Loom services provide execution, batching, residency, and
scheduling, with loom-serve adding HTTP endpoints and server controls. Models
can share a process and its resources, and implementations can be changed while
the server is running. Adding a model means supplying a program to the platform.
The compiler emits ELF, HSACO, SPIR-V, WebAssembly, and other artifacts. An
application can load that output through its own runtime, or use the execution
libraries here. The shared HAL provides CPU execution, Vulkan execution, and
native AMD GPU and XDNA execution. Native AMD access uses libamdf and the OS
drivers; it does not require a ROCm SDK or ROCr installation. Vulkan uses the
system's Vulkan implementation.
These boundaries keep model behavior out of the compiler and hardware layers.
A new implementation can reuse the surrounding software, and an improvement to
the compiler or runtime can benefit the programs already using it. libhrx is
another client of the shared runtime, exposing a native HRX API and a HIP
compatibility binding. Loom's compiler and services use the runtime directly.
| Package | What lives here |
|---|---|
| Loom | Language, compiler, public compiler C API, tools, model execution, serving, and SDK packaging. Start here for Loom development. |
| Shared runtime | HAL, VM, CPU task system, asynchronous I/O, networking, storage, and tokenization. |
| libamdf | Native AMD GPU and NPU access: device capabilities, memory backing, queues, and OS integration. |
| libhrx | Native HRX API, HIP compatibility, conformance tests, and package installation. |
| Hardware reference | AMD GPU and NPU programming contracts and execution mechanisms. |
| Build tools | Source setup, Bazel and CMake workflows, dependency configuration, tests, and embedding. |
The shared runtime grew from IREE, which
explains the iree/ source paths and API names. Its current contracts live beside
the implementation in this repository.
The Loom library is the home for reusable model programs, kernels, and their tests. Community efforts such as loom-fun's models and authoring skills show how that corpus can grow independently of the compiler and server.
For changes to the core, start with Building and Contributing, then the README, headers, and tests nearest the component you are changing. Model ports and experiments belong with their model sources; fixes and capabilities that other programs can reuse belong in the compiler, runtime, or shared libraries.
See Security for reporting vulnerabilities and LICENSE for the Apache 2.0 license with LLVM exceptions. Individual third-party components and assets retain their own license notices.