ROCm/rocm-libraries: what the ROCm super-repo changes for GPU library contributors

The problem rocm-libraries solves is contributor workflow, not runtime performance

ROCm's GPU libraries were historically one GitHub repository per library. rocBLAS, hipBLASLt, MIOpen, rocFFT, rocSPARSE and their siblings each had their own build scripts, their own CI jobs and their own review queues. That layout is fine for a single library and painful for anything that crosses a boundary. A change to rocBLAS that requires a matching change in hipBLASLt means two pull requests, two review cycles and a coordination problem that no CI system can see. The README states the goal directly: consolidate libraries and shared components into a single repository to streamline development, CI and integration.

The audience is narrow and specific. This is for engineers who build ROCm libraries from source, maintain CI for them, or land patches across more than one of them. If you install ROCm from a distribution package and call rocBLAS through its C API, the super-repo is invisible to you. It changes where the source lives, not what the compiled library does.

The shared/ directory is the part that explains the design. rocroller, tensile, mxdatagenerator and origami are dependencies used by multiple libraries but, per the README, they do not produce their own distinct packages in previous ROCm releases. Putting them under shared/ rather than projects/ encodes that distinction in the directory layout: projects/ entries are released artifacts, shared/ entries are internal building blocks.

How the super-repo is laid out and what the migration table actually tells you

The structure is flat and predictable. Everything released lives under projects/, everything shared lives under shared/, and the README prints the full listing. There is no nested grouping by domain, so rocblas and miopen sit as siblings rather than under a math/ or dnn/ parent.

The more useful artifact is the migration table. Each component carries one of three statuses. Completed means fully migrated and integrated, and the README says the super-repo should be considered the source of truth for that project, with the old repository possibly still used for release activities. In Progress means migration or integration is ongoing, and the README asks contributors to refrain from submitting new pull requests on the individual repository and to develop on the super-repo instead. Pending means the individual repository is still the source of truth.

That table is the single most important thing to read before opening a pull request. Landing a patch on the wrong repository is a silent waste of review time. The table also links per-component Math CI status on math-ci.amd.com, which lets you see whether a component's precheckin job is green before you start.

Two CI systems coexist. TheRock CI runs multi-component testing on top of builds from the TheRock build system, and the README links both a push-triggered workflow and a nightly workflow on the develop branch. Legacy per-component CI runs alongside it for components that have not finished migrating. The duplication is deliberate during the transition and will presumably shrink, but the README does not say when the legacy pipelines are retired.

Getting a working tree: sparse-checkout, not a full clone

The README does not contain build commands. It points to CONTRIBUTING.md for setup instructions, sparse-checkout configuration, development workflow and pull request guidelines. That is the document to open first, and it is the only place in this repository that describes how to configure a working tree.

A full clone pulls every library plus the shared components. For a contributor who touches one library, that is a large checkout for no benefit. The README explicitly names sparse-checkout as part of the setup, which tells you the intended workflow is partial: materialize the directories you need and leave the rest out.

The first step is the ordinary clone of the default branch:

git clone https://github.com/ROCm/rocm-libraries.git
cd rocm-libraries

After that, the sparse-checkout configuration and the build presets come from CONTRIBUTING.md, not from the README. The top-level entries confirm the repository is a CMake project rather than a set of independent ones. CMakeLists.txt, CMakePresets.json, a cmake/ directory, .clang-format and .cmake-format.py all sit at the root, so formatting and configure conventions are applied across components rather than per component. The .gitmodules file indicates submodules are in use, which matters for sparse checkout: a partial checkout still needs its submodules initialized.

Because CONTRIBUTING.md is not reproduced here, the exact sparse-checkout paths and preset names cannot be quoted. Read that file and use the paths it gives rather than guessing at directory names, and note that the migration status of your component determines which repository you should be working in at all.

Naming was standardized, and that breaks old muscle memory

The README has a short section called Nomenclature that is easy to skip and worth reading. Project names were standardized to match the casing and punctuation of released packages, which removes the inconsistent camel-casing and underscores used in legacy repositories.

In practice this means the directory names under projects/ are the package names, not the historical repository names. composablekernel and hipblas-common appear in lowercase and with a hyphen respectively. If you have scripts, CI configuration or documentation that reference the old spellings, those references need updating. The change is cosmetic at the API level and disruptive at the tooling level, which is the usual trade-off for this kind of rename.

The same section is why the component list reads cleanly: rocblas, hipblaslt, hipsparselt, hipcub, hiprand, rocrand, rocprim, rocthrust, rocwmma, hiptensor, miopen, rocfft, rocsolver, rocsparse, hipsolver, hipsparse, hipfft, hipblas, mxdatagenerator, origami, rocroller and tensile all follow one convention.

The root has no unified license, and that is a real constraint for redistributors

The README is unusually direct here. Each subproject retains the license under which it was originally published. To find the terms for a given component you read the LICENSE, LICENSE.md or LICENSE.txt file inside its projects/ or shared/ directory. For files outside those directories, you read the header notice in the file itself.

A note in the README states that the root of the repository does not yet define a unified license across all components. There is no SPDX identifier to copy from the repository root, and the repository metadata does not carry one either.

For anyone vendoring or redistributing ROCm library sources, this changes the review process. You cannot clear the whole tree with one license read. You inspect the license file in each directory you actually ship, and you inspect file headers for anything outside projects/ and shared/. This is not legal advice; it is a description of where the license text lives. The practical consequence is that a compliance check scales with the number of components you vendor, not with the repository.

When rocm-libraries is the wrong tool

The clearest failure case is a component marked Pending in the migration table. The README says that for Pending components the individual repository should be considered the source of truth. Working here on such a component means your patch may not be the one that ships, and reviewers may not be watching this repository for it. Check the status before you clone.

The second case is consumption rather than development. Nothing in the README describes producing end-user ROCm packages from this repository for general installation. TheRock CI is described as performing multi-component testing on top of builds leveraging the TheRock build system, which is a testing role. The README gives no install path for a user who wants a working ROCm runtime. If that is what you need, this repository is the wrong entry point.

The third case is a contributor who needs a stable, frozen tree. The default branch is develop, and the recent release tags (therock-10.0, therock-7.14, rocm-7.2.4) are points in time on top of a moving branch. The README does not document rollback, does not describe a supported downgrade path, and does not explain how a release tag relates to the per-component packages that ship in a ROCm release. If your workflow depends on pinning and reverting cleanly, that documentation gap is a genuine risk rather than a minor omission.

How this differs from building each ROCm library separately

The alternative is the pre-consolidation model: clone rocBLAS from its own repository, clone hipBLASLt from its own, build each with its own scripts, and let each project's CI validate only its own component. That model is still partly alive here, since the README keeps legacy CI status links per component and says old repositories may still be used for certain release activities.

The difference in approach is where integration is tested. In the per-repository model, a cross-library incompatibility surfaces at release integration time or in a downstream consumer. In the super-repo model, TheRock CI runs multi-component testing on top of a shared build, so a break that spans rocBLAS and hipBLASLt can be caught in one pipeline on the develop branch. That is the entire argument for the consolidation, and it is a CI argument rather than an API argument.

The cost is checkout size and build surface. A contributor who wants one library now navigates a repository containing all of them, which is why the README points to sparse-checkout rather than a plain clone. The benefit only materializes for changes that cross component boundaries; for a single-library fix, the per-repository model was leaner.

Editorial conclusion

Use rocm-libraries if you contribute to or build ROCm math and primitives libraries from source, because the migration table marks rocBLAS, hipBLASLt, MIOpen, rocFFT and most siblings as Completed and the README says the super-repo is the source of truth for those. Do not adopt it if you only consume prebuilt ROCm packages, or if you work on a component still marked Pending, where the standalone repository remains the source of truth. Before cloning, check the migration status of your component in the README table and read CONTRIBUTING.md for the sparse-checkout configuration; the root LICENSE is not yet unified, so confirm the license file inside the specific projects/ directory you plan to build.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes