MIOpen has been folded into the ROCm monorepo, and the old repository is retired

The first thing in the readme is a redirection

The MIOpen repository now opens with a CAUTION block.

The MIOpen repository is retired, please use the ROCm/rocm-libraries repository.

That is the current state of the project, and it is the single most important fact for anyone reading this repository. The homepage in the repository metadata points at github.com/ROCm/rocm-libraries, and the default branch is named develop_deprecated, which is about as explicit as a branch name can be. The last push was on 2026-10-14, so somebody is still touching it, but what they are touching is a repository that is being wound down.

The releases are labelled with the ROCm version rather than with a MIOpen version, rocm-7.2.2, rocm-7.2.1 and rocm-7.2.3, because MIOpen ships as part of a ROCm release train rather than on its own schedule. That is the packaging reality of a library that is a component of a larger stack.

What is not deprecated is the library. MIOpen is AMD's library for high-performance machine learning primitives, the published documentation is still organised and searchable on the ROCm documentation site, and the sources and binaries are still in the GitHub repository. The migration is about where the code lives, not about whether the software is finished.

Two programming models, one of them on the way out

MIOpen supports two programming models, which it calls backends.

The first is HIP, which is AMD's own portable kernel language, and it is the supported one. The second is OpenCL, which is marked deprecated in the same list.

That deprecation matters more than a label, because the two backends are not interchangeable at install time. The install section is explicit: you cannot install both backends on the same system simultaneously, and if you want a backend other than the one already present you must completely uninstall the existing one first.

That is an unusual constraint for a library, and it exists because the packages install the same files in the same places. The result for an operator is that the backend is a decision you make once, at install time, and changing it means reinstalling.

The readme also points to the MIOpen documentation in the ROCm docs site, and notes that the documentation source files live in the MIOpen/docs folder of this repository, and that as with all ROCm projects the documentation is open source.

So even a retired repository is still the source of the published documentation, which is worth knowing if you are looking for the build instructions for the current release.

Prebuilt packages, and the one backend rule

The installation path for most people is a package, and it is one line.

apt-get install miopen-hip

The OpenCL variant exists as miopen-opencl, but the readme says it is not recommended, because OpenCL is deprecated.

That gives the practical answer for a deployment: install the HIP package, on a ROCm enabled platform, and do not mix backends. The prerequisite list is a ROCm enabled platform, a base software stack that includes either HIP with the HIP and HCC libraries and header files, or OpenCL with the OpenCL libraries and headers, and the ROCm CMake modules which provide the common build tasks for the ROCm software stack.

The rest of the prerequisites are libraries MIOpen links against or uses. Half is the IEEE 754 half-precision floating point library. Boost is needed, with version 1.79 recommended because older versions may need patches to work on newer systems, and specifically the boost-system and boost-filesystem packages, which are what enable the persistent kernel cache. SQLite3 is a reading and writing performance database, lbzip2 is a multi-threaded compress or decompress utility, and rocBLAS is AMD's BLAS implementation on ROCm.

The two BLAS-related options are controlled by CMake flags rather than by detection. The HIP backend uses rocBLAS by default and it can be disabled with -DMIOPEN_USE_ROCBLAS=Off. It can also use hipBLASLt, AMD's flexible BLAS API, which is disabled with -DMIOPEN_USE_HIPBLASLT=Off. Neither rocBLAS nor hipBLASLt is available with OpenCL, which is another way of seeing that the OpenCL path is a compatibility leftover rather than a parallel implementation.

Precompiled kernels and the cache that eats your startup time

MIOpen provides an optional pre-compiled kernels package to reduce startup latency, and the explanation of why it only helps once is the most useful paragraph in the section.

The precompiled kernels comprise a select set of popular input configurations, and the readme says the set will be expanded in future releases. The package is installed per GPU architecture.

apt-get install miopen-hip-<arch>kdb

Where the architecture is the GPU architecture, for example gfx900, gfx906 or gfx1030.

The catch is in the next paragraph. All compiled kernels are locally cached in the $HOME/.cache/miopen/ folder, so precompiled kernels reduce the startup latency only for the first run of a neural network, and they do not reduce startup time on subsequent runs.

So the package is not a performance setting, it is a first run optimisation. After the first run the cache holds the compiled kernel and the compile cost is paid once either way, which means the benefit accrues to the machine that runs each configuration for the first time, and to nobody after that.

There is also a script that automates the install, utils/install_precompiled_kernels.sh, which queries the machine for the GPU architecture and installs the appropriate package. It depends on the rocminfo package to do the query.

And the note that these packages are optional: not installing them does not affect the functioning of MIOpen, since it compiles them on the target machine when you run the kernel, but the compilation step may significantly increase the startup time for different operations.

The dependency list shows a kernel compiler in the stack

The requirements file is a list of pinned dependency versions with their own build options, and it is the clearest picture of what MIOpen actually is.

There is sqlite3 at 3.49.1, boost at 1.83 with the C++20 standard flag and a set of deprecation suppressions, facebook/zstd at v1.4.5, ROCm/half pinned to a commit, ROCm/rocMLIR at rocm-5.5.0 with a checksum and a fat library compiler build, nlohmann/json at v3.11.2, ROCm/FunctionalPlus, ROCm/eigen at 3.4.0, ROCm/frugally-deep, ROCm/composable_kernel pinned to a commit with a release build type, and google/googletest at v1.14.0.

The presence of rocMLIR is the item that tells you the most. MLIR is AMD's multi-level intermediate representation, and MIOpen has an MLIR dialect, which the prerequisites describe as being there to support and complement kernel development. So MIOpen is not only a library of hand written kernels, it is also a place where kernels are compiled through an MLIR based toolchain, and where Composable Kernel, the C++ templated device library for GEMM-like and reduction-like operators, fits in.

That is a heavy stack. The pragmatic route for most users is the prebuilt package, and the requirements file is really for the people building from source or for the dependency resolver in a package build.

The dependencies can also be installed with a script, install_deps.cmake, run as cmake -P install_deps.cmake, which installs to /usr/local by default and takes a --prefix argument to put them somewhere else, and the resulting prefix is then passed to the configuration phase with CMAKE_PREFIX_PATH.

Building from source is a CMake configure with a backend flag

Building MIOpen from source is possible with either backend, and the sequence is short.

First a build directory.

mkdir build; cd build;

Then a CMake configure, with the backend chosen by the MIOPEN_BACKEND variable and the compiler set to clang++. For the HIP backend on ROCm 3.5 and later, the configure is run with the CXX export pointing at the clang binary and the prefix path covering the HIP installation, the ROCm installation and the MIOpen dependency path.

export CXX=/opt/rocm/llvm/bin/clang++ && \
cmake -DMIOPEN_BACKEND=HIP

The dependency prefix is passed with CMAKE_PREFIX_PATH, which is the same variable the install_deps.cmake script feeds its output into, so the two steps fit together.

The other detail in the Dockerfile is the one that causes friction. The base is ubuntu:22.04, the build installs the ROCm repository packages for a pinned ROCm version, and the image is multi-architecture with dpkg --add-architecture i386. The Dockerfile also has a comment about installing to /opt/rocm causing permission issues, which is why the PREFIX build argument defaults to /usr/local, and there are separate arguments for ccache, the compiler launcher and the GPU architectures to build for.

The tree, and the number of build systems behind it

The top level listing is large, and it shows a project that has been through a lot of infrastructure.

The code is in src/ with headers in include/, and the driver layer is separate in driver/, which is the layer that talks to the hardware. There is test/ for the tests, speedtests/ for the performance harness, samples/ with a README and a cba_fused_infer example plus a utils header, tools/ for the developer tooling, and utils/ for the helper scripts such as the precompiled kernel installer.

Then there is the build machinery. There is a CMakeLists.txt at the root, a cmake/ directory, a script/ directory, vars/ for the build variables, a fin/ directory, addkernels/ for the kernel addition tooling, install_deps.cmake, and a requirements.txt and a min-requirements.txt, which is a pattern for recording the minimum version of each dependency as well as the pinned one.

The continuous integration is spread across several systems, which is a legacy rather than a design choice. There is a .azuredevops/ directory, a .jenkins/ directory and a Jenkinsfile, a .github/ directory, a .githooks/ directory, and a Dockerfile.perftests alongside the main Dockerfile. The docs/ directory has a .readthedocs.yaml, and the repository carries a codecov.yml, a .clang-format, a .clang-tidy, a .lfsconfig for large file handling and a CHANGELOG.md.

For a repository that is being retired into a monorepo, that is a sensible amount of scaffolding to leave behind, because the monorepo needs the history, the tests and the documentation as much as it needs the code.

Editorial conclusion

Adopt MIOpen through the ROCm/rocm-libraries repository and not from this one, because the standalone MIOpen repository is retired and the default branch is named develop_deprecated. Do not pin your build to this tree. Verify first which ROCm release you are targeting, since the package names and the precompiled kernel packages are tied to the ROCm version, and whether you need the OpenCL backend at all, because it is deprecated and cannot be installed alongside the HIP backend on the same system.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. ROCm/MIOpen on GitHub