ZLUDA, the open-source project aiming to run CUDA code on non-NVIDIA GPUs, has added support for some cuFFT APIs by relying on hipFFT. The change, limited to a mathematical library, says a lot about the direction of CUDA compatibility outside NVIDIA's ecosystem.

cuFFT is NVIDIA's library for fast Fourier transforms, an important component in HPC, signal processing, and various scientific workloads. hipFFT is the counterpart AMD provides in its ROCm/HIP stack for the same kind of operations. Implementing some cuFFT APIs through hipFFT is not a minor technical detail: it means ZLUDA is building its compatibility layer not as an isolated reimplementation, but as a bridge to primitives AMD already maintains.

So far, ZLUDA's value has been mostly in reducing lock-in: developers and research groups with existing CUDA codebases can evaluate AMD hardware without rewriting everything. The addition of cuFFT, even if partial, broadens the application scope to workloads that use FFTs intensively. Teams working on signals, simulations, or pipelines combining linear algebra and spectral transforms have one more reason to test Radeon GPUs in the lab. But it would be a mistake to read this news as the end of CUDA's advantage.

The support is limited to some cuFFT APIs, not the entire library. Behavioral differences, real performance, and function coverage remain variable. Moreover, the use of hipFFT ties ZLUDA to the quality and maturity of the ROCm stack, which on certain consumer GPUs and workloads has historically been less uniform than CUDA. For a team evaluating on-premises deployment, this introduces a trade-off: on one side there is the opportunity to reduce dependence on NVIDIA and take advantage of different pricing or availability; on the other side there is a software ecosystem that must be verified function by function, not only at compilation level. AI-RADAR offers analytical frameworks at /llm-onpremise to assess these trade-offs.

The direction is nonetheless clear: compatibility layers are moving toward using the native primitives of alternative vendors instead of emulating CUDA entirely on their own. This could shift incentives: AMD can benefit from an open-source layer that expands the executable code base on its GPUs without convincing every developer to migrate to HIP; NVIDIA, for its part, keeps an advantage in maturity and completeness, but loses exclusivity on less sophisticated workloads. The question is not whether ZLUDA will replace CUDA, but whether it will lower the threshold enough to make non-NVIDIA hardware a pragmatic choice in more contexts. The answer will come from API coverage and real-world testing, not from support announcements.