The userspace vs kernelspace distinction is important here. Nvidia contributing userspace code with dependencies on their hardware and proprietary drivers is part of a lock-in strategy. Contributing open-source drivers would be a very different thing, and would undermine at least some of their product segmentation strategies.

Yet CUDA is still fully proprietary & total vendor lock-in...

Kinda surprising AMD hasn't made their own CUDA compiler and set of libraries.

They have (sort of): https://github.com/ROCm-Developer-Tools/HIP

It just isn't very good yet.

However, it features in the preparation for the Frontier supercomputer, I think, though I can't immediately find the OCLF material I saw.

I think the theory is that that's what OpenCL is, but for most people if you're building a dedicated cluster, you're buying Nvidia hardware anyway, and if you already are using the hardware for it, you might as well go native and get the best performance and library support.

OpenCL is no match for CUDA.

Stuck in pure C, printf style debugging with graphical debuggers that never properly handled everything.

CUDA, polyglot GPGPU development environment, graphical debuggers that allow for single stepping and conditional breakpoints in GPGPU code, interoperability with graphical APIs.

OTOY just replaced their rendering code in Octane Render from Vulkan to CUDA (via Optix 7).

Yet no competition was able to provice a polyglot OpenCL and IDE with graphical GPGPU debuggers.

Failure of execution from the competion is also to blame.

Yes, OpenCL finally adopted SPIR-V, when it was down and the referee started the countdown.

What's actually "open source" about what they have made themselves, as possibly opposed to modifying existing stuff? There's a significant effect of being proprietary in that people like me can't distribute packages using it for Fedora, Debian, SUSE, etc.