Skip to content

[RFC] Make cuda.core a required dependency #128

Closed
1 of 2 issues completed
Closed

Description

@leofang

Recent works in cuda.core/cuda.bindings have reached to a point where we can replace most, if not all, numba-cuda internal wrappers to driver, nvvm, linker, … by cuda.core. It has been the plan to make cuda.core a required (not just optional) dependency of numba-cuda (and cuda.bindings would become a transitive dependency). There are multiple benefits, such as

  • separation of concerns: numba-cuda focuses on the compiler stack and leave CUDA’s Python exposure to CUDA Python
  • support CUDA wheels out of box (so issue 65 and issue 66 do not need any effort on the numba-cuda side)
  • better performance (since cuda-bindings is based on Cython instead of ctypes)
  • support Windows (which pynvjitlink does not, as of today)
  • coverage of latest CUDA features
  • …

This RFC is created to track necessary efforts:

Activity

  1. realarnavgoel commented on Mar 6, 2025

    @realarnavgoel

    @leofang Does cuda.core._launcher support option in LaunchConfig to select cuLaunchCooperativeKernel or cuLaunchKernel depending on the user needs for grid.sync() or other deadlock-free guarantees when performing non-local operations in each GPU (e.g. barrier between GPUs) of a multi-GPU application ?

    numba-cuda supports this automatically and selects the appropriate mechanism in the dispatcher: https://github.com/NVIDIA/numba-cuda/blob/main/numba_cuda/numba/cuda/dispatcher.py#L409

  2. leofang commented on Mar 6, 2025

    @leofang
    MemberAuthor

    Does cuda.core._launcher support option in LaunchConfig to select cuLaunchCooperativeKernel or cuLaunchKernel depending on the user needs for grid.sync() or other deadlock-free guarantees when performing non-local operations in each GPU (e.g. barrier between GPUs) of a multi-GPU application ?

    The beauty of the new cuLaunchKernelEx API is it is not our (cuda.core, and maybe even Numba) job to choose which API to use. We just need to add a new option to LaunchConfig to hook with CU_LAUNCH_ATTRIBUTE_COOPERATIVE as you suggested, so that the driver knows to launch it cooperatively. Please open an issue in NVIDIA/cuda-python to track it.

  3. realarnavgoel commented on Mar 6, 2025

    @realarnavgoel

    Does cuda.core._launcher support option in LaunchConfig to select cuLaunchCooperativeKernel or cuLaunchKernel depending on the user needs for grid.sync() or other deadlock-free guarantees when performing non-local operations in each GPU (e.g. barrier between GPUs) of a multi-GPU application ?

    The beauty of the new cuLaunchKernelEx API is it is not our (cuda.core, and maybe even Numba) job to choose which API to use. We just need to add a new option to LaunchConfig to hook with CU_LAUNCH_ATTRIBUTE_COOPERATIVE as you suggested, so that the driver knows to launch it cooperatively. Please open an issue in NVIDIA/cuda-python to track it.

    Created an issue: NVIDIA/cuda-python#496

  4. added this to the v0.5.0 milestone on Oct 2, 2025
  5. cpcloud commented on Dec 1, 2025

    @cpcloud
    Contributor

    For transparency:

  6. rwgk commented on Dec 1, 2025

    @rwgk

    cuda-python 1036 isn't blocked on anything AFAICT, but maybe @rwgk knows more specifically if anything is blocking there?

    Correct. It's purely a matter of finding the time to work on it.

  7. cpcloud commented on Dec 4, 2025

    @cpcloud
    Contributor

    I added #153 since it's likely we'll need to do that to address the RFC.

  8. cpcloud commented on Dec 15, 2025

    @cpcloud
    Contributor

    #152 and #153 are now hard blocked until StridedLayout (or something like it) exists and StridedMemoryView.from_buffer (or something like it) exists.

  9. gmarkall commented on Dec 18, 2025

    @gmarkall
    Contributor

    If this issue is hard blocked until these exist, it will probably not fit into the 0.24.0 milestone - moving to "next".

  10. modified the milestones: v0.24.0, next on Dec 18, 2025
  11. cpcloud commented on Dec 18, 2025

    @cpcloud
    Contributor

    I don't think this is hard blocked anymore. We made _StridedLayout private, but from_buffer still exists, which should be enough to get us to support Buffer and StridedMemoryView as inputs.

  12. modified the milestones: next, v0.24.0 on Dec 18, 2025
  13. modified the milestones: v0.25.0, next on Feb 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions