rocm-systems

What lives in the repository

The README describes the ROCm Systems super-repo as a single repository that consolidates multiple ROCm systems projects. The first group of migrated projects targets the requirements for building PyTorch on AMD hardware. The repository lists a long set of components in its migration table. These include amdsmi, aqlprofile, clr, hip, hipfile, hipother, hip-tests, rdc, rocdbgapi, rocdecode, rocjpeg, rocm-core, rocminfo, rocm-smi-lib, rocprofiler, rocprofiler-compute, rocprofiler-register, rocprofiler-sdk, rocprofiler-systems, rocr-debug-agent, rocr-runtime, rocshmem, and roctracer. Every entry in that table is marked Completed, and the table says the public super-repo should be treated as the source of truth for those components. Older standalone repositories may still be used for release activities, but active development has moved here.

The migration status key explains three states. Completed means the project is fully migrated and integrated, and the super-repo is the source of truth. In Progress means migration, tests, or integration are ongoing, and contributors are asked to develop on the super-repo instead of opening pull requests on the individual project repo. Pending means work has not started or is in early planning, and the individual repo remains the source of truth. The README says all listed components are Completed and notes the remaining schedule is to be determined. This status model tells outside contributors where to send their changes without guessing which repository is current.

Repository structure and shared code

The repository is organized with a projects directory and a shared directory. Each folder under projects corresponds to a ROCm systems project that was previously maintained in its own standalone GitHub repository and released as a separate package. The README lists these folders explicitly. They include amdsmi, aqlprofile, clr, hip, hipfile, hipother, hip-tests, rccl, rdc, rocdbgapi, rocdecode, rocjpeg, rocm-core, rocminfo, rocmsmilib, rocprofiler, rocprofiler-compute, rocprofiler-register, rocprofiler-sdk, rocprofiler-systems, rocr-debug-agent, rocrruntime, rocshmem, and roctracer. The list mirrors the migration table but also includes rccl, which appears in the structure yet is not in the Completed table, a small gap the reader should keep in mind. Having both directories in one checkout means a developer can build several related libraries without jumping between many repositories.

The folders under shared hold code that previously lived in its own repository and is used as a dependency by several projects, but does not produce its own package in earlier ROCm releases. This split keeps package producing projects apart from internal shared helpers. The README also explains the naming convention. Project names have been standardized to match the casing and punctuation of released packages, which removes inconsistent camel casing and underscores used in the legacy repositories. That change makes directory paths and package names line up with what downstream users already install, reducing confusion when moving from the old per project repos to this combined tree.

CI health and build integration

Continuous integration is a central reason the super-repo exists. The README embeds many status badges for individual components, pointing at GitHub Actions workflows that run on the develop branch. For example, aqlprofile runs CodeQL and a continuous integration workflow. rocprofiler-compute runs continuous integration, formatting, a Red Hat Enterprise Linux job, sanitizers, and an Ubuntu Jammy job. rocprofiler-sdk runs code coverage, CodeQL, continuous integration, documentation, formatting, Python linting, restriction checks, and a release compatibility workflow. rocprofiler-systems runs containers, GHCR package builds, formatting, Python linting, Red Hat, Ubuntu Jammy, and Ubuntu Noble jobs. These badges give a quick view of whether each component passes its checks.

Beyond per component workflows, the repository runs TheRock CI, which performs multi component testing on top of builds that use the separate TheRock build system. TheRock is referenced as the build system that ties the components together. The README notes that TheRock CI runs on push to the develop branch. The combination of per component badges and a cross component integration pipeline is meant to improve visibility and catch breakage that only shows up when several libraries are built together, which is the integration problem the super-repo was created to solve. The README frames TheRock CI as the layer that validates the integrated whole, while the per component badges validate each piece on its own.

Contributing and licensing

Getting started is documented in a CONTRIBUTING.md file linked from the README. The guide includes setup instructions, sparse checkout configuration, the development workflow, and pull request guidelines. Sparse checkout matters here because the repository holds many large projects, and a contributor may only want to clone the subset they are working on. The README also points readers to GitHub discussions for questions and to the issue tracker for bug reports.

Licensing is handled per component. The README states that the super-repo contains multiple subprojects, each of which keeps the license under which it was originally published. There is no single license at the root. Instead, readers should look inside each projects or shared directory for a LICENSE, LICENSE.md, or LICENSE.txt file with the specific terms. For files outside those two directories, the header notice in each individual file carries its own license terms. The README explicitly notes that the root of the repository does not define a unified license across all components, so anyone redistributing or packaging parts of the repo must check each subdirectory. This per folder licensing model reflects the fact that the components arrived from separate histories and keep their original agreements, and the README warns readers not to assume one license covers the whole tree.

Editorial conclusion

The ROCm Systems super-repo brings more than twenty AMD system libraries into one place, with per component licensing and a CONTRIBUTING.md that covers sparse checkout and pull requests. The source is hosted at github.com/ROCm/rocm-systems.