dk Dark Knight 2026-09-14 6 min read

CUDA for AMD on Windows: Repo Audit and 3% Verdict

Hacker News is eating a repo called CUDA-for-AMD-Windows this morning — created 2026-09-13T13:23 UTC, 68 stars within hours, promising exactly what every AMD GPU owner on Windows has wanted since ZLUDA's original sponsor walked away: run CUDA-targeted Windows binaries on a Radeon. I cloned it and audited all 1,590 lines — every PowerShell script, both hash manifests, and the benchmark JSON. Verdict up front: this is one of the most provenance-honest repos I've read this year, and its own data says you should use the boring upstream path.

What it actually does

No magic, no patched drivers. It stages a pinned stack:

graph TD
  A[CUDA-targeted Windows .exe] --> B[ZLUDA v6-preview.69]
  B --> C[cuBLAS / cuSPARSE / cuFFT shims]
  C --> D[rocBLAS / hipBLASLt / HIP SDK 6.4]
  D --> E[AMD GPU]

The installer (scripts/install.ps1, 60 lines) chains doctor → setup → verify → runtime test. setup.ps1 downloads exactly two binaries, both pinned:

# from scripts/setup.ps1 and manifests/upstream-assets.sha256
ZLUDA v6-preview.69  (32,944,552 bytes)
  E2959ED1...E5D9A  from github.com/vosen/ZLUDA official releases
LibTorch 2.3.0+cu118 (2,660,890,386 bytes)
  E7D57EE5...5C6CC  from download.pytorch.org

Both verified with Get-FileHash -Algorithm SHA256 before use. No untracked URLs, no random CDN, no Invoke-Expression anywhere in the download path. That's rarer than it should be.

The recovered-DLL story — where it gets interesting

Buried in docs/RECOVERY_NOTES.md and docs/CUSTOM_OVERLAY.md is the real narrative. The author had a private, faster stack built around custom BLAS DLLs — a modified cublas64_11.dll with rocBLAS routing, and three cuBLASLt shims that identify themselves as a HumanLikeRL cublasLt shim, compiled from cublasLtShim.c. Then the disks changed, and the source was gone. Only binaries survived.

Most maintainers would ship the DLLs. This one didn't. The publication rule in the recovery notes is a single sentence worth quoting in every ML infra repo: "Do not silently invent source for the recovered DLLs. Keep hashes and provenance." The custom binaries are kept locally, hashed in manifests/recovered-artifacts.sha256, and A/B-tested — but the public runtime uses only upstream ZLUDA. Binary archaeology instead of binary distribution. That's the correct call, and it's the first time I've seen it made under this exact circumstance.

The benchmark says no to the fancy path

The repo's own controlled A/B (2026-09-13, RX 9060 XT, 2,216,347-parameter PPO network, 8 measured iterations per runtime, warmup discarded) is in benchmarks/ as JSON and CSV. I loaded it:

overall SPS, median:   upstream 13,278.46   custom 12,875.80   →  custom -3.03%
collection SPS, median: upstream 63,306.00   custom 59,360.67   →  custom -6.23%
inference, median:      upstream  0.5863s    custom  0.6293s    →  custom +7.33%

The custom overlay that took months of reverse-engineering effort is 3.03% slower than stock ZLUDA v6-preview.69 on this workload. The repo publishes that result and recommends against its own custom stack. Receipts beating rhetoric, inside a repo most people will only read the headline of.

The fine print nobody on HN is reading

Bottom line

If you have an RX 9060 XT and a CUDA LibTorch workload on Windows, this repo is a real, hash-verified, reproducible path — run install.ps1, use the upstream runtime, ignore the overlay. If you have any other AMD card, you're an untested data point, not a user. And regardless of hardware: bookmark this repo as the template for how to handle lost source under binaries. Hashes, honest benchmarks against your own prized work, and a refusal to ship opaque DLLs. The 3% loss was the author's own code losing to the stack it extended — and they published it anyway. That's rarer than the CUDA compatibility itself.

Related