CUDA for AMD on Windows Works, but Only Through a Narrow Compatibility Path

AMD users now have a reproducible CUDA for AMD on Windows setup, despite CUDA remaining an NVIDIA platform. The community project translates selected CUDA calls through ZLUDA, then executes them through AMD's HIP libraries. Its creator reports one completed AI training workload on a Radeon RX 9060 XT.

That achievement matters because it crosses a difficult boundary. Developers can start with a Windows application built for NVIDIA's software stack and run it against one supported AMD configuration. They do not need to rewrite that application for HIP first.

However, the result does not make CUDA hardware-neutral. The setup depends on a compatibility layer, pinned software versions, and incomplete library replacements. Only one GPU model currently has validated status in the project.

The real contest is therefore not simply AMD versus NVIDIA hardware. It is compatibility with existing CUDA applications versus the reliability of native vendor support. The new setup advances the first goal without delivering the second.

The Project Turns a CUDA Binary Into an AMD Workload

The important change is a documented, repeatable path from a CUDA-facing Windows application to an AMD GPU.

The open-source compatibility project packages installation, runtime staging, diagnostics, and validation scripts. It builds on ZLUDA and AMD's Windows HIP software rather than implementing another GPU runtime from scratch.

ZLUDA is a translation layer that presents CUDA-compatible interfaces to an application. It redirects supported operations into corresponding functions available through the host GPU stack.

HIP, the Heterogeneous-compute Interface for Portability, is AMD's C++ runtime and kernel language for portable GPU software. In this setup, HIP provides the lower layer that ultimately communicates with the Radeon GPU.

The path starts with a Windows program expecting NVIDIA CUDA components. ZLUDA receives those calls and routes supported library operations into AMD equivalents.

For example, cuBLAS operations can reach rocBLAS, while cuSPARSE calls can reach rocSPARSE. These libraries handle common linear algebra and sparse-matrix workloads.

The repository includes a PowerShell installer that checks the detected GPU, driver, HIP SDK, and required math libraries. It then downloads a pinned ZLUDA build and verifies downloaded files through SHA-256 hashes.

The installer can also retrieve LibTorch 2.3.0 built for CUDA 11.8. LibTorch is the C++ distribution of PyTorch, used when applications embed PyTorch functions without a Python runtime.

That download is about 2.66 GB, according to the repository. Users who do not need LibTorch can skip it.

After installation, the scripts create machine-specific runtime and GPU reports. Another diagnostic runs ZLUDA's cuda_check utility against the installed AMD stack.

Launching an application requires the project's wrapper script. It places the necessary compatibility libraries beside the target executable and configures the HIP runtime paths for that process.

This local staging model limits system-wide changes. It also exposes a central weakness: each application still depends on the exact CUDA functions and libraries that ZLUDA can translate.

The project reports successful checks for the CUDA driver interface, cuBLAS, cuBLASLt, cuSPARSE, and cuFFT. Those results apply to its validated machine and software combination.

They do not establish general compatibility across Windows applications. A program can pass basic runtime checks while later reaching an unsupported function during a different workload.

The repository states that only the Radeon RX 9060 XT, identified by AMD's gfx1200 target, has validated-reference status. Other detected Radeon architectures remain unverified candidates.

That language is important. Detection means a script recognizes the device and its architecture. It does not mean the application, translation layer, and libraries will work together.

Why CUDA for AMD on Windows Matters Now

The project attacks the migration cost around CUDA applications, not CUDA's ownership or NVIDIA's hardware advantage.

CUDA is NVIDIA's parallel-computing platform and programming model. Its programming model covers kernel execution, memory management, synchronization, and libraries optimized for NVIDIA GPUs.

Many applications rely on more than CUDA-flavored source code. They call libraries such as cuBLAS, cuFFT, cuSPARSE, and cuDNN, while depending on specific runtime behavior.

This accumulated software creates switching costs. Buying a different GPU does not automatically make a CUDA-targeted Windows program portable.

Developers normally have three broad options. They can remain on NVIDIA hardware, port the program to another interface, or place a translation layer between the application and hardware.

AMD supports the porting route through HIP. Its HIPIFY tools translate many CUDA source constructs into portable HIP C++.

Source conversion can be a sound long-term choice when developers control the application. It also demands testing, maintenance, and sometimes manual changes around unsupported APIs.

That route does little for a user who has only a compiled Windows binary. It also creates work for small teams maintaining CUDA-specific dependencies.

ZLUDA targets that gap. It attempts to preserve the application's expected CUDA-facing interface while translating operations at runtime.

This approach resembles a compatibility bridge more than a new programming standard. The application continues speaking CUDA, while the bridge maps supported requests into AMD's software stack.

Windows makes the problem particularly relevant. AMD has expanded its GPU-compute support there, but its Windows stack has historically exposed fewer components than ROCm on Linux.

AMD describes the Windows HIP SDK as a subset of the broader ROCm platform. Its support matrices also limit official coverage to listed operating systems and GPUs.

Recent ROCm releases have improved native Windows options, including PyTorch support on selected Radeon hardware. Native support reduces the need for translation when applications already offer an AMD path.

Yet native PyTorch support does not solve every CUDA dependency. A Windows application might bundle a CUDA-specific LibTorch build or directly load NVIDIA libraries.

The new repository addresses that less convenient situation. Its stated motivation was a CUDA-facing LibTorch training application that needed to run on an AMD desktop GPU.

The project reports that its test application completed inference, reinforcement-learning updates, and optimizer work. The network contained 2,216,347 parameters and ran one validation iteration covering 65,536 timesteps.

Those figures describe one real workload rather than a synthetic API probe. They give the project more credibility than a launcher that only starts an application window.

Still, the test remains narrow. A relatively small reinforcement-learning network cannot represent every transformer, image generator, scientific simulation, or rendering pipeline.

The development pressure falls most directly on AMD's Windows software experience. Each successful compatibility experiment highlights demand for applications that still assume CUDA.

NVIDIA also faces a different kind of pressure. Translation layers test how much of CUDA's application base depends on essential interfaces that another runtime can reproduce.

Neither pressure produces an immediate platform shift. It does show that developers continue searching for ways around vendor-specific application boundaries.

The Mechanism Preserves APIs, Not the Full CUDA Platform

ZLUDA can translate selected interfaces, but CUDA applications often depend on behavior extending far beyond those interfaces.

A CUDA application usually contains host code running on the CPU and device work running on the GPU. The host allocates memory, transfers data, and launches kernels.

The binary can also call optimized libraries. Those libraries often determine whether an AI or scientific application works at useful speed.

ZLUDA presents replacements for CUDA-facing components and connects them to non-NVIDIA backends. On AMD hardware, those backends use HIP and ROCm libraries.

This model can work well when a program stays within implemented runtime functions and mapped libraries. It becomes fragile when the application expects missing behavior.

Version compatibility adds another layer. CUDA applications can target different toolkits, binary formats, libraries, and compiler assumptions.

The repository pins ZLUDA v6 preview 69, AMD HIP SDK 6.4, and LibTorch 2.3.0 with CUDA 11.8. Pinning converts a moving collection of dependencies into one testable combination.

That discipline improves reproducibility. It also means users should not assume newer components are interchangeable.

A newer HIP SDK can change library paths, exported symbols, or supported device targets. A newer CUDA-facing application can call functions that its pinned compatibility layer does not implement.

The project reports that cuBLAS, cuBLASLt, cuSPARSE, and cuFFT passed its runtime check. These components cover important matrix, sparse-compute, and Fourier-transform operations.

The most significant missing piece is cuDNN. NVIDIA's CUDA Deep Neural Network library provides optimized primitives used by many neural-network workloads.

The repository says cuDNN is unavailable with its validated stable Windows HIP SDK configuration. It also notes that the SDK lacks the complete ROCm AI library collection available elsewhere.

That omission creates a hard application boundary. Convolution-heavy software expecting cuDNN can fail, require a newer development stack, or need additional compatibility work.

The successful reinforcement-learning workload did not require cuDNN for its tested path. Dense matrix operations were sufficient for the functions it exercised.

That detail explains both the result and its limits. The project selected a workload compatible with the libraries available on its machine.

Runtime translation also differs from source portability. HIP source can be compiled and optimized for different backends, while a binary compatibility layer must infer and redirect existing behavior.

Source-level work gives developers more control over architecture-specific tuning. Translation offers faster initial access when modifying the original application is impractical.

Neither method guarantees identical performance. GPUs differ in execution width, memory behavior, instruction support, and specialized hardware.

A translated function can produce correct output while using a less efficient path. Conversely, a mapped vendor library can perform well because AMD already optimized the underlying operation.

This explains why one benchmark cannot settle the wider performance question. Translation overhead is only one factor, while library selection and kernel behavior can dominate total runtime.

The repository recorded a controlled comparison on September 13, 2026. It ran ten iterations per runtime on the same RX 9060 XT reinforcement-learning workload.

After removing each trial's first warmup iteration, the upstream path reached a reported median of 13,278 overall steps per second. A recovered custom overlay reached 12,876.

The repository calculates that the custom overlay was about 3.03 percent slower in that test. It therefore keeps the public upstream path as its default.

This comparison evaluates two compatibility configurations on one machine. It does not compare the Radeon card with an NVIDIA GPU or a native HIP implementation.

Historical numbers in the repository used another training configuration. They cannot be directly compared with the controlled test.

For developers, the useful result is simpler. The public components completed the chosen workload without private or recovered binary files.

That makes the procedure easier to inspect and reproduce. Independent results on other hardware will determine whether it becomes more than a single-machine reference.

One Verified GPU Leaves a Large Compatibility Gap

The setup is an experiment with evidence, not general CUDA support for Radeon cards.

The RX 9060 XT is currently the only validated device listed by the project. The scripts recognize additional AMD architecture families but label them as candidates.

AMD's official support matrix is a separate constraint. The company states that GPUs absent from its current table are not officially supported by the relevant Windows distribution.

Even a listed GPU does not inherit the repository's validation. Official HIP support and successful CUDA translation test different layers of the system.

A user needs a compatible AMD driver, working HIP installation, supported libraries, correct ZLUDA behavior, and an application that stays inside implemented coverage.

Failure in any layer can produce an error or incorrect result. Some problems will appear during installation, while others will emerge only after sustained computation.

Correctness deserves more attention than application launch success. Numerical workloads can complete while producing output that differs because of precision, library, or implementation behavior.

A serious validation plan should compare expected outputs, training behavior, and repeatability. It should also test memory pressure, long runs, and recovery from errors.

The repository provides scripts and a documented workload, which helps other users begin that process. Independent validation remains sparse because the project is new and hardware coverage is narrow.

ZLUDA itself describes its software as a drop-in CUDA replacement for non-NVIDIA GPUs. Its public repository also carries a long list of implementation changes and preview releases.

However, a drop-in interface does not equal complete behavioral compatibility. The ZLUDA release history reflects ongoing fixes for loaders, compiler behavior, data types, and CUDA-version handling.

Preview software can introduce regressions. A project that pins one working release avoids some movement but also misses later compatibility fixes.

Windows security software creates another practical risk. Runtime interception and library redirection can resemble techniques used by malicious software.

Users should obtain binaries only from identified upstream releases and verify hashes. They should not disable broad security controls merely to force an unknown package to run.

The repository's hash verification is useful here. It reduces the chance that a changed download silently enters the runtime.

It does not audit the upstream code or establish the safety of every dependency. Organizations should apply their normal software review and artifact-control procedures.

Licensing also deserves careful handling. The repository includes its own license and third-party notices, while ZLUDA uses open-source licenses.

CUDA remains an NVIDIA platform with proprietary components and licensing terms. Users must understand which redistributable files their application contains and what the compatibility setup downloads.

The repository emphasizes a public upstream-only path. That choice helps separate the current method from earlier experimental arrangements involving recovered or private libraries.

Enterprise teams face another issue: support ownership. AMD does not officially support a community CUDA compatibility recipe simply because it uses the HIP SDK.

NVIDIA does not support CUDA applications running on AMD GPUs. The project maintainer cannot replace either vendor's service commitments.

That makes the setup poorly suited to workloads requiring guaranteed uptime without extensive internal qualification. It remains more attractive for labs, hobbyists, and developers testing portability.

Teams evaluating it should preserve machine reports, exact package versions, validation outputs, and application logs. A searchable engineering knowledge base can keep those artifacts connected to each test.

They should also isolate testing from production environments. A dedicated machine or disposable Windows image makes rollback easier when drivers or libraries conflict.

The central question is not whether a sample launches. It is whether the exact application produces correct, repeatable results across the team's required hardware.

Compatibility Layers Put CUDA’s Software Advantage Under a New Test

The project challenges CUDA's application lock-in at the edges, while reinforcing how difficult complete compatibility remains.

NVIDIA's advantage includes hardware, drivers, compilers, debugging tools, optimized libraries, documentation, and years of application integration. CUDA is the interface connecting those pieces.

A compatibility project can reproduce selected calls without reproducing that entire development environment. This difference explains why such projects generate attention before they achieve broad reliability.

For AMD, compatibility offers a way to reach applications that vendors have not ported. Native ROCm and HIP support remains the cleaner route when developers maintain both backends.

The two strategies can coexist. Translation serves existing CUDA binaries, while HIP supports software designed or converted for cross-vendor deployment.

DirectML and other Windows interfaces offer additional alternatives. They can provide vendor-neutral acceleration, but applications must explicitly adopt them.

OpenCL and SYCL also pursue portability at different levels. Their presence has not erased CUDA-specific libraries or application assumptions.

The Hacker News discussion exposed this tension. Some commenters argued that open standards deserve more attention because closed interfaces restrict hardware choice.

Others stressed that portable interfaces often deliver weaker developer experiences. Another critical view held that hardware-specific optimization prevents one generic layer from matching every vendor.

Both positions describe real constraints. Developers want portability, yet high-performance kernels depend on architecture details and tuned libraries.

ZLUDA chooses compatibility over purity. It lets the application keep its CUDA-facing assumptions and translates what it can.

That approach reduces initial migration work. It also preserves CUDA as the language the application expects, rather than replacing it with an independent standard.

This is the project's central reversal. Running a CUDA-targeted program on AMD can weaken hardware lock-in while leaving software dependence on CUDA intact.

If more applications work, CUDA could function like a widely targeted interface whose binaries reach several backends. That outcome would pressure NVIDIA's hardware exclusivity.

If compatibility remains workload-specific, the experiments can instead demonstrate the depth of NVIDIA's software integration. Every missing library becomes another reason developers stay on supported CUDA hardware.

AMD's native Windows progress changes the calculation. Better HIP libraries and wider PyTorch support give translation projects a stronger foundation.

They also reduce the need for translation when applications can adopt official AMD packages. That is a healthy form of overlap, not necessarily a conflict.

The important competitive signal will be application behavior. Support matrices matter, but users experience compatibility through programs that install, finish work, and return correct results.

A list of translated API names cannot substitute for that evidence. Neither can an isolated benchmark with no comparable native implementation.

The most valuable future reports will describe the application version, GPU, driver, HIP SDK, ZLUDA release, exercised libraries, output checks, and sustained performance.

Negative reports will be equally important. A documented failure identifies the missing function or incompatible assumption that maintainers must address.

This evidence can also guide application vendors. Repeated failures around one dependency can justify a native HIP backend or another portable execution path.

The repository therefore matters even if it never becomes a universal runtime. It creates a reproducible test surface for measuring where CUDA dependence begins and ends.

Three Signals Will Determine What Happens Next

Broader hardware reports, deeper library coverage, and stable application results will decide whether this becomes a practical Windows option.

The first signal is independent validation across additional Radeon GPUs. The RX 9060 XT result needs replication on officially supported RDNA3 and RDNA4 hardware.

Successful reports should include exact versions and output checks. A simple screenshot or detected device name will not establish workload compatibility.

Several consistent results would strengthen the claim that the setup is portable across AMD's Windows devices. Frequent architecture-specific failures would narrow it to a reference configuration.

The second signal is cuDNN or equivalent neural-network coverage. Many AI applications rely on operations that the validated stable stack does not currently provide through this path.

Support could arrive through a newer HIP distribution, added ZLUDA mappings, application changes, or another library bridge. Each route carries different maintenance costs.

Working convolution-heavy applications would materially expand the project's relevance. Continued absence would keep many image and model workloads outside its practical reach.

The third signal is stability across application and toolkit updates. The current success depends on pinned versions of ZLUDA, HIP, and CUDA-facing LibTorch.

Developers should watch whether later ZLUDA releases preserve the test, whether newer Windows HIP packages remain compatible, and whether newer applications introduce unsupported calls.

A compatibility project gains value when upgrades do not require rediscovering a fragile combination. Regressions would indicate that the approach still needs intensive manual maintenance.

Performance should follow correctness in that evaluation. A translated application that occasionally returns wrong results has little value, regardless of throughput.

After correctness, comparisons should include a native HIP build where one exists. They should also use equivalent application settings and the same hardware.

NVIDIA comparisons can answer a purchasing question, but they do not isolate translation overhead. GPU architecture, memory capacity, and vendor libraries can all affect the result.

The current project has already cleared one meaningful threshold. It turned a collection of upstream components into a repeatable Windows procedure and completed its motivating workload.

It has not cleared the threshold implied by its memorable title. CUDA for AMD on Windows remains a compatibility claim tied to specific software and one validated GPU.

Developers interested in testing should begin with the repository's documented versions and diagnostic scripts. They should verify their GPU against AMD's current support list before installing anything.

Next, they should choose a workload with a known-correct reference result. That reference matters more than whether the program detects a device named CUDA.

Teams should record failures and publish reproducible compatibility reports when possible. Shared evidence will reveal whether the bridge supports a category of applications or only isolated examples.

The larger question now has a measurable form: how much CUDA software can move to AMD hardware without source changes, and what breaks first?

For the next several months, watch the compatibility matrix, cuDNN-related progress, and results from real Windows applications. Those signals will decide whether CUDA for AMD on Windows becomes dependable or remains an instructive experiment.