# Composable Kernel turns a GEMM into a tiled, multi-architecture operation > Composable Kernel is AMD's C++ and HIP library for performance-critical machine learning kernels, built on a tile-based programming model and a technique called Tensor Coordinate Transformation. The repository is now a read-only mirror of the code that moved to ROCm/rocm-libraries, and the build system is where most of the friction lives. **ROCm/composable_kernel** — [DEPRECATED] Moved to ROCm/rocm-libraries repo. NOTE: develop branch is maintained as a read-only mirror - Repository: https://github.com/ROCm/composable_kernel - Website: https://rocm.docs.amd.com/projects/composable_kernel/en/latest/ - Stars: 548 · Forks: 313 - Language: C++ - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/rocm-composable-kernel ## What the tile-based model is meant to fix Composable Kernel is a programming model for performance-critical kernels for machine learning workloads, written in general purpose kernel languages such as HIP C++, and the README names two ideas behind it. The first is a tile-based programming model, which works on blocks of data rather than element by element, so a kernel author can reason about data reuse inside a tile instead of about individual loads. The second is algorithm complexity reduction for complex machine learning operators, done with a technique the README calls Tensor Coordinate Transformation. The claim is that the same source can serve GPUs and CPUs, and that the two ideas together are what produce performance portability and code maintainability. The audience is kernel authors and compiler people, not application developers: nothing here is a drop-in replacement for a framework operator unless the framework already knows how to call it. ## The four layers between a call and a GPU The library is organised into four layers, and knowing which one you are working in decides how much boilerplate you write. At the bottom sit templated tile operators, the reusable pieces that do the actual data movement and math. Above them, templated kernel and invoker classes define a kernel generically. Then come instantiated kernel and invoker classes, which is where template arguments are fixed and the device code is generated for a specific problem shape. At the top is the client API, the layer an application calls. The repository also exposes separate surfaces for code generation, a profiler, a dispatcher, a tile_engine/ directory and an experimental/ tree, and it documents supported operations in include/ck/README.md with tile operations in include/ck_tile/README.md. The practical consequence is that writing a new operator means working at the lower layers, and that the client layer alone will not cover what you want. ## Building inside Docker with GPU_TARGETS as the pivot The README recommends building inside Docker, and the repository ships several Dockerfiles, including one for AITER, one for the compiler, one for manylinux, one for PyTorch and a base Dockerfile that starts from ubuntu:24.04 and defaults to ROCMVERSION=10.1 with the TheRock nightly tarball discovery. Building a new image: ```bash DOCKER_BUILDKIT=1 docker build -t ck:latest -f Dockerfile . ``` then launching it with the workspace mounted: ```bash docker run \ -it \ --privileged \ --group-add sudo \ -w /root/workspace \ -v ${PATH_TO_LOCAL_WORKSPACE}:/root/workspace \ ck:latest \ /bin/bash ``` The container approach is not a convenience here, it is how the ROCm toolchain arrives intact. Pre-built images are published on DockerHub, so an evaluation can skip the build step entirely. ## Why one architecture list breaks and another does not The single most consequential build flag is GPU_TARGETS, and the README explains its edge cases in detail. The macro names the GPU architectures you intend to run on, and multiple values are separated by a semicolon, for example gfx908;gfx90a;gfx942. The configuration step passes it to CMake along with the ROCm prefix and the hipcc compiler: ```bash cmake \ -D CMAKE_PREFIX_PATH=/opt/rocm \ -D CMAKE_CXX_COMPILER=/opt/rocm/bin/hipcc \ -D CMAKE_BUILD_TYPE=Release \ -D GPU_TARGETS="gfx908;gfx90a" \ .. ``` The trap is that a mixed architecture list under GPU_TARGETS only works when the architectures are similar, and the README names gfx908;gfx90a and gfx1100;gfx1101;gfx11012 as examples that work and tells you to use GPU_ARCHS instead for a genuinely mixed list such as gfx908;gfx1030;gfx1100;gfx942. If you leave GPU_TARGETS unset, the build covers every architecture the current compiler supports, which the README warns may take a long time, and tests and examples are only built when the user sets GPU_TARGETS on the command line. ## The development script and the fast configuration path For iteration, the README points at script/cmake-ck-dev.sh, which cleans the CMake cache before configuring, sets BUILD_DEV=ON, defaults the GPU targets to gfx908;gfx90a;gfx942, turns on verbose makefile output and adds compiler flags for clearer error messages. It assumes the parent directory is the source directory, and takes the source directory as its first argument and the GPU targets as its second: ```bash ../script/cmake-ck-dev.sh .. gfx1100 ``` Extra CMake arguments can be passed after that, for example a release build type. The fast path is the --minimal flag, which the README says cuts configuration from roughly 150 seconds to roughly 5 by disabling device instances, the profiler, examples, tutorials and tests: ```bash ../script/cmake-ck-dev.sh --minimal .. gfx90a ``` A preset form is also available with --preset=dev-minimal. Once configured, the build itself is a plain make: ```bash make -j"$(nproc)" ``` and installation is make -j install. Optional follow-up targets build examples and tests with make -j examples tests, and make -j check builds and runs them all. ## Windows builds run through TheRock and Ninja The README documents a separate Windows path that does not use the Linux container. You install TheRock, then configure with CMake using its prefix and its hipcc executable, Ninja as the generator, and a GPU target of gfx1151: ```bash cmake \ -D CMAKE_PREFIX_PATH="C:/dist/TheRock" \ -D CMAKE_CXX_COMPILER="C:/dist/TheRock/bin/hipcc.exe" \ -D CMAKE_BUILD_TYPE=Release \ -D GPU_TARGETS="gfx1151" \ -G Ninja \ .. ``` Ninja then builds either the whole library or individual targets. The Dockerfile in the repository root contains the same TheRock mechanism on the Linux side, with build arguments for pinning a specific tarball, choosing an architecture variant such as linux-multiarch, linux-gfx90a or linux-gfx94X-dcgpu, or overriding the compiler version. So TheRock appears to be the common denominator across both platforms, which is a useful thing to know before you set up two different toolchains. ## The Python side is a PyTorch inductor bridge, not a package The repository does publish a Python package, and its metadata is worth reading before you assume it installs kernels. The pyproject.toml names the distribution rocm-composable-kernel, declares requires-python of 3.8 or later, has no runtime dependencies and classifies the licence as OSI approved MIT. But the packages it ships are ck4inductor and its subpackages, mapped to the python/ck4inductor directory, include/ and library/, with the package data covering the CK headers, the tile headers and the instance headers. The intent is an inductor integration that can emit CK code, not a pip install that gives you a working kernel library. The examples directory tells the same story from the other side, with numbered cases from 01_gemm through 29_batched_gemm_bias_e_permute, covering GEMM, convolution, reduction, pooling, quantization, grouped GEMM, layernorm, softmax, contraction and elementwise work. ## This repository is a mirror, and the real one moved The repository description carries a deprecation notice: the project has moved to the ROCm/rocm-libraries repository, and the develop branch is maintained as a read-only mirror. The default branch is develop, and the last push was on 2026-10-20, so the mirror is being kept current even though it is not where work happens. The published releases are ROCm version releases, rocm-7.2.4 on 2026-05-28, rocm-7.2.3 on 2026-05-04 and rocm-7.2.2 on 2026-04-14, which tells you the tags here track the ROCm release train rather than a Composable Kernel version of its own. The README states that CK is released under the MIT license, with the licence file in the repository root, and that the documentation is open source like all ROCm projects. For a team picking a dependency, the practical instruction is to point at the code in rocm-libraries and treat this repository as history. ## Conclusion Composable Kernel is a good fit for a performance engineer writing or replacing a fused machine learning kernel on AMD hardware who wants one implementation to serve several GPU architectures rather than a per-architecture fork, and who is prepared to work in a templated C++ stack with a build driven by GPU_TARGETS. It is the wrong place to start a new project, because the repository is marked deprecated and its content has moved to the ROCm/rocm-libraries repository, with the develop branch kept as a read-only mirror. Verify three things before you adopt it: that the copy you are pinning is the one in rocm-libraries rather than this mirror, that your GPU architecture list is one the compiler can build together, since mixed architectures need GPU_ARCHS instead of GPU_TARGETS, and that your toolchain has the ROCm prefix and hipcc compiler the CMake configuration expects, because a missing GPU_TARGETS silently expands the build to every architecture the compiler supports. ## FAQ ### What is Composable Kernel used for? It provides a programming model for writing performance-critical kernels for machine learning workloads across architectures such as GPUs and CPUs, using general purpose kernel languages such as HIP C++. It is aimed at kernel authors rather than at application developers. ### How do I build Composable Kernel? The README recommends building inside a Docker container that already has the packages, using the provided Dockerfile, then configuring with CMake and building with make. Pre-built Docker images are published on DockerHub, and a convenience script script/cmake-ck-dev.sh handles development configuration. ### What does the GPU_TARGETS macro do in a Composable Kernel build? It sets the GPU target architectures you want to run on, with multiple architectures separated by a semicolon such as gfx908;gfx90a. The README notes that a mixed architecture list only works when the architectures are similar, and that GPU_ARCHS should be used for a genuinely mixed list. ### Has Composable Kernel been moved to another repository? Yes. The repository description marks it deprecated and states that the project moved to the ROCm/rocm-libraries repository, with the develop branch kept as a read-only mirror. The last push was on 2026-10-20. ### What layers make up the Composable Kernel library? The README lists four layers: templated tile operators, templated kernel and invoker, instantiated kernel and invoker, and the client API. Supported operations are listed in include/ck/README.md and tile operations in include/ck_tile/README.md. ## Sources - [Issues](https://github.com/ROCm/composable_kernel/issues) - [Project website](https://rocm.docs.amd.com/projects/composable_kernel/en/latest/) - [README](https://github.com/ROCm/composable_kernel/blob/develop/README.md) - [Releases](https://github.com/ROCm/composable_kernel/releases) - [ROCm/composable_kernel on GitHub](https://github.com/ROCm/composable_kernel) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rocm-composable-kernel