ROCm/legacy-rocm-build: the AMD ROCm home repository, and where it is heading

What ROCm/legacy-rocm-build actually is, and who it is for

The description on the repository is blunt: AMD ROCm Software - GitHub Home. It is a landing page for a software stack, not the stack itself. The README describes ROCm as an open-source collection of drivers, development tools and APIs that enable GPU programming from low-level kernels to end-user applications, aimed at GPU-accelerated high-performance computing, AI, scientific computing and CAD. The primary language listed for the repository is Shell, which fits a repository whose main artefacts are Markdown, configuration and documentation scaffolding rather than compiled source.

The audience follows from that. If you are evaluating an AMD Instinct or Radeon GPU for a compute cluster, a PyTorch training box, or a port of CUDA code, this repository is where AMD points you for the component inventory and for links to the installation guide. If you are looking for a single tarball that compiles the whole stack, this is not it. The README does not document a build procedure for the repository itself, and the top-level entries (docs/, tools/, cmake/, default.xml) read like documentation and manifest tooling rather than a compiler tree.

How the ROCm stack is split across repositories

The README gives an explicit architecture: most core components live in two super-repos, ROCm Libraries and ROCm Systems, divided by domain. Math and compute libraries sit under rocm-libraries, including hipBLAS and rocBLAS, hipBLASLt, hipFFT and rocFFT, hipRAND and rocRAND, hipSOLVER and rocSOLVER, hipSPARSE and rocSPARSE, MIOpen, rocPRIM, rocThrust, rocWMMA and Composable Kernel. Communication libraries, RCCL and rocSHMEM, are under rocm-systems, as are the HIP runtime, the ROCr runtime, the profilers (rocprofiler-compute, rocprofiler-systems, ROCprofiler-SDK), the debuggers (ROCdbgapi, ROCgdb, ROCR Debug Agent), the control and monitoring tools (AMD SMI, ROCm Data Center Tool, rocminfo) and the media and storage libraries (rocDecode, rocJPEG, hipFile).

Two components sit outside that split in the README's list: HIPIFY and the LLVM fork under ROCm/llvm-project. The practical consequence is that a bug in rocBLAS is not fixed here. The README's own warning says issues and discussions should go to ROCm/TheRock, which means this repository's role is shrinking even before the announced deprecation. For a reader, the useful mental model is a directory: this repository tells you which project owns which capability, and you follow the link.

Installing ROCm and running a first check

The README does not give install commands. It points to the ROCm installation guide at rocm.docs.amd.com for installing ROCm on your system, and to the compatibility matrix for official support across ROCm versions, operating system kernels and GPU architectures (CDNA/Instinct, RDNA/Radeon and Radeon Pro). Supported distributions named in the README include Ubuntu, RHEL, SLES, Oracle Linux, Debian and Rocky Linux. Because the exact package names and repository setup differ per distribution and per ROCm version, copy them from that install page rather than from here.

Once ROCm is installed, rocminfo is the component the README lists for control and monitoring, and it is the first thing to run. It reports the agents the runtime can see, so a GPU that does not appear there will not appear to HIP either.

Limitations, and the deprecation notice you should read first

The most important statement in the README is a warning block at the top: this repository will be deprecated soon, and readers should use ROCm/TheRock moving forward, including for issues and discussions. That has three consequences. First, the issue tracker here is a dead end for new problems. Second, any automation you build that watches this repository for changes is watching a repository AMD has said it will retire. Third, the name itself, legacy-rocm-build, signals that the build-side purpose has already moved.

The second limitation is scope. ROCm is hardware-specific. The compatibility matrix, not the README, decides whether your GPU and kernel are supported, and the README lists targets across CDNA4, CDNA3, CDNA2, RDNA4 and RDNA3 without claiming every combination works. If your card is not in the matrix for the ROCm version you want, no amount of reading this repository changes that. The third is that this is the wrong tool entirely for someone who wants a portable, vendor-neutral GPU abstraction: ROCm is AMD's stack, and the README frames HIP as an interface similar to CUDA, which tells you the migration story is a port, not a drop-in.

ROCm versus CUDA, and what HIPIFY does about it

The obvious alternative is NVIDIA CUDA, and the README addresses the comparison directly by describing HIP as a C++ runtime API and kernel language that lets developers write portable GPU code with an interface similar to CUDA. The difference in approach is that HIP is a portability layer over AMD hardware, with HIPIFY listed among the runtimes and compilers as the tool for translating CUDA source. CUDA, by contrast, is the native interface for NVIDIA GPUs, so the porting direction runs one way in practice: CUDA code moves to HIP, not the reverse.

ROCm also supports OpenMP and OpenCL, which matters if your code already targets those rather than CUDA. The README states that ROCm integrates with PyTorch and TensorFlow, and points to separate installation pages for PyTorch and JAX under the AI Ecosystem documentation. So the honest framing is not ROCm against CUDA in the abstract. It is whether your framework build, your GPU and your kernel version line up, and the compatibility matrix is the document that answers that. The README does not publish performance comparisons, and none should be inferred from it.

Maintenance, releases and the licence boundary

The repository is not archived, and the last push was on 2026-09-02, which is recent. Releases are tagged with version names: rocm-7.14.0 (ROCm 7.14.0 Release) on 2026-07-16, rocm-7.2.4 on 2026-05-29 and rocm-7.2.3 on 2026-05-04. The README also links to release notes, so the upgrade path is versioned and traceable rather than rolling.

Upgrade cost is mostly a compatibility exercise. Moving between ROCm versions means re-checking the matrix for your distribution kernel and GPU architecture, and the README names enough distributions (Ubuntu, RHEL, SLES, Oracle Linux, Debian, Rocky Linux) that a fleet is unlikely to be uniform. The repository itself carries an MIT LICENSE at the top level, but that file governs this repository. The README's own component list points to separate projects, and the licences of hipBLAS, MIOpen, RCCL or the ROCr runtime are not stated here. Treat the top-level MIT as covering the home repository, and read each component's own licence before redistributing anything.

Editorial conclusion

Adopt this repository as a pointer, not as a source tree: read its README for the component list, then install ROCm from the official installation guide and file issues and discussions under ROCm/TheRock, which the README names as the forward path. Do not clone it expecting to build a compiler, and do not treat the MIT LICENSE on the top level as the licence of hipBLAS, MIOpen or the ROCr runtime, which are separate projects. Before committing to a version, check the compatibility matrix for your GPU architecture and operating system, and confirm that the ROCm version you install matches the release notes you read. The one fact to act on is the deprecation notice: if your workflow depends on this repository's issue tracker, move it before the move is forced on you.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ROCm/legacy-rocm-build on GitHub