Open-source project ZLUDA lets CUDA apps run on AMD GPUs
An open-source project called ZLUDA aims to let CUDA applications run on AMD GPUs, reviving hopes for breaking Nvidia’s dominance in GPU-accelerated computing. Commenters weigh the technical and legal hurdles, from Nvidia’s EULA restrictions and reliance on proprietary libraries like cuDNN to the challenges of clean-room reimplementation and performance parity. Much of the debate centers on AMD’s long‑criticized software ecosystem and strategic choices, including why it stopped funding ZLUDA and whether alternatives like ROCm, HIP, or open standards can ever rival CUDA’s maturity and lock-in.
Scope of ZLUDA and Legal Constraints
- ZLUDA is a clean-room, drop‑in CUDA implementation targeting non‑Nvidia GPUs (Intel first, now AMD).
- Nvidia’s CUDA EULA has, since at least 2022, banned using SDK outputs to target non‑Nvidia platforms and running key libraries (e.g., cuDNN, cuBLAS) on other hardware.
- Debate over enforceability:
- One side: emulation and API re‑implementation are generally legal; if you never agreed to Nvidia’s EULA you’re not bound, and this may be anti‑competitive.
- Other side: if apps bundle Nvidia binaries, their licenses may forbid running them on third‑party runtimes; DMCA and prior OS‑on‑non‑vendor‑hardware cases suggest strong legal risk for commercial use.
- Clean‑room reverse engineering is possible but expensive and hard to keep current; doing this for all Nvidia libraries is a major barrier.
AMD’s Strategy and Software Ecosystem
- Many argue AMD’s biggest weakness is software: buggy OpenCL/ROCm/HIP stacks, unstable drivers, and short support windows, despite decent hardware.
- AMD funded ZLUDA for ~2 years, then stopped, claiming “no business case”; code became open source per contract.
- Some see that as a missed opportunity and “absurd,” since it immediately benefits AMD users.
- Others argue it’s rational: a robust CUDA‑on‑AMD layer could further entrench CUDA by letting developers stay Nvidia‑centric while using AMD only as cheaper execution hardware.
Technical and Practical Limitations
- Key difficulty is not basic kernel translation but high‑performance, maintained equivalents for Nvidia’s libraries (cuDNN, cuBLAS, etc.).
- Nvidia has PTX as a stable IR; AMD often compiles per‑architecture, complicating long‑term support and community optimization.
- Reports of ZLUDA + llama.cpp working but slower than native ROCm; AMD APUs are typically bottlenecked by memory bandwidth and small effective “VRAM.”
- Some hobbyists report good experiences with small LLMs on consumer AMD GPUs; others recount persistent crashes, segfaults, and driver bugs.
Alternatives and Standards
- Mentioned alternatives: HIP/HIPIFY (source translation, not runtime), ROCm, OpenCL, Vulkan compute, SYCL, OpenMP GPU offload.
- Several commenters argue AMD and Intel should jointly push open standards like SYCL; others note that fragmentation and poor implementations have limited traction.
Broader Market Perspective
- Multiple comments frame Nvidia, AMD, and Intel as acting like aspiring monopolists once they gain power.
- There is speculation that regulators, especially in the EU, may eventually view Nvidia’s restrictions as anti‑competitive, but outcomes are unclear.