What is AMD ROCm and how to install it?

If you work with GPU acceleration for AI or HPC, you've probably already heard of ROCm, AMD's open platform that lets you leverage its cards for serious computing on Linux and, increasingly, in other environments as well. ROCm was created to efficiently integrate CPUs and GPUs and handle real-world computing workloads with an open approach, free from licensing restrictions.

In recent cycles, AMD has accelerated development: ROCm 7 brought powerful improvements in performance and compatibility, and previous 6.x versions opened the door to scenarios like WSL2 and multi-GPU configurations. The interesting thing is that we're no longer talking about a perpetual demo , but rather a maturing and scaling ecosystem that's starting to appeal to those seeking alternatives to CUDA without compromising their stack.

What is AMD ROCm and why is it important?

ROCm (Radeon Open Compute) is an open-source software stack that includes drivers, tools, libraries, and APIs for programming AMD GPUs from the kernel level down to end-user applications. The goal is to provide a unified, high-performance foundation for generative AI and high-performance computing (HPC), with relatively easy migration from existing ecosystems.

The platform supports running intensive workloads on Linux and focuses on maximizing GPU performance with an optimized runtime, compilers, and libraries. It integrates components such as HIP for porting CUDA code , libraries for collective communication like RCCL, linear algebra accelerators, and profiling and debugging tools.

In addition to performance, ROCm's value lies in its open nature: no closed licenses and broad alignment with AI and data science ecosystems such as PyTorch, TensorFlow, and ONNX. This makes it a very attractive option for universities, SMEs, and labs that want to scale without incurring excessive software costs.

What ROCm 7 brings: performance, lightweight form factors, and more compatibility

With version 7, the platform took a significant leap forward. AMD reports that it is up to 3,5x faster in inference and 3x faster in training in certain scenarios, driven by support for low-precision data types such as FP4 and FP6 and improvements to the communication stack and distributed execution.

These smaller formats allow for more data to be packed into less memory and accelerate throughput without significantly degrading quality under appropriate workloads, which is key for LLMs and generative AI . The trend towards lower precision (from FP32/FP16 to FP8/FP6/FP4) aligns with current best practices.

Another critical point is GPU-to-GPU communication. With the integration of RCCL (AMD's equivalent of NCCL), ROCm 7 improves GPU-to-GPU traffic orchestration , reducing bottlenecks when scaling to multiple accelerators. This facilitates more stable and efficient distributed training.

There's also progress in compatibility: in addition to Linux, support for Windows is being developed (still limited, but progressing), and the hardware range is expanding to include the Instinct MI300X, recent Radeon cards, and even Ryzen AI platforms. For desktop developers , this opens up options beyond the data center.

Software stack and key components in ROCm

ROCm is more than a driver: it's a complete stack. It includes development tools, compilers, numeric libraries, communication APIs, and administration utilities . Broadly speaking, its most relevant components are:

• HIP: A portability layer that allows CUDA kernels to be adapted to AMD GPUs. HIPify automates much of the translation process.
• RCCL: Collective communication library optimized for AMD GPUs, very useful in distributed training.
• MIOpen: primitives for neural networks GPU accelerated.
• ROCM BLAS, FFT, Sparse and MAGMA: Key algebra libraries for AI/HPC performance.
• Tools such as rocminfo, rocm-smi, profiling, debugging, and orchestration utilities (including support for Kubernetes via GPU Operator).

This set covers the entire development cycle , from writing and porting kernels to training models and operating clusters with visibility and control.

Differences from CUDA: What changes in practice?

Anyone coming from NVIDIA and CUDA knows that the performance is there, but so is the vendor lock-in. ROCm seeks to break that barrier with an open and more affordable proposition. In practice:

• The stack is open and free, ideal for AI clusters with controlled costs.
• HIP makes it easier to port CUDA kernels, but Not everything is automatic or 1:1.
• Hardware compatibility is more selective: Not all consumer Radeons are officially supported.
• Windows support is moving forward, and WSL2 is now appearing in 6.x branches as a beta, expanding development scenarios.

If your workflow relies on proprietary, CUDA-centric tools, you might encounter limitations. But if you use PyTorch or TensorFlow and operate within the open source environment , ROCm 7 begins to offer a serious production experience.

Hardware compatibility and requirements you should take into account

An important distinction is the list of officially supported GPUs. NVIDIA enables CUDA across much of its product line , while AMD officially restricts ROCm to specific chips (Instinct and certain Radeon cards). This doesn't mean other GPUs won't work, but they may require adjustments or lack support altogether.

Previous generations supported models like the Instinct MI25, which offered approximately 12,5 TFLOPs FP32 and 768 GFLOPs FP64 , but it was removed from the list of supported processors starting with ROCm 5.0. Even so, with some workarounds , it might still work for experimentation.

Above that, the Instinct MI50 offers around 13,3 TFLOPs FP32 and 6,6 TFLOPs FP64 , and current models like the MI300X raise the bar with plenty of memory and power for LLMs. In the professional consumer market, the 48GB Radeon Pro W7900 is an interesting option for LLMs that require 35GB or more per GPU.

An often overlooked requirement is CPU/motherboard support for PCIe Atomics. If your platform is older than 2017, you may encounter compatibility issues . It's advisable to verify this before making purchases or attempting ambitious deployments.

ROCm 6.1.3: Multi-GPU and WSL2 on the radar

Before ROCm 7, the 6.1.3 branch brought practical improvements: support for multi-GPU configurations (key for scaling services) and beta support for the Windows Subsystem for Linux (WSL2). This allows running AI tools designed for Linux from a Windows system, a very useful feature for hybrid workstations.

Furthermore, compatibility was added to TensorFlow alongside PyTorch and ONNX , expanding the options for those who switch between frameworks. If you work on Windows but the actual deployment is on Linux, WSL2 can be a convenient bridge for development.

Base installation on Linux (Ubuntu) and verification

For a personal computer running Ubuntu 20.04/22.04 LTS, the official installation is straightforward. The recommended workflow is to add the AMD repository, install the development metapackage, and verify the GPU.

Prepare the system with basic tools and the AMD repo key:

sudo apt update && sudo apt install -y wget gnupg2
wget https://repo.radeon.com/rocm/rocm.gpg.key
sudo gpg --dearmor -o /etc/apt/keyrings/rocm.gpg < rocm.gpg.key

Add the list of repositories and update the package index:

echo 'deb [signed-by=/etc/apt/keyrings/rocm.gpg] https://repo.radeon.com/rocm/apt/debian/ ubuntu main' | sudo tee /etc/apt/sources.list.d/rocm.list
sudo apt update

Install the development stack and main tools:

sudo apt install -y rocm-dev

To validate the installation, you can check the detected GPU and the driver status. These utilities are included in the ROCm stack.

rocminfo
rocm-smi

With this, you should be ready to compile code in HIP or run PyTorch with an AMD backend. If you're working with Kubernetes, the GPU Operator simplifies provisioning nodes with ready-to-use drivers and runtime.

Is there an automatic conversion from CUDA? What is really there?

A common question is whether a CUDA project can be converted to ROCm without touching the code. The short answer: there's no 100% automatic magic button . What does exist is HIP and the hipify tools that help translate a large part of the CUDA APIs and kernels.

In real-world projects, a semi-automated migration with manual reviews is typical , especially in areas with specific CUDA dependencies, non-standard extensions, or subtle behaviors. The effort required varies depending on the code size and the use of third-party libraries.

Unlike other initiatives, the experience here is designed to converge with the C++/HIP code, making it easier to maintain a common foundation . Even so, it's advisable to prototype critical modules before committing to a full migration.

Advanced Guide: Running ROCm on a Vega iGPU (Ryzen APU)

In unsupported scenarios, there's room for experimentation. An interesting example is a Ryzen 2200G with an iGPU Vega 8, capable of ~1,8 TFLOPs FP32 at 1,6 GHz . It's not a beast, but it allows for experimentation with smaller models.

The goal is for the system to detect the iGPU via ROCm, install the latest version available , and test PyTorch. In these cases, for PyTorch to recognize the GPU, it's usually necessary to compile PyTorch from source with specific parameters.

First, remember that the iGPU uses shared memory with the RAM. Allocate the maximum possible amount in the BIOS (for example, 2 GB) to allow for some headroom in inference.

Step 1: Install ROCm and validate the GPU

Use the Ubuntu procedure described above. Verify with rocminfo and openclinfo that the system recognizes the GPU:

sudo rocminfo
sudo openclinfo

If the agents are listed and the GPU appears in the corresponding section, you have the foundation ready for the rest of the process.

Step 2: Dependencies for compiling PyTorch with ROCm

You will need additional build tools and libraries that are not included with the default installer. Install the toolchain and build utilities:

sudo apt install -y python3 python3-pip gcc g++ libatomic1 make \
cmake doxygen graphviz texlive-full

It also adds ROCm packages and libraries that PyTorch will request during compilation. This includes drivers, MIOpen, RCCL, and the HIP ecosystem.

sudo apt install -y libstdc++-12-dev rock-dkms rocm-dev rocm-libs \
miopen-hip rccl rocthrust hipcub roctracer-dev cmake

For MAGMA, it's best to use Conda as your MKL provider. Install Miniconda in your user folder and leave the path manually:

mkdir -p ~/miniconda3
wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -O ~/miniconda3/miniconda.sh
bash ~/miniconda3/miniconda.sh -b -u -p ~/miniconda3
rm -rf ~/miniconda3/miniconda.sh
~/miniconda3/bin/conda init bash

Restart the terminal to load the environment. This will give you the necessary MKLROOT when you bind MAGMA.

Step 3: Build and install MAGMA for ROCm

Before compiling, identify your GPU's LLVM target using rocminfo or the AMDGPU LLVM documentation. On a Vega 8, you'll typically see gfx902, but practical support for these experiments approximates using gfx900 (MI25) as the target.

With that reference, adjust PYTORCH_ROCM_ARCH and MKLROOT and run the MAGMA build:

export PYTORCH_ROCM_ARCH=gfx900
# Clona el repo
git clone https://bitbucket.org/icl/magma.git
pushd magma
# Branch con corrección de memory leak
git checkout 5959b8783e45f1809812ed96ae762f38ee701972
cp make.inc-examples/make.inc.hip-gcc-mkl make.inc
# Añade linkers y objetivos de GPU al make.inc
echo 'LIBDIR += -L$(MKLROOT)/lib' >> make.inc
echo 'LIB += -Wl,--enable-new-dtags -Wl,--rpath,/opt/rocm/lib -Wl,--rpath,$(MKLROOT)/lib -Wl,--rpath,/opt/rocm/magma/lib' >> make.inc
echo 'DEVCCFLAGS += --gpu-max-threads-per-block=256' >> make.inc
export PATH="${PATH}:/opt/rocm/bin"
if [[ -n "$PYTORCH_ROCM_ARCH" ]]; then
  amdgpu_targets=`echo $PYTORCH_ROCM_ARCH | sed 's/;/ /g'`
else
  amdgpu_targets=`rocm_agent_enumerator | grep -v gfx000 | sort -u | xargs`
fi
for arch in $amdgpu_targets; do
  echo "DEVCCFLAGS += --amdgpu-target=$arch" >> make.inc
done
# Evita conflictos con OpenMP en hipcc
sed -i 's/^FOPENMP/#FOPENMP/g' make.inc
make -f make.gen.hipMAGMA -j $(nproc)
LANG=C.UTF-8 make lib/libmagma.so -j $(nproc) MKLROOT=~/miniconda3
make testing/testing_dgemm -j $(nproc) MKLROOT=~/miniconda3
popd
sudo mv magma /opt/rocm

This step ensures you have the key linear algebra for PyTorch . If it fails, adjust routes or re-validate the GPU target.

Step 4: Build PyTorch with ROCm backend

Clone the repository and resolve Python dependencies . Include additional packages that often prevent compilation errors:

git clone https://github.com/pytorch/pytorch.git
cd pytorch
git submodule update --init --recursive
sudo pip3 install -r requirements.txt
sudo pip3 install enum34 numpy pyyaml setuptools typing cffi future \
hypothesis typing_extensions CppHeaderParser argparse

Convert the CUDA code to HIP using the tool provided by AMD. This step adapts the kernels to the AMD backend.

sudo python3 tools/amd_build/build_amd.py

Finally, compile using the gfx900 target and enable ROCm. Adjust MAX_JOBS according to your cores/threads to avoid overloading the machine.

sudo PYTORCH_ROCM_ARCH=gfx900 USE_ROCM=1 MAX_JOBS=4 python3 setup.py install

Be patient: compilation can take hours and doesn't have to be on the final machine if you replicate dependencies on another machine.

Step 5: Driver stability and testing with MNIST

To improve iGPU stability, adjust the AMDGPU driver's power policies. Check the current settings and locate ppfeaturemask:

find /sys/module/amdgpu/parameters/ -type f -name '*' -exec sh -c 'filename=${1%.*}; echo "File: ${filename##*/}"; cat "$1"' sh {} \;

Next, load the module with a permissive value for ppfeaturemask. This value usually provides stability in the cases described:

sudo modprobe amdgpu ppfeaturemask=0xfff73fff

Restart and clone the PyTorch samples. Install the MNIST sample dependencies and use an override to make PyTorch treat the iGPU as gfx 9.0.0 (MI25):

git clone https://github.com/pytorch/examples.git
cd examples/mnist
sudo pip3 install -r requirements.txt
sudo HSA_OVERRIDE_GFX_VERSION=9.0.0 python3 main.py --verbose

If the PyTorch backend marks the GPU as available (even if the internal name uses "cuda"), it's using the HIP route. In PyTorch, "cuda" is the historical label for the GPU backend , regardless of whether the vendor is NVIDIA or AMD.

Windows, WSL2, and the path to mixed workstations

Although ROCm's primary support remains Linux, Windows support is on the way . Version 6.1.3 already points to WSL2 execution in beta, enabling Windows development with Linux AI tools.

For those working in corporate or educational environments with Windows, this greatly simplifies adoption : less friction in testing, preparing environments, and then moving to production on native Linux or Kubernetes.

Scaling: Multi-GPU, RCCL, and Orchestration

If your goal is distributed training, pay attention to RCCL and multi-GPU setups. ROCm 6.1.3 introduced finer multi-GPU support , and ROCm 7 further refines the communication layer to reduce latency.

In Kubernetes deployments, the GPU Operator assists with drivers, runtime, and workload-ready nodes. This reduces manual work on clusters and provides reproducibility for CI/CD teams and environments.

Cost, licenses and usage scenarios

One of ROCm's strengths is its cost-benefit ratio. Because it lacks proprietary licenses , it's possible to build more affordable AI clusters using AMD hardware and open-source software, which is very attractive to laboratories, universities, and SMEs.

That doesn't mean ROCm is suitable for every workflow. If you rely on proprietary tools with exclusive CUDA support , you'll encounter obstacles. But if your stack revolves around PyTorch, TensorFlow, ONNX, and the Python ecosystem, the field is favorable.

Practical tips to get started and avoid pitfalls

If you're new to AMD, try using smaller models first. Verify that the GPU and drivers are working correctly and that the necessary libraries (MIOpen, RCCL, BLAS/FFT) are present.

If you already use PyTorch or TensorFlow, try porting non-critical modules with HIP before moving everything. Detect specific CUDA dependencies that require manual adaptation and measure performance with and without reduced formats (FP16/FP8/FP6/FP4).

For clusters, plan the topology and communication from the outset. RCCL and a good interconnect fabric make a difference at scale. Consider GPUs with a lot of VRAM if you're running large LLMs.

The open source community is growing, and places like r/StableDiffusion are a constant source of ideas and tools. Take advantage of technical threads and repositories with scripts to accelerate your adoption or solve unusual problems.

With all of the above, the picture is clear: ROCm has gone from a fledgling alternative to a robust platform , with version 7 pushing hard in performance (FP4/FP6), communication, and support; version 6.1.3 opening the door to multi-GPU and WSL2; and a reasonably straightforward installation path on Ubuntu. There are compatibility limitations and some manual work required when porting from CUDA or on unofficial GPUs, but in return, it offers freedom, cost savings, and an experience that already feels like real-world production.