The CUDA/HIP APIs are mostly C-like APIs but are really C++ language extensions. e.g. you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it.
The GPU kernel code itself needs to be compiled and for CUDA that is done with the proprietary nvcc, which is clang-based. HIP is better because it's an open-source llvm backend/frontend but you'd still need to add GPU-specific support to zig/rust/whatever.
> you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it.
It all boils down to calling CUDA runtime or driver APIs. Compiler just sprinkles fairly trivial amount of syntactic sugar, and under-the-hood glue code. One can launch GPU kernel from a pure C source file compiled with gcc.
> The GPU kernel code itself needs to be compiled and for CUDA that is done with the proprietary nvcc, which is clang-based.
nvcc is not the only option. Clang itself can compile most of existing CUDA code just fine, and the rest usually needs minimal porting.
Also, nvcc is not based on clang. It may use it as the host compiler, but that's the extent of its involvement with clang. IIRC, their front-end used to be based on EDG.
> HIP is better because it's an open-source llvm backend/frontend
CUDA and HIP share most of the front-end code in clang, so CUDA compilation with clang shares the same benefits. What's missing is PTX to SASS assembler, which creates the actual GPU binary, and that part is proprietary to NVIDIA.
AFAIK PTX compilation is the bit that is not mature in the Rust CUDA ecosystem as well, because it has to be reverse engineered rather than simply translated.