Reproducible ZLUDA and ROCm stack runs CUDA Windows apps on AMD GPUs

What the stack does

A repository named CUDA-for-AMD-Windows, which reached the Hacker News front page, lays out a working, reproducible recipe for running Windows applications compiled against NVIDIA's CUDA toolkit on AMD GPUs. The project combines ZLUDA, a compatibility layer that intercepts CUDA calls, with AMD's HIP SDK and the ROCm library ecosystem. According to the repository, the full path was verified using only public upstream components: ZLUDA v6-preview.69 from the official release, AMD HIP SDK 6.4, and LibTorch 2.3.0 built for CUDA 11.8. The validated reference machine is a single card, AMD's Radeon RX 9060 XT (gfx1200), and the project explicitly frames other AMD GPUs as unverified candidates rather than supported devices. It asks testers to file compatibility reports whether a card works or fails, and stresses that detecting a GPU's architecture is not proof that a workload will run.

How it works

The documented pipeline runs in layers. A CUDA-targeted application links against what it believes are NVIDIA's libraries; ZLUDA sits underneath and redirects those calls, with cuBLAS, cuBLASLt, cuSPARSE and cuFFT compatibility shims mapping onto AMD's rocBLAS, hipBLASLt, rocSPARSE and HIP runtimes, which execute on the Radeon hardware. A launcher script stages the necessary compatibility DLLs beside the target executable and sets the HIP/ROCm runtime paths for that run, so applications do not need to be rebuilt or modified.

Validation and performance

On the validated setup, ZLUDA's cuda_check tool passes for the CUDA driver (nvcuda), cuBLAS, cuBLASLt, cuSPARSE and cuFFT. The integration test goes further than a synthetic check: the repository reports that a real PPO network with 2,216,347 parameters completed forward passes, inference, learning and optimizer steps on the CUDA-facing device, and that one clean validation iteration ran 65,536 timesteps using the runtime the project produces.

cuDNN is the notable gap. The stable Windows HIP SDK does not ship the fuller ROCm AI-library stack such as MIOpen, so the project warns that convolution-heavy software depending on cuDNN may need a newer or nightly HIP stack or additional work. Dense, GEMM-heavy LibTorch training does not necessarily require cuDNN, and the validated PPO workload finished without it.

A controlled A/B benchmark dated 2026-09-13 ran ten iterations per runtime on the same RX 9060 XT workload, discarding the first iteration of each trial as warmup. The upstream-only path reached 13,278 median overall steps per second versus 12,876 for a custom DLL overlay from the original development environment, making the overlay about 3.03% slower, so the public upstream path remains the default. Historical tuned runs used a different training configuration and reached roughly 70,000 to 109,000 overall steps per second. That custom overlay is not distributed as binaries because its source provenance is incomplete and the recovered HIP runtime contains third-party AMD binaries, although SHA-256 fingerprints are recorded in the repository's manifests.

Tooling and limitations

Installation is scripted in PowerShell. The installer detects the AMD GPU and its native gfx target, verifies the driver and HIP SDK along with required math libraries, downloads the pinned ZLUDA build and optionally LibTorch (about 2.66 GB), checks SHA-256 hashes, generates runtime configuration and GPU report files, and runs cuda_check against the installed stack. A separate launcher runs a chosen CUDA-facing executable, and additional scripts can stage DLLs without launching, diagnose a machine, scan the GPU or test the runtime. According to the project, the scanner records model, architecture, driver and HIP information and does not intentionally collect usernames, tokens or user files.

The limitations list is candid: only the RX 9060 XT is validated, ZLUDA is not a complete CUDA implementation, Windows exposes only a subset of the full ROCm ecosystem, and NCCL, TensorRT, some PTX behaviour and custom CUDA extensions may fail. The ZLUDA_CC=8.6 setting is a CUDA-facing compatibility value, not a description of the AMD architecture. Project-owned scripts and documentation are MIT licensed, while ZLUDA, ROCm/HIP, CUDA components and PyTorch/LibTorch keep their own upstream licenses.

Why it matters

CUDA remains the default target for GPU software, which locks a large amount of Windows tooling and AI workloads to NVIDIA hardware. A documented, reproducible stack that runs real LibTorch training on a consumer Radeon card is a practical demonstration that the lock-in is porous. API and library coverage is workload-dependent and validation is one card deep, but the project's pinned versions, hash verification, benchmarking methodology and compatibility reporting give the community a concrete foundation to widen both.