Commit a7d4c35

- ``cuda.core`` now requires a minimum ``cuda-bindings`` version per CUDA major: 12.9.8 for

CUDA 12 and 13.5.0 for CUDA 13. See the breaking changes below.

- ``cuda.core`` now requires a minimum ``cuda-bindings`` version per CUDA major, at build and run

time: 12.9.8 for CUDA 12 and 13.5.0 for CUDA 13. See the

:ref:`support policy <cuda-core-bindings-floor>`. ``import cuda.core`` with an older

``cuda-bindings`` fails with a message that names the required version and how to install it.

``pip install cuda-core[cu12]`` or ``pip install cuda-core[cu13]`` installs a compatible

version. Supported CUDA drivers and CUDA Toolkit libraries are unchanged. Previously

``cuda.core`` accepted any ``cuda-bindings`` of the right major, and an older one produced import

errors for missing C functions, silently disabled features, or crashes.

(https://github.com/NVIDIA/cuda-python/issues/2783)

- A source build of ``cuda.core`` must use a ``cuda.h`` of the same major.minor as its

``cuda-bindings``. If they differ, the build fails early.

(https://github.com/NVIDIA/cuda-python/issues/2783)

- A source build of ``cuda.core`` now compiles against the CCCL headers pinned in the

``cuda_core/third_party/cccl`` submodule, and fails without them. Clone with

``git clone --recurse-submodules``, or run

``git submodule update --init cuda_core/third_party/cccl`` in an existing clone. The

``CCCL_HOME`` environment variable is no longer read.

(`#2940 <https://github.com/NVIDIA/cuda-python/pull/2940>`__)

- With the ``cuda-bindings`` floor in place, whether a feature is available now depends only on

the CUDA driver and the ``cuda.core`` build's CUDA major. The checks that also inspected the

``cuda-bindings`` version are gone, and so are their error messages. Error messages that name a

minimum now name a driver version. ``cuda.core.system`` always uses NVML through

``cuda-bindings``, so ``cuda.core.system.CUDA_BINDINGS_NVML_IS_COMPATIBLE`` is always ``True``.

:mod:`cuda.core.checkpoint` requires the CUDA 13 build of ``cuda.core`` and now says so. That

requirement was already in effect, because the CUDA 12 ``cuda-bindings`` lack a type it uses.

(https://github.com/NVIDIA/cuda-python/issues/2783)

- The C++ layer calls the driver through the entry points ``cuda-bindings`` resolves rather than

through its Cython wrappers. As a result, a driver function that the installed driver lacks can

no longer surface as ``SystemError`` from a C++ call.

(https://github.com/NVIDIA/cuda-python/issues/2783)

and nvJitLink would otherwise silently omit them. Incremental links with

link-time optimization disable the nvJitLink intermediate cache, which

crashed after repeated links on Windows.

``ValueError``.

(`#2954 <https://github.com/NVIDIA/cuda-python/issues/2954>`__)

- A failed IPC export that receives an invalid file descriptor from the

driver now raises the original error. The rollback used to close the

invalid descriptor and replace the error with ``EBADF``.

12.8 drivers, although the driver supports them. This regression is present

since 1.2.0.

- :meth:`SMResource.split` with ``dry_run=True`` raises on

CUDA 13 when a group requests a nonzero SM count.