QWE AI Academy If you own an AMD or Intel GPU, you’ve probably slammed into the same wall a thousand times: the tool you want to run – PyTorch, Blender’s CUDA path, a niche ML repo – assumes Nvidia. That wall just got a little thinner. ZLUDA v6 landed a couple of weeks ago and the discussion around running CUDA on non-Nvidia hardware is loud again, both because the release is genuinely useful and because the project simultaneously lost its commercial funding. Odd timing. Let’s actually use it.
What just happened, in one paragraph
ZLUDA is a drop-in replacement for CUDA on non-Nvidia GPUs that lets you run unmodified CUDA applications with near-native performance. Version 6 dropped in July 2026 and, per the developer’s own blog, it brought 32-bit PhysX support, texture implementation that enables Blender, and better Windows tooling including automatic performance-library loading. The catch: the project is no longer commercially funded and is back to being the author’s weekend project, so priorities shifted to what he finds interesting rather than what makes commercial sense. In other words – it’s the best it’s ever been for hobby use, and the least reliable it’s ever been for anything you’d bet a job on.
Pick the right tool before you install anything
Not every workload wants ZLUDA. There are four real options, and choosing wrong wastes a whole afternoon.
| Tool | What it does | Best for |
|---|---|---|
| ZLUDA | Runs compiled CUDA binaries on AMD ROCm at the driver level | Closed-source apps, Blender, some PyTorch workloads |
| HIPIFY (AMD) | Translates CUDA source code to HIP so you can build for ROCm | You own the source and can rebuild |
| SCALE (Spectral Compute) | Compiles CUDA source directly for AMD GPUs | Devs who want a clean CUDA toolchain without porting |
| SYCLomatic | Migrates CUDA to Data Parallel C++ (DPC++) | Intel hardware / cross-vendor code |
AMD’s HIPIFY converts CUDA source into C++ that runs on ROCm via HIP. Intel’s SYCLomatic migrates CUDA to DPC++, covering roughly 90% automatically – the final 10% needs manual work. ZLUDA is a just-in-time layer that runs CUDA binaries on non-Nvidia hardware without touching source at all. That last part is why it matters: if you have a random binary that only ships CUDA, HIPIFY can’t help you. ZLUDA can. If you have the source and want long-term maintainability, port with HIPIFY or SCALE instead.
Install ZLUDA on AMD (the beginner path)
This is the shortest path that actually works on a modern Radeon. According to the official ZLUDA repository, current support targets AMD Radeon RX 5000 series and newer (as of mid-2026).
- Update AMD drivers. On Windows, install the latest Adrenalin. On Linux, install ROCm – the full stack, not just the runtime.
- Install the latest HIP SDK from AMD. On Windows this is a separate installer. If you have an older HIP SDK already installed, uninstall it first.
- Grab ZLUDA. Download the latest release from the official repo. For AI/Stable Diffusion workloads on Windows, the community fork at
lshqqytiger/ZLUDAis often more current for PyTorch compatibility. - Point your CUDA app at ZLUDA. On Linux, prepend the ZLUDA folder to
LD_LIBRARY_PATH. On Windows, use thezluda.exeloader – v6 handles the performance-library flags automatically now.
For Blender specifically, the app detects a CUDA device once ZLUDA is in the library path and you can select CUDA (not OptiX) as the render backend in Cycles. Textures work in v6, which was the last major missing piece for Blender.
# Linux one-liner to try a CUDA binary through ZLUDA
export LD_LIBRARY_PATH=/opt/zluda:$LD_LIBRARY_PATH
./your_cuda_appThe gotchas nobody puts on the front page
Every beginner tutorial ends at “and it works!” Then reality shows up. Three specific traps:
The Windows performance-library hunt. On Linux, installing ROCm hands you everything at once: runtime driver, performance libraries, monitoring tools. Windows? You get the runtime driver with Adrenalin and nothing else. hipBLASLt – the Windows equivalent of cuBLASLt – hasn’t had an official AMD release as of mid-2026. Same story for MIOpen (the cuDNN equivalent). Unofficial builds exist, but you’ll spend 30 minutes tracking them down and copying DLLs before any ML workload touches your GPU. That’s not a bug in ZLUDA; it’s a gap in AMD’s Windows support that ZLUDA can’t paper over.
The first-run “freeze” that isn’t a freeze. If you’re running Stable Diffusion via SD.Next with ZLUDA, the first generation can take 10-15 minutes – or even longer, some reports say over an hour – while MIOpen finds and caches the optimal kernel. The message “Compilation is in progress. Please wait” will loop repeatedly. Don’t kill the process. Go make coffee. Twice.
The invisible iGPU. If you have an integrated AMD GPU, you may need to disable it or use the HIP_VISIBLE_DEVICES environment variable (per the SD.Next ZLUDA wiki). Symptom: launches fine, then crashes or renders on nothing. The iGPU grabbed the workload.
Pro tip: Set
HIP_VISIBLE_DEVICES=0(or whichever index your discrete card is) as a system environment variable, not just per-session. Every ZLUDA-based tool you install afterward will inherit it, and you’ll skip the exact same debugging session three times.
What performance actually looks like
Numbers first, then context. In the developer’s own PhysX demo, using a Ryzen 9 9950X3D with a Radeon RX 9070 XT at 2560×1440 in the original Mafia II 2010 benchmark, the result went from 26.2 FPS without ZLUDA to 80.2 FPS with ZLUDA. That’s the poster child. It’s also a 15-year-old game running a specific 32-bit PhysX path – don’t extrapolate to your workload.
For ML, the picture is fuzzier. Spectral Compute’s SCALE has published its own benchmarks on its website claiming nearly a 6x performance boost on AMD GPUs compared to HIPIFY-converted CUDA – but no independent lab has reproduced that number in public, as of July 2026. For pure LLM inference, the community read on Hacker News after the v6 release was blunt: Vulkan and ROCm paths have caught up, and for ML/LLMs the native stack has closed the gap with frameworks increasingly supporting AMD directly. Translate that: if llama.cpp already has a Vulkan backend that runs on your card, you probably don’t need ZLUDA.
When NOT to do this
Being honest is more useful than being enthusiastic. Skip ZLUDA if:
- You’re building anything for production. The project is no longer commercially funded and updates will be less frequent, driven by what the developer finds entertaining rather than commercial priorities. Bug in your critical path? You might wait months.
- There’s already a native path. If your framework supports ROCm natively (recent PyTorch, llama.cpp Vulkan, koboldcpp-rocm), use that. Translation always adds a failure surface.
- You need cuDNN-heavy training. On Windows especially – the MIOpen story isn’t there yet.
- You’re on an older Radeon (pre-RX 5000). Officially unsupported as of mid-2026. People make it work, but you’re on your own.
The legal question keeps coming up. Nvidia’s EULA may prohibit running CUDA on non-Nvidia hardware – though no public legal action against ZLUDA has been reported and the project has run for years. Enforceability depends on jurisdiction and implementation details. Not legal advice; just the current state of play as I understand it.
A short story about why this whole thing keeps happening
ZLUDA has been resurrected more times than a bad TV show. Per Tom’s Hardware, it started around 2020 targeting Intel, was abandoned in 2021, came back around 2022 with AMD funding, then AMD cut the funding in 2024 – and in August 2024 even forced the developer to rebuild the code the company had paid for. A second undisclosed sponsor picked up the project after that, bringing it to the v6 milestone. Now that funding is gone too, and it’s back to hobby status.
Every time a GPU company gets close to funding real CUDA independence, they seem to get cold feet. Whether that’s Nvidia’s legal team, market dynamics, or just the ROI math – nobody outside the boardrooms knows. What we know is that a single developer keeps rebuilding it, and each rebuild is a little more usable than the last.
Your next move
If you have an RX 5000 or newer sitting there and a specific CUDA-only tool you’ve been avoiding – download ZLUDA v6 today, spend an hour on the setup, and try it on that one tool. Don’t rebuild your workflow around it yet. Just check whether the thing you thought you couldn’t run actually runs. That’s the whole test.
FAQ
Does ZLUDA work on Intel GPUs?
Not currently. The project started on Intel around 2020 but pivoted to AMD when AMD funded it. Intel support would require a different backend and isn’t on the roadmap as of mid-2026.
Why is my Stable Diffusion generating black images with ZLUDA?
This usually hits older Navi cards and is a numerical precision issue in the ROCm math libraries. The common fix people share in the SD.Next Discord is forcing FP32 in the launch settings (some Fooocus users set FORCE_FP32 = True as a workaround). If FP32 doesn’t help, check that hipBLASLt is actually present in your ROCm folder – the drivers won’t install it for you and its absence causes silent fallback to broken code paths.
Should I use ZLUDA or just port my code with HIPIFY?
Port with HIPIFY if you own the source. HIPIFY produces code that AMD supports directly, so you’re not depending on a weekend project for your production pipeline. Use ZLUDA when you have no choice – closed-source apps, third-party CUDA plugins, or research repos you can’t or don’t want to modify.