CUDA training just ran on an AMD Radeon in Windows — reproducibly
A compatibility layer that Nvidia spent two decades making unnecessary now trains real PyTorch models on a consumer Radeon, and it ships as an installer.
A Windows stack built on ZLUDA + AMD's ROCm/HIP completed a real LibTorch reinforcement-learning run on an AMD Radeon RX 9060 XT, and the maintainer published the whole thing as a reproducible installer. The validated reference pins ZLUDA v6-preview.69 from official releases, AMD HIP SDK 6.4, and LibTorch 2.3.0 with the cu118 build — no private or recovered DLLs anywhere in the path. On that setup a 2,216,347-parameter PPO network ran forward inference, the learning step, and the optimizer on the CUDA-facing device, and one clean validation iteration cleared 65,536 timesteps. The driver shim nvcuda plus cuBLAS, cuBLASLt, cuSPARSE and cuFFT all pass ZLUDA's own cuda_check, mapped onto rocBLAS, hipBLASLt and rocSPARSE underneath.
The honest caveats are the interesting part. Only that one GPU architecture (gfx1200) is validated; everything else is listed as "unverified candidate," and the repo says detection is not proof a workload runs. cuDNN is missing from the stable Windows HIP SDK because AMD doesn't ship the full MIOpen stack there, so convolution-heavy software — most vision training — needs a nightly HIP build or extra work. Dense, matrix-multiply-heavy training doesn't need cuDNN, which is exactly why the PPO workload completed. NCCL, TensorRT and odd PTX behaviour can still fail.
Why it matters more than another GitHub toy: the maintainer benchmarked it. A controlled A/B run today on the same RX 9060 XT workload, ten iterations per runtime with the first discarded as warmup, put the public upstream path at 13,278 median steps per second versus 12,876 for the older custom overlay — meaning the hacked-together path people had been sharing was about 3.03% slower, and clean upstream is now the default. Historical tuned configurations reached roughly 70,000–109,000 steps per second on different settings. That is a usable local-training machine built from software nobody was supposed to be able to reverse-engineer on Windows.
The backdrop is the CUDA moat quietly becoming a hobby. ZLUDA 6 shipped after its author lost commercial funding and said development is a weekend project again — priorities now "what I find the most entertaining," which is why textures and legacy PhysX landed instead of enterprise support. AMD funded that work for years trying to break CUDA's lock on machine learning, then its legal team came after the developer for releasing the code; version 6 was rebuilt from a pre-AMD-funded codebase. Read that sequence as the real signal: AMD has spent a decade trying to do what a solo maintainer now does with a PowerShell script, because the moat was always ecosystem and inertia rather than physics. It pairs with the hardware push we covered in AMD's Halo Station answers DGX Station with 576GB of HBM3E — big boxes on one side, a $300-class card running unmodified CUDA binaries on the other. Nobody should build production infrastructure on a weekend project whose update cadence is whatever entertains its author. But every "you need Nvidia for that" claim now needs a specific reason.
What to watch: whether anyone files a compatibility report for a Radeon larger than 16 GB, and whether AMD ships MIOpen on Windows before the community does it for them.
If CUDA ran on any GPU you owned, would you move your local models off Nvidia — or is the ecosystem the real lock-in? Tell us in the comments.
Sources: CUDA-for-AMD-Windows (GitHub) · ZLUDA Q1/Q2 2026 update · Tom's Hardware
