ZLUDA stack brings CUDA apps to AMD's RX 9060 XT on Windows

A GitHub project called CUDA-for-AMD-Windows (Speedstu/CUDA-for-AMD-Windows) has published what it calls a reproducible Windows CUDA compatibility stack, built around ZLUDA and AMD HIP/ROCm, that lets CUDA-targeted Windows applications, including CUDA-enabled LibTorch workloads, run on an AMD GPU. The stack layers a CUDA-targeted application on ZLUDA, which maps cuBLAS, cuSPARSE and cuFFT calls onto AMD's rocBLAS, hipBLASLt and rocSPARSE through HIP, with the AMD GPU doing the actual work underneath. The headline claim for this release is that the public, upstream-only path, using only official components and no private or recovered DLLs, has now been tested end to end.

Validated hardware is currently limited to one card, the AMD Radeon RX 9060 XT (gfx1200, RDNA4 architecture). Other AMD GPUs are, in the project's own words, candidates rather than guaranteed working devices, and it asks anyone who tries a different card to file a GPU compatibility report whether it works or fails. On the RX 9060 XT, the tested combination pairs ZLUDA v6-preview.69 (the official ZLUDA release), AMD HIP SDK 6.4 and LibTorch 2.3.0+cu118, and on that combination nvcuda, cuBLAS, cuBLASLt, cuSPARSE and cuFFT all pass ZLUDA's own cuda_check test.

The stack was exercised with a real machine-learning workload rather than a synthetic check. A 2,216,347-parameter PPO (proximal policy optimization) reinforcement-learning network completed forward and inference passes, learning and optimizer steps on the CUDA-facing device, and one clean validation iteration completed 65,536 timesteps; that is the same CUDA-facing LibTorch training workload that originally motivated the project. The project is explicit that this does not mean every CUDA program or AI model works: CUDA API and library coverage is workload-dependent, and this one PPO network is the only workload actually run through the stack end to end.

Setup runs through a PowerShell script, install.ps1, that detects the installed AMD GPU and its native gfx target, verifies the AMD driver, HIP SDK and required math libraries, downloads the pinned official ZLUDA build plus LibTorch 2.3.0+cu118 (about 2.66 GB), checks the downloads' SHA-256 hashes, writes a runtime-config.json and a gpu-report.json, and finally runs ZLUDA's own cuda_check.exe against the installed AMD stack; a -SkipLibTorch flag skips the LibTorch download for anyone who does not need it. A second script, run-zluda.ps1, stages the required ZLUDA compatibility DLLs beside a target application and points it at the HIP/ROCm runtime for that single run, and a related script can stage the runtime into a folder without launching anything. A GPU-scan script records the card's model, gfx architecture, driver and HIP details for a compatibility report; the project states it does not intentionally collect usernames, tokens or user files, and it marks any GPU architecture it recognizes but has not validated as an unverified candidate rather than a supported device, since detecting an architecture is not proof that a workload on it will run.

Earlier work on the project also produced a custom cuBLAS/cuBLASLt/HIP overlay, recovered from an original development environment. Its DLLs are fingerprinted in the repository's manifests but not published as binaries, because the custom wrapper's own source and provenance are incomplete and the recovered runtime bundles third-party AMD binaries. To check whether that overlay was still worth using, the project ran a controlled A/B benchmark on September 13, 2026: 10 iterations per runtime on the same RX 9060 XT PPO workload, discarding each trial's first iteration as warmup. The public upstream path reached a median of 13,278 steps per second overall, against 12,876 for the recovered custom overlay, making the overlay about 3.03% slower on this workload; the project keeps the public upstream path as the default as a result. Separate, earlier tuned runs, using a different training configuration, reached roughly 70,000 to 109,000 steps per second, a figure the project does not present as comparable to the 13,278 versus 12,876 result.

The project lists its own limits plainly. ZLUDA is not a complete CUDA implementation, Windows exposes only a subset of the full ROCm ecosystem, and the stable Windows HIP SDK does not ship the full ROCm AI library stack, including MIOpen, so convolution-heavy software that needs cuDNN can require a newer or nightly HIP stack or extra work; dense or GEMM-heavy LibTorch training does not necessarily need cuDNN, and the validated PPO workload ran without it. NCCL, TensorRT, unsupported PTX behavior and some custom CUDA extensions may fail, and a reported ZLUDA_CC=8.6 value is a CUDA-facing compatibility number rather than a description of the AMD GPU's real architecture. Licensing is split: the project's own scripts and documentation are MIT licensed, while ZLUDA, AMD ROCm/HIP, Nvidia's CUDA components and PyTorch/LibTorch each keep their own separate upstream licenses.

Key facts

The stack is validated on only one card so far, AMD's Radeon RX 9060 XT (gfx1200, RDNA4); other AMD GPUs are untested candidates, and the project asks testers to file a compatibility report either way.
The tested public path pairs ZLUDA v6-preview.69, AMD HIP SDK 6.4 and LibTorch 2.3.0+cu118, on which nvcuda, cuBLAS, cuBLASLt, cuSPARSE and cuFFT all pass ZLUDA's cuda_check test.
Validation ran a real 2,216,347-parameter PPO reinforcement-learning network through forward and inference passes, learning and optimizer steps, completing 65,536 timesteps in one clean iteration.
A controlled A/B benchmark on September 13, 2026 (10 iterations per runtime, first iteration discarded as warmup) measured the public upstream path at a median 13,278 steps per second, against 12,876 for an earlier custom overlay, making the overlay about 3.03% slower; upstream stays the default.
The stable Windows HIP SDK lacks the full ROCm AI library stack, such as MIOpen, so cuDNN-dependent, convolution-heavy workloads may need a newer or nightly HIP build; the validated PPO workload did not need cuDNN.

Why it matters

CUDA lock-in is a real cost for anyone who owns an AMD GPU but needs to run software written against Nvidia's CUDA, and this project's own earlier attempt to bridge that gap relied on a private, unverifiable piece. The news here is not ZLUDA itself, which already exists, but that this project now has a reproducible path built only from official, public components, an official ZLUDA release, AMD's own HIP SDK and stock LibTorch, validated with a real training workload rather than a marketing claim, and benchmarked against its own earlier private overlay rather than simply asserted to work.

Who it affects

AMD GPU owners on Windows who want to run CUDA-targeted software, particularly PyTorch/LibTorch-based machine-learning workloads, without buying Nvidia hardware. Today that means specifically owners of the AMD Radeon RX 9060 XT, the only validated card; owners of other AMD GPUs are invited to extend that validation themselves by running the project's scan and test scripts and reporting whether their card works.

How to use it

Clone the repository and run install.ps1, which detects the installed AMD GPU and its gfx target, checks the AMD driver, HIP SDK and required math libraries, downloads the pinned ZLUDA build and LibTorch 2.3.0+cu118 (about 2.66 GB), verifies the downloads' SHA-256 hashes, and runs ZLUDA's cuda_check.exe against the result; add -SkipLibTorch if LibTorch is not needed. Run run-zluda.ps1 with a target application to stage the ZLUDA compatibility DLLs beside it and point it at the HIP/ROCm runtime for that run, or stage the runtime into a folder first without launching anything; separate scripts cover diagnostics, a GPU scan and a runtime test. The project's own scripts and documentation are MIT licensed; ZLUDA, AMD ROCm/HIP, Nvidia's CUDA components and PyTorch/LibTorch each keep their own separate upstream licenses.

How solid is it

The claim rests on one validated card and one real workload: a 2,216,347-parameter PPO network trained through forward and inference passes, learning and optimizer steps, for 65,536 timesteps in one clean run, on the exact CUDA-facing LibTorch setup that motivated the project. The decision to keep the public path as the default rests on a controlled, repeated benchmark, 10 iterations per runtime with the first iteration of each discarded as warmup, rather than a single measurement, and the install script hash-checks its own downloads. Working against that: only one GPU is validated end to end, every other card is an unverified candidate, and detecting a GPU's architecture is explicitly not treated as proof that a given workload will run on it. The project itself is explicit that this does not mean every CUDA program or AI model works, since CUDA API and library coverage is workload-dependent and only the one PPO network above has actually been run through the stack end to end. A private overlay exists, but its own DLLs are not published because their source and provenance are incomplete, which limits how independently that specific piece can be checked.

Risks and caveats

By the project's own account, ZLUDA is not a complete CUDA implementation and Windows exposes only a subset of the full ROCm ecosystem. The stable Windows HIP SDK does not ship the full ROCm AI library stack, including MIOpen, so convolution-heavy software that needs cuDNN can require a newer or nightly HIP stack or extra work, though the validated PPO workload, being dense and GEMM-heavy rather than convolution-heavy, did not need cuDNN. NCCL, TensorRT, unsupported PTX behavior and some custom CUDA extensions may fail. A reported ZLUDA_CC=8.6 value is a CUDA-facing compatibility number, not a description of the AMD GPU's actual architecture. Licensing is mixed across the stack's components, and the GPU-scan script, while stated not to intentionally collect usernames, tokens or user files, does record the card's model, gfx architecture, driver and HIP details for its compatibility report.

“Detection is not proof that a workload runs.”

— CUDA-for-AMD-Windows (GitHub README)