AMD vis-à-vis GPUs #6

Running rocm-examples

AMD vis-à-vis GPUs #5

---

AMD’s ROCm examples are designed to provide a detailed guide for running a variety of workloads on AMD GPUs. For the purposes of this series, we will look at successfully running all of these examples without spoofing as a starting point for porting ROCm to the gfx90c. They don’t cover every use-case, but we can use them as a pretty good expansive set, a simple litmus test which takes a few minutes. For running ROCm examples, we will start by using the precompiled Fedora package.

$ dnf info rocm-examples
Name            : rocm-examples
Version         : 6.4.2
Release         : 2.fc43
$ /usr/bin/hip_device_query
Hip target platform:      AMD
Compiler:                 HIP-Clang
--------------------------------------------------------------------------------
Device ID                 0
--------------------------------------------------------------------------------
Name:                     AMD Radeon Graphics
totalGlobalMem:           13.61 GiB
sharedMemPerBlock:        64 KiB
regsPerBlock:             65536
warpSize:                 64
maxThreadsPerBlock:       1024
maxThreadsDim:            (1024, 1024, 1024)
maxGridSize:              (2147483647, 65536, 65536)
clockRate:                1800 Mhz
gcnArchName:              gfx90c:xnack+

peer(s):                  None

memInfo.total:            13.61 GiB
memInfo.free:             13.61 GiB (100%)

This is all as expected, pretty promising. Running rpm -ql rocm-examples returns a list of 113 HIP / ROC benchmarks present in /usr/bin/.

The results from running these benchmarks are presented as a Sankey diagram below.

61 benchmarks are of the ‘ROC’ type, meaning they’re AMD specific, whereas 52 are generic HIP benchmarks (portable across various CPU and GPU flavours). Around 75% of these examples failed to run. Except for FFT which succeeded fully, atleast one example failed in each workload category, whether ROC or HIP. We will study and resolve each of these failed examples, one by one. But before that, here’s the execution time data for the examples which ran without issues.

While the efficacy of iGPUs for large scale production AI/ML workloads such as LLMs is up for debate, I strongly feel that for educational/testing purposes they have sufficient compute. The most slow example to run successfully took (only) 13.2 seconds. My hypothesis is that even if they are significantly slower, AMD iGPUs are capable of performing these tasks effectively. We can also observe that a few benchmarks were sub-50ms, due to the use of UMA (Unified Memory Architecture). When they launched CDNA3, which is 3 generations newer than our GCN5.1 iGPU, they launched the discrete Instinct MI300X, but they also launched the Instinct MI300A with CDNA3 architecture. The MI300A is nothing but a Zen 4 EPYC server CPU combined with a CDNA3 ‘accelerator’ which has 128GB HBM3. Packaging these 2 together reduces latency (which is a significant concern for HBM), and incidentally our gfx90c is quite similar! There is rarely a perfect answer for how to design compute / accelerators. However there are definitely some wrong answers while designing accelerators. In our case, I feel that the MI300A is a clear indicator that we don’t have a completely wrong architecture incapable of running modern AI models. There are tangible benefits from using an APU (Accelerated Processing Unit) architecture for GenAI workloads.

Here’s the list of errors thrown by the failed examples:

1. (49 instances) exit code (255)

2. (29 instances) error encountered: “invalid device function”

3. (5 instances) Tensile Error: “Missing TensileLibrary.dat”

4. (only on hip_hipify): exit code (1) h_out[0] = 0, expected: 2.61792

5. (only on rocrand_simple_distributions_cpp) exit code (134) terminate called after throwing an instance of ‘rocrand_cpp::error’

Here, exit code 255 is caused because the Fedora provided rocm-examples binaries dont contain device-side machine instruction blocks for gfx90c. These machine instruction blocks are called bundled code objects, in this case LLVM Bitcode / AMDGPU ISA, and they should be present within each of these 49 failing binaries present in /usr/bin.

The second error, “invalid device function” is caused partly because our GPU isn’t a compilation target. This causes the error even though our GPU can run any gfx9 (eg. code compiled for gfx900). Even though the ISA is identical, we will have to physically modify the target metadata and target feature flags for these examples. There are also some incompatibilities caused by ECC and XNACK, which are set as compilation attributes. XNACK is AMD’s retry-on-fault feature which automatically fetches objects from system memory when they are missing in the GPU’s VRAM. An iGPU can easily support this due to UMA, but some AMD dGPUs did not support XNACK. ECC (Error Correcting Code memory) is a hardware feature which has to be supported by the GPU’s memory. For example, the MI300A’s HBM3 memory supports ECC, whereas our consumer APU’s DDR4 memory doesn’t.

The third Tensile error, is caused because our program is unable to fetch the gfx90c's TensileLibrary.dat. These files contain precomputed logic profile tables optimized for different matrix shapes and hardware configurations. We have already come across this error in AMD vis-à-vis GPUs #4.

The fourth error is a functional validation failure (not a crash) where the HIPified CUDA code ran successfully but with incorrect output. HIPify is an auxiliary program provided by ROCm, covered in AMD vis-à-vis GPUs #5, and its not a part of the ROCm runtime. We can ignore this bug for now.

The fifth error is caused because our APU does not have bidirectional cache coherency between the CPU and GPU, so the program is run with BASE_PROFILE. rocrand_simple_distributions_cpp requires Coherent Host Access: TRUE. rocminfo tells us that our hardware physically is incapable of running the rocrand_simple_distributions_cpp benchmark.

$ rocminfo
ROCk module is loaded
=====================    
HSA System Attributes    
=====================    
Runtime Version:         1.1
Runtime Ext Version:     1.7      
XNACK enabled:           YES
==========               
HSA Agents               
==========     
*******                  
Agent 2                  
*******                  
  Name:                    gfx90c                  
  Device Type:             GPU                                
  Cache Info:              
    L1:                      16(0x10) KB                        
    L2:                      1024(0x400) KB                      
  Compute Unit:            7                       
  Coherent Host Access:    FALSE                              
  Memory Properties:       APU

To summarise, 1/113 examples failed due to a hardware constraint, but the 84 failures are caused purely because of software support. And the 28 examples which succeed run without problems, albeit slowly. Not bad!

Upcoming topics:

1. Compile and run rocm-examples from scratch and compare results with Fedora rocm-examples

2. Generating our own missing Tensile .dat files for gfx90c against system ROCm 6.4.4

3. Deep-dive on GPU programming

4. Getting TheRock working

5. HIP performance differences between gfx90c and spoof

6. PyTorch benchmarks

7. Compare rocm-examples HIP code with same workloads written using Mojo / ZML / etc.

See you in the next one!

© 2026 by Soham Kulkarni. This work is licensed under CC BY-SA 4.0.