CUDA for AMD on Windows: ZLUDA + HIP Setup Guide (2026)

CUDA for AMD on Windows (GitHub: Speedstu/CUDA-for-AMD-Windows) is a reproducible setup stack for running CUDA-targeted Windows applications on AMD GPUs, without an NVIDIA GPU. It combines ZLUDA (a CUDA driver API compatibility layer) with AMD's HIP SDK/ROCm libraries via a set of scripts, primarily targeting CUDA-facing compute workloads such as those using CUDA-enabled LibTorch. It hit the Hacker News front page in September 2026, reaching 135 points and 68 comments (all figures in this article are as of September 14, 2026).

As the README explicitly states, this project does not claim that every CUDA program or AI model works. What's published is a record of actually testing the public, upstream-only path — using only the official ZLUDA release and AMD HIP SDK, with no private or recovered DLLs. The validated environment is as follows.

- ZLUDA v6-preview.69 (official release)
- AMD HIP SDK 6.4
- LibTorch 2.3.0+cu118
- Validated GPU: Radeon RX 9060 XT (gfx1200)
- nvcuda, cuBLAS, cuBLASLt, cuSPARSE, and cuFFT all pass cuda_check
- A 2,216,347-parameter PPO neural network completed forward/inference, training, and optimizer steps
- One validation run completed 65,536 timesteps on the reference workload

Following the README's own diagram, the translation happens in five stages. A CUDA-targeted Windows app's call first reaches ZLUDA, which stands in for the CUDA driver API (nvcuda). From there it passes through a compatibility layer for CUDA library calls such as cuBLAS, cuBLASLt, cuSPARSE, and cuFFT, which get translated into the AMD HIP SDK's own libraries — rocBLAS, hipBLASLt, rocSPARSE, and HIP. The call is finally executed on the AMD GPU. From the application's point of view it's still calling CUDA; underneath, everything is delegated to AMD's libraries.

As of September 14, 2026, the only AMD GPU this project labels "validated" is the Radeon RX 9060 XT (gfx1200, RDNA4). Every other AMD GPU is treated as a candidate, not a guaranteed working device, and the README asks users to file a GPU compatibility report — whether it works or fails — as a GitHub issue.

Setup breaks into two phases: a one-time run of install.ps1, and run-zluda.ps1 as the launcher used every time you run an app.

install.ps1 detects the AMD GPU and its gfxXXXX target, verifies the AMD driver/HIP SDK and required math libraries, downloads the pinned official ZLUDA Windows build, fetches LibTorch 2.3.0+cu118, verifies the downloaded files' SHA-256 hashes, generates .runtime\runtime-config.json and .runtime\gpu-report.json, and finally runs ZLUDA's own cuda_check.exe against the installed stack — all in one pass.

run-zluda.ps1 stages the required ZLUDA compatibility DLLs beside the target application's working folder and sets the HIP/ROCm runtime paths scoped to that one run, before launching the app. Rather than permanently rewriting system-wide environment variables, it restages the DLLs next to the app on every launch — a practical detail worth understanding before deploying it broadly.

The README lists CUDA-facing library calls (nvcuda, cuBLAS, cuBLASLt, cuSPARSE, cuFFT) and GEMM-heavy LibTorch training workloads as confirmed working. In practice, a roughly 2.2 million-parameter PPO network reportedly completed both training and inference cleanly. The following, however, are currently unsupported or unstable.

- cuDNN/MIOpen: not included in the validated stable HIP SDK, so convolution-heavy (CNN) workloads may not work. Dense/GEMM-heavy LibTorch training doesn't strictly require cuDNN, and the validated PPO workload completed without it
- NCCL and TensorRT: the README explicitly notes these may fail
- Unsupported PTX instructions and some custom CUDA extensions: may fail
- ZLUDA's own limits: the README states plainly that "ZLUDA is not a complete CUDA implementation," so coverage is workload-dependent

Early in development, the project also experimented with an unpublished custom cuBLAS/cuBLASLt/HIP overlay. But in a controlled A/B test run on September 13, 2026 (10 iterations per runtime on the same RX 9060 XT PPO workload, with the first iteration of each trial discarded as warmup), the public upstream-only path reached a median 13,278 SPS versus 12,876 SPS for the custom overlay — the overlay was about 3.03% slower. Based on this result, the project defaults to the upstream-only path and does not publish the custom overlay's binaries (its provenance is incomplete, and the recovered HIP runtime contains third-party AMD binaries). Separately, historical tuned runs under a different training configuration reportedly reached roughly 70k–109k overall steps/s.

Several other paths exist for running CUDA-targeted software, or equivalent compute, on AMD hardware. They differ in Windows support, setup complexity, and how thoroughly they've been validated.

As the table shows, CUDA for AMD on Windows' distinguishing goal is running existing CUDA-targeted Windows apps unmodified. DirectML and Vulkan backends each require writing (or using an already-ported) code against their own API, whereas the ZLUDA-style approach intercepts CUDA calls themselves underneath the app — making it an option when you want to keep using an existing CUDA-dependent codebase as-is.

The scripts and documentation the project itself publishes are MIT licensed, free to use, modify, and redistribute. ZLUDA, AMD ROCm/HIP, NVIDIA CUDA components, and PyTorch/LibTorch each retain their own upstream licenses, though, so it's worth checking those before relying on this stack. The README explicitly lists the following limitations.

- Only the RX 9060 XT (gfx1200) is currently validated
- ZLUDA is not a complete CUDA implementation
- Windows exposes only a subset of the full ROCm ecosystem
- cuDNN/MIOpen is unavailable on the validated stable HIP SDK path
- NCCL, TensorRT, unsupported PTX behavior, and some custom CUDA extensions may fail
- The ZLUDA_CC=8.6 environment variable is a CUDA-facing compatibility value, not the actual AMD GPU architecture

The GPU scanner (gpu-scan.ps1) records the GPU model, gfx architecture, driver, and HIP information, and the README states it does not intentionally collect usernames, tokens, or user files. Even so, given that the stack bundles third-party binaries, it's worth checking it against your organization's software and security policies before adopting it.

- AMD Threadripper Halo Station Explained: 96-Core CPU, 576GB HBM3E AI Workstation (Sept 2026)