CCCL C library should support CUDA minor version compatibility
- Dominant language
- C++
- Stars
- 2.5k
- Forks
- 486
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 295
Description
After #4845 is fixed we still have a problem in supporting CUDA minor version compatibility (MVC). This time the problem is in the usage of driver APIs.
The driver types (over which many of the runtime types are typedef'd) are stable over minor releases, as per @pciolkosz, but not the driver APIs. For how the public driver APIs are redirected to the underlying symbols that could change in minor releases, consult `cuda.h` & co. For this purpose, there are driver (`cuGetProcAddress`) and runtime (`cudaGetDriverEntryPoint{ByVersion}`) APIs for fetching the correct underlying driver symbol in an MVC-complaint manner.
This bug is more serious because it essentially forces users to have the same driver version at run time as the one used at build time, which most of time is a very stringent limitation.
There are a few solutions:
1. Statically link to `cudart` and use the runtime counterparts instead. Most of CUDA libraries do this and it's the simplest solution. Starting CUDA 12.0 we should have everything that we need (ex: `CUkernel` -> `cudaKernel_t`).
2. Statically link to `cudart` and use `cudaGetDriverEntryPoint{ByVersion}` to fetch the needed driver function pointer. This is [what cudax does today](https://github.com/NVIDIA/cccl/blob/main/cudax/include/cuda/experimental/__utility/driver_api.cuh).
3. Auto-generate a shim layer over all needed driver APIs that does `cuGetProcAddress` under the hood. This is what [`cuda.bindings.driver` does today](https://github.com/NVIDIA/cuda-python/blob/d1c8b0fd2206fb4a3061c2145447e3291d02e0a7/cuda_bindings/cuda/bindings/_bindings/cydriver.pyx.in#L539).
We should fix this asap, though I am not sure if this is a must-fix before releasing the first wheels.
Contributor guide
Assessment
This issue has not been assessed yet.