# ROCm Systems Super-Repo: One Tree for AMD's GPU Toolchain > AMD has consolidated two dozen ROCm systems projects into a single super-repo. This review examines what the migration means for developers building PyTorch on AMD GPUs and how to navigate the new structure. **ROCm/rocm-systems** — super repo for rocm systems projects - Repository: https://github.com/ROCm/rocm-systems - Stars: 516 · Forks: 423 - Language: C++ - License: not declared - Published: 2026-08-27 · Updated: 2026-08-27 · Language: en - Canonical page: https://hysenlabs.com/projects/rocm-rocm-systems ## What the Super-Repo Actually Consolidates For an engineer, the practical change is that you no longer need to clone and build a dozen separate repos to get a working ROCm stack. The super-repo gives you one checkout with all the source. But it is not a source distribution in the usual sense. It is a development and integration tree, not a replacement for the released packages. The old repos may still be used for release activities, as the README says, which means the super-repo is the place to develop, but official releases still flow through the legacy repos. That split is worth understanding before you rely on this tree for a production build. ## Migration Status: Completed versus In Progress versus Pending The tentative migration schedule section is empty, with only a note saying the remaining schedule is to be determined. That suggests the migration is not fully done despite the Completed labels. The README itself says the first set of projects focuses on requirements for building PyTorch, which implies more projects may come later. For an adopter, the takeaway is to treat the Completed labels as aspirational until you see a passing CI run for the specific component you care about. ## TheRock CI: Multi-Component Testing on a Shared Build However, the README gives no details on how to run TheRock locally or how to reproduce its results. The link to the TheRock build system is provided, but the super-repo README does not include a command to invoke it. If you need to reproduce a CI failure locally, you will have to dig into the workflow file or TheRock docs yourself. That is a documentation gap, but not a blocker: the workflow files are in the repo, and you can read them directly. ## Getting the Code and Building: What the README Does and Does Not Say For a developer who already knows ROCm, this is not a blocker. You can clone the repo, check out a tag, and enter a project folder to build it as you would before. For a newcomer, the lack of build instructions is a real friction point. The super-repo is not a turnkey SDK; it is a source tree for people who already know the components. The README's focus is on migration status, not on usage. That is a deliberate choice, and it matches the audience: the projects are for maintainers and contributors, not end users. ## The Real Limitation: Empty CI Entries and Unverified Claims Another limitation is that the README does not list a license. The repository metadata says 'unknown'. For an open source project, that is a red flag. If you plan to redistribute code from this repo, you need to know the license terms. The individual components likely have their own licenses, but the super-repo as a whole does not state one. That is a legal uncertainty that an adopter must resolve before using the code. This is not a technical limitation, but it is a practical one for any organization that needs to comply with licensing. ## Alternatives: The Old Individual Repos and the Upstream PyTorch Approach Another alternative is not to use ROCm's repos at all and instead rely on the upstream PyTorch build process, which pulls in ROCm components as prebuilt packages. That approach avoids building from source entirely. The difference is that with rocm-systems you get source-level control and the ability to patch components before building PyTorch, which is essential for debugging or for adding custom features. The cost is the complexity of building and maintaining the whole stack. For most application developers, the prebuilt path is simpler. For system integrators and ROCm contributors, the super-repo is the intended tool. ## Maintenance and Upgrade Cost: What the Tags and Branches Suggest The license ambiguity adds to the maintenance cost. Without a clear license for the super-repo, you cannot safely redistribute modified code without legal review. The individual components may have licenses, but the super-repo as a whole does not state one. That is something to verify before you build anything on top of it. ## Conclusion Adopt rocm-systems if you build or package ROCm components like hip, rocprofiler, or amdsmi and want a single source of truth with unified CI and naming. Avoid it if you need the latest release of a component that is still marked Pending or In Progress, because the old individual repos remain authoritative for those. Before switching, verify the migration status of every component you depend on and check the specific CI workflow for that component, since the table shows some have no visible CI status at all. ## Sources - [Official README](https://github.com/ROCm/rocm-systems#readme) - [Project repository](https://github.com/ROCm/rocm-systems) - [Release notes](https://github.com/ROCm/rocm-systems/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rocm-rocm-systems