For years, anyone needing to run OpenCL code on an NVIDIA GPU had few options beyond the vendor's own implementation. The Mesa project is changing that picture: for the past year, a Gallium3D implementation has been running on top of NVIDIA's CUDA driver API. First known as CLUDA, it is now called NOCL and, paired with Rusticl, works well as a new OpenCL compute option on the NVIDIA proprietary driver.

The technical point is simple but loaded with consequences. Gallium3D is the driver framework inside Mesa, used to expose graphics and compute APIs on different hardware. Rusticl is Mesa's OpenCL implementation built on Gallium3D. NOCL acts as a bridge: it translates Gallium3D calls into the CUDA driver API. As a result, OpenCL workloads do not go through the vendor's OpenCL implementation or the full CUDA toolchain, but only through the lowest layer of the NVIDIA driver.

The thesis to watch is not that CUDA gets replaced. CUDA remains the substrate: NOCL still depends on NVIDIA's proprietary driver. What changes is where the control point sits. An organization that has standardized its compute stack on OpenCL can now consider NVIDIA GPUs without adopting the CUDA ecosystem at the language and runtime level. This matters for teams managing mixed accelerator fleets, self-hosted compute centers, and industrial or scientific software that speaks OpenCL.

There is a second, less visible effect: NOCL makes Rusticl more interesting as an open glue layer for GPU compute. Until now, anyone wanting an open source OpenCL runtime on NVIDIA hardware often had to settle for incomplete support or unofficial paths. With NOCL, the Mesa community has a more coherent route to bring OpenCL workloads onto the NVIDIA driver without depending on the vendor's choices about OpenCL support. It does not remove the hardware constraint: an NVIDIA GPU and its closed driver are still required. But it shifts the dependency from the software layer to the physical one, and that is a substantial difference for long-term infrastructure planning.

For on-prem and self-hosted deployments, the project offers a concrete signal. Those evaluating local acceleration for inference or HPC workloads often face a choice between open stacks that work well on some GPUs and proprietary stacks that bind them to a single supplier. AI-RADAR offers analytical frameworks at /llm-onpremise to assess these trade-offs. In this context, NOCL shows that open source compatibility layers can coexist with proprietary drivers, lowering the exit cost from a software ecosystem without requiring alternative hardware.

Open questions remain about performance, feature completeness, and stability. The source reports no benchmarks, and it would be a mistake to assume that a Gallium3D path over CUDA is already competitive with NVIDIA's native OpenCL implementation. But the structural value is not in the numbers: it is in the compatibility architecture Mesa is building. If NOCL matures, the choice of compute runtime becomes less tied to the vendor's toolkit and more aligned with the actual needs of infrastructure operators.