The distinction matters. Windows users evaluating this route need to treat it as an experimental compatibility stack with real setup, maintenance, and application-coverage risks. It may be valuable for a specific project that matches the tested path. It is not yet a sound basis for buying hardware, deploying a production workstation, or assuming a CUDA-only application will run.
What the project says it achieved
The project, called CUDA-for-AMD-Windows, combines AMD’s HIP/ROCm components with ZLUDA, a compatibility layer intended to let software making CUDA-facing calls use an AMD GPU backend. It is not presented as a newly written CUDA runtime. Rather, it assembles existing upstream components into a Windows configuration targeted at a particular workload.
Its documented public validation used Windows x64, a Radeon RX 9060 XT identified as gfx1200, AMD HIP SDK 6.4, ZLUDA v6-preview.69, and LibTorch 2.3.0+cu118. The project says its verification executable successfully exercised the CUDA driver-facing interface plus cuBLAS, cuBLASLt, cuSPARSE, and cuFFT.
That library list is meaningful, but it should be read precisely. Passing checks for those components indicates that selected CUDA-style interfaces and math-library calls worked in that environment. It does not prove that every code path inside those libraries works, that arbitrary applications will load, or that results will match an NVIDIA system in every workload.
The maintainer also reports completing one Proximal Policy Optimization training iteration of 65,536 timesteps using a 2,216,347-parameter model. If accurately reproduced, that is stronger evidence than a simple device-detection demonstration: it indicates one CUDA-enabled LibTorch workload got through inference-facing work and a learning/update phase on the AMD Windows stack.
Even so, it remains a project-authored result. No independent reproduction is included in the available record, and one completed iteration is not a broad reliability study. It does not establish compatibility with proprietary CUDA applications, older codebases, scientific software, game-development tools, or the wide variety of custom extensions used in practical AI workflows.
The installer improves repeatability, not the compatibility guarantee
One of the more useful aspects of the project is its attempt to make a fragile stack repeatable. Its installer documentation describes detecting the AMD GPU and graphics target, checking for the relevant driver and HIP SDK pieces, obtaining pinned dependency versions, validating downloads with SHA-256 hashes, and running a CUDA check after setup.
The pinned combination includes ZLUDA v6-preview.69 and LibTorch 2.3.0+cu118. Pinning matters because compatibility work often depends on a particular interaction among drivers, compiler targets, library ABIs, and replacement DLLs. A setup that works with one preview build can fail after an apparently routine component update.
For users, that means the project’s automation should be understood as a way to reproduce its tested recipe. It is not a promise that the newest driver, the newest ZLUDA release, a different PyTorch build, or a different Radeon card will behave identically.
There is already evidence of why that caution is appropriate. ZLUDA had released v7-preview.10 on August 26, 2026, while the project continued to pin v6-preview.69. That version gap does not demonstrate a defect in the chosen stack; older pinned builds are often deliberate in reproducibility work. But it does mean the project’s validated setup is not synonymous with the latest upstream preview, and updating individual layers casually may invalidate the result.
Before testing, a sensible Windows user should isolate the environment, record the exact driver and library versions, retain installers and hashes, and make a rollback plan. A development PC used for other GPU tools may be especially vulnerable to conflicts when several applications expect different versions of low-level runtime files.
cuDNN is the important boundary
The clearest documented limitation is cuDNN. On the stable official Windows HIP SDK route, the test utility cannot load cuDNN 8 or cuDNN 9 because the SDK does not include MIOpen, AMD’s corresponding neural-network library layer.
This is not a minor footnote for AI users. Many deep-learning workloads depend heavily on convolution operations and cuDNN-backed code paths. A framework may launch and still fail when it reaches the particular model, operator, or acceleration route that requires cuDNN. A test that exercises cuBLAS and cuFFT cannot substitute for testing convolution-heavy training or inference software.
The project’s materials point toward a nightly or newer stack, or further work, as possible avenues for such cases. That is not the same as a verified solution. Anyone whose workflow explicitly requires cuDNN should assume the stable Windows setup is unsuitable unless they can validate their exact model and package combination themselves.
Other major warning signs include TensorRT, NCCL, unsupported PTX behavior, and some custom CUDA extensions. These should be treated as likely compatibility boundaries, not as features that have been established as working. TensorRT matters for optimized inference deployments; NCCL matters for many multi-GPU and distributed workflows; PTX handling and custom extensions matter because real-world Python and C++ AI projects often compile or load specialized code outside a framework’s basic binary distribution.
In short, the stack appears most plausible where an application relies on the demonstrated API and library subset, ships compatible binaries, and does not need the missing AI-library pieces. The further a workload departs from that profile, the less the reported result says about it.
AMD’s official Windows support has narrower goals
It would be inaccurate to frame this project as proof that AMD officially offers general CUDA compatibility on Windows. AMD’s own Windows documentation identifies PyTorch support for particular listed Radeon hardware configurations, while also stating that the entire ROCm stack is not yet supported on Windows.
AMD further characterizes Windows availability as PyTorch rather than the broader ROCm stack available on Linux. Its listed limitations include no ML training support and officially supported LLM batch sizes of one only. Those statements define AMD’s official support boundary; a successful community experiment beyond that boundary does not change it.
This creates an unusual but important contrast. The project maintainer reports a PPO learning iteration, which is an interesting experimental result. AMD’s documented Windows limitations still mean users cannot reasonably treat that result as vendor-supported ML training. If a workstation is used for paid production work, compliance-sensitive research, classroom labs, or a deadline-driven deployment, the distinction affects who can help when an update breaks the environment.
There is a second scope issue around GPU support. The RX 9060 XT is the project’s only validated reference GPU in the supplied evidence. That does not mean it is the only Radeon GPU supported by AMD’s Windows HIP SDK; AMD lists multiple supported Radeon families and graphics targets. Conversely, AMD support for a GPU does not show that this ZLUDA-based project has validated it. “Supported by AMD” and “tested by this compatibility project” are separate claims.
Users with another Radeon card should therefore not extrapolate from the RX 9060 XT result. At most, it supplies a reason to investigate whether the necessary graphics target and HIP components exist for their hardware. It is not a compatibility certification.
What the benchmark does—and does not—measure
The project also published a controlled comparison for its PPO workload on the RX 9060 XT. It reported a median overall rate of 13,278.46 steps per second for the public upstream path and 12,875.80 steps per second for a recovered custom overlay, placing that overlay 3.03% behind on that exact test.
That is a narrow but potentially useful A/B result. It compares two versions of the project’s compatibility setup on one workload and one GPU. It does not compare AMD hardware with an NVIDIA CUDA system. It does not quantify how closely ZLUDA tracks native CUDA performance. And it does not establish performance for image generation, large-language-model inference, scientific computing, rendering, or gaming workloads.
The project documentation also warns against a common misreading: a later native HIP rewrite was a different implementation and must not be presented as a measurement of ZLUDA overhead. Without the same workload and implementation running natively on both paths under comparable conditions, assigning a translation-layer penalty would be speculation.
For practical evaluation, throughput alone is not enough. Users should also check numerical outputs, model convergence where applicable, memory use, startup reliability, repeated-run stability, and behavior after driver updates. A compatibility layer that is fast on one benchmark but intermittently fails during a long job may be a poor trade for a serious workflow.
Maintenance and provenance are deployment risks
The software’s sustainability deserves consideration alongside raw capability. ZLUDA’s maintainer stated in June 2026 that commercial funding had ended and development had returned to being a weekend project. That does not predict a specific bug or abandonment, and it should not be used to dismiss the work. It does mean users should set realistic expectations about the speed of fixes for new drivers, new GPU generations, framework changes, or unexpected application failures.
The project’s custom overlay adds a separate concern. Its source and provenance are incomplete, and the repository intentionally does not distribute its binary overlay or AMD runtime files. The published, reproducible route is therefore more relevant than the recovered overlay for most users, even if the latter appears in benchmark material.
Licensing is also more complex than a single “open source” label suggests. The project’s own scripts and documentation are MIT-licensed, but the installed stack draws on multiple upstream components, including ZLUDA, AMD software, NVIDIA CUDA-related components, and LibTorch. Each carries its own licensing and redistribution terms. Developers planning to bundle anything, ship a commercial product, or deploy across an organization should review the terms for every included component rather than relying on the repository’s license alone.
A realistic decision framework for Windows users
This work is best approached as a targeted experiment. It may be worth trying when all of the following are true:
- Your hardware closely matches the validated Radeon RX 9060 XT configuration, or you can accept that another GPU is unvalidated.
- Your workload can run from a clean, disposable environment rather than a critical production installation.
- It depends primarily on the documented working CUDA-facing libraries.
- You can test the exact executable, model, extensions, and inputs that matter to you.
- You have a fallback path, such as an NVIDIA system, a Linux ROCm setup where appropriate, or a CPU-capable mode.
It is a poor fit when a workflow depends on cuDNN, TensorRT, NCCL, distributed training, arbitrary PTX, undocumented custom extensions, vendor support, or predictable long-term maintenance. It is also a poor foundation for interpreting AMD’s official Windows AI support more broadly than AMD documents.
The underlying achievement should not be understated: a documented Windows configuration reportedly drove selected CUDA-facing libraries and completed a CUDA-enabled LibTorch PPO iteration on a Radeon RX 9060 XT. That is useful technical evidence and a promising direction for experimentation. But it remains evidence for one carefully bounded compatibility case. Until broader, independent testing covers more applications, GPUs, and failure modes, “CUDA on AMD in Windows” should be read as an invitation to validate a specific workload—not as a blanket compatibility promise.