Run CUDA Apps on an AMD GPU in Windows: A Practical ZLUDA + HIP SDK Guide

The moment I saw this project trending on Hacker News, I understood the emotion in the comments. An unmodified CUDA application, compiled for an NVIDIA GPU, running on an AMD Radeon without recompilation. It sounds like a trick. It is not. The stack is public, pinned, and validated on real hardware, and it just completed a full reinforcement-learning training loop on an RX 9060 XT.

Let me be upfront about one thing: I have not run this stack on my own hardware yet. This is a researched guide, built from the project's own validation documents, the AMD ROCm documentation, and coverage of ZLUDA 6. Everything below is what the sources show, labeled clearly where I am extrapolating. If you have an AMD card gathering dust because your ML tools only spoke CUDA, this is the state of play as of September 2026.

The CUDA moat, in one paragraph

CUDA is not fast because NVIDIA GPUs are magic. It is fast because every framework, library, and runtime you use speaks it first. PyTorch, LibTorch, TensorFlow, and most research code ship CUDA-first. AMD's answer, ROCm and HIP, works well on Linux and datacenter parts, but on Windows the story has been thinner for years: fewer libraries, less validation, and a consumer experience that mostly means "install the driver and hope."

ZLUDA attacks exactly this. It is a translation layer: it presents the CUDA API surface (the nvcuda driver, cuBLAS, cuSPARSE, cuFFT) and forwards the calls to AMD's stack underneath. The app never knows. It thinks it is talking to CUDA. Under the hood, every matrix multiply lands on rocBLAS, every sparse op on rocSPARSE, and every FFT on AMD's runtime via HIP. The project name is Polish for "mirage", and the metaphor is precise. To the app, CUDA is a mirage. The work happens on AMD silicon.

The project that made it reproducible

The interesting part this week is not ZLUDA itself. ZLUDA 6 shipped in late June with PhysX support, Blender texture support, and better Windows tooling, and its author, vosen, said the project is back to being a weekend project after AMD funding ended. The interesting part is a separate community project, CUDA for AMD on Windows by GitHub user Speedstu, which turns ZLUDA from "a thing you assemble yourself" into a reproducible, scriptable stack.

The repo's own validation section, updated this week, lists what has been verified end to end on the reference machine:

ZLUDA v6-preview.69 from the official ZLUDA release
AMD HIP SDK 6.4 for Windows
LibTorch 2.3.0 + cu118
Radeon RX 9060 XT (gfx1200, RDNA4)

With that stack, the repo reports that the CUDA driver interface nvcuda, cuBLAS, cuBLASLt, cuSPARSE, and cuFFT all pass cuda_check, and that a real 2,216,347-parameter PPO network completed forward pass, PPO learning, and optimizer work on the CUDA-facing device. One clean validation iteration ran 65,536 timesteps. These are the project's numbers, published with pinned hashes and a verify workflow in the repo, not my own runs.

For context on why this matters: PPO training is dense GEMM-heavy work, exactly the shape of compute that used to require an NVIDIA card, full stop. If a translation layer can push 65k timesteps of a 2.2M-parameter network through rocBLAS instead of cuBLAS, the CUDA moat has a crack in it that anyone with a Windows PC and an RX 9060 XT can walk through.

How the stack actually works

The diagram from the repo, in words:

CUDA-targeted Windows application
              |
            ZLUDA
              |
 cuBLAS / cuSPARSE / cuFFT compatibility
              |
 rocBLAS / hipBLASLt / rocSPARSE / HIP
              |
           AMD GPU

The top layer is your app. It links against CUDA libraries as usual. No source changes, no recompilation. That is the whole point.

The middle layer is ZLUDA. It provides fake CUDA DLLs that implement the CUDA driver and runtime API by translating to HIP. When your app calls cudaMalloc, ZLUDA calls hipMalloc. When it calls a cuBLAS GEMM, ZLUDA dispatches to rocBLAS. Coverage is partial by design; the docs are explicit that ZLUDA is not a complete CUDA implementation.

The bottom layer is AMD's. The HIP SDK for Windows ships the ROCm runtime, rocBLAS, hipBLASLt, and rocSPARSE. This is the part AMD builds and supports on Windows, and it is the reason the stack is viable at all. Without a Windows HIP SDK, ZLUDA has nothing to translate into.

One caveat on GPUs. The validated reference is only the RX 9060 XT (gfx1200, RDNA4). The project marks other AMD cards as "unverified candidates" rather than supported. Your RX 6000/7000/9000-series card may work, but you are a tester, not a customer.

Trying it: the actual steps

The repo is scripts-driven. Everything below is from the project's install documentation.

Step 1: AMD prerequisites. Install a current AMD GPU driver and the AMD HIP SDK for Windows including HIP Libraries. The validated reference uses HIP SDK 6.4. Newer versions may work but are unverified.

Step 2: Clone and run the installer.

git clone https://github.com/Speedstu/CUDA-for-AMD-Windows.git
cd CUDA-for-AMD-Windows
powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1

The installer detects your GPU and its gfxXXXX target, verifies the driver and math libraries, downloads the pinned official ZLUDA build, optionally pulls LibTorch 2.3.0+cu118 (about 2.66 GB), verifies SHA-256 hashes, generates runtime config and a GPU report, and runs cuda_check.exe against the installed AMD stack. If you do not need LibTorch, add -SkipLibTorch.

Step 3: Launch your CUDA app.

.\scripts\run-zluda.ps1 -Program C:\path\to\app.exe

The launcher stages the ZLUDA compatibility DLLs beside the target application and sets HIP/ROCm runtime paths for that run. You can stage without launching with stage-runtime.ps1 -TargetDir <dir>.

Step 4: Diagnose. Three diagnostic scripts exist: doctor.ps1, gpu-scan.ps1, and test-runtime.ps1. The scanner records model, gfx architecture, driver, and HIP info without collecting usernames, tokens, or user files.

What runs, what breaks

This is the part most coverage skips, and it is where the decision matrix lives. From the repo's own coverage table on the validated setup:

CUDA driver (nvcuda): passes.
cuBLAS, via rocBLAS: passes.
cuBLASLt, via hipBLASLt: passes.
cuSPARSE, via rocSPARSE: passes.
cuFFT: passes.
cuDNN: unavailable with the validated stable Windows HIP SDK.

That last line is the big one. The stable Windows HIP SDK does not ship MIOpen, so convolution-heavy software that needs cuDNN may need a nightly HIP stack or additional work. Dense, GEMM-heavy workloads like the validated PPO run do not require cuDNN and pass. The repo also lists NCCL, TensorRT, unsupported PTX behavior, and some custom CUDA extensions as likely failures.

The honest summary: dense linear algebra runs. Convolution and multi-GPU work mostly does not. Local LLM enthusiasts should note that llama.cpp and friends have native ROCm/Vulkan paths that are more reliable than any translation layer; ZLUDA is for CUDA-only software with no AMD port, not for workloads that already have a native path.

What you should actually do, by use case

You train small RL or dense models on a single AMD card: promising. The validated workload is exactly this shape. Expect friction, budget an afternoon for the install, and file GPU compatibility reports; the repo explicitly asks for failed tests too.
You need cuDNN, NCCL, or TensorRT: not yet. Wait for the Windows HIP SDK to ship MIOpen, or use Linux + native ROCm.
You run local LLMs: skip this. Use llama.cpp with its native Vulkan or ROCm backend. Translation layers are for CUDA-only software, and llama.cpp is not CUDA-only.
You are deciding between an NVIDIA and AMD GPU purchase today: this project is a good reason to expect the gap to close, not a reason to buy AMD today. Only one card is validated. Treat it as a signal, not a spec sheet.
You are a library author: your library's CUDA-only assumptions are a product liability. If a weekend project can translate your calls to a rival's runtime, your lock-in was never technical. It was social.

Why this matters beyond Windows

The deeper story is what the moat actually was. If one unfunded developer plus AMD's public SDK can translate the CUDA API surface for dense training workloads, then CUDA's dominance was always more about ecosystem gravity than technical impossibility. Add three concurrent eroding forces:

Native ROCm ports (PyTorch, llama.cpp, vLLM on Linux) make the translation layer unnecessary for the biggest workloads.
Translation layers (ZLUDA) catch the long tail of CUDA-only software.
The Nvidia-Hugging Face deal announced September 3, where Nvidia bought the distribution layer of open-weight AI for $12.93 billion, shows even Nvidia is behaving like the moat is shifting from "developers must use CUDA" to "developers must stay in Nvidia's orbit."

That last point deserves its own article, and it will get one. For now, note the pattern: everyone in the AI infrastructure business is suddenly very keen to tell you their platform is open and neutral. When the chip monopolist buys the GitHub of AI, "open" is doing a lot of work in that sentence.

For AMD, the math is simple. There are far more AMD GPUs in consumer Windows machines than in Linux datacenter boxes. Every point of ZLUDA coverage makes those cards more useful for AI work, and every validated GPU report expands the compatibility table. The moat does not crack with an announcement. It cracks with a scriptable installer, pinned hashes, and one GPU at a time.

Subscribe and questions

I write about developer tools, AI infrastructure, and the business of open source every week. Subscribe, it is free, and you will get the follow-up on the Nvidia-Hugging Face deal and what it means for open-weight AI.

Have you tried ZLUDA or the HIP SDK on Windows? What worked, what failed, and on which card? Drop a comment with your GPU model and results; the project's compatibility table grows from exactly these reports.