Skip to content

Conversation

@gmarkall
Copy link
Contributor

The docs state that pointer should be a c_void_p, but the rest of the driver binding code expects the pointer to be represented as a CUdeviceptr when the NVIDIA bindings are in use.

If we're given a c_void_p by the user when using the NVIDIA bindings, we can work around this by converting it to a CUdeviceptr.

This was first noticed when testing PyArrow with Numba-CUDA. See apache/arrow#47128

@copy-pr-bot
Copy link

copy-pr-bot bot commented Jul 17, 2025

Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

@gmarkall
Copy link
Contributor Author

/ok to test

@gmarkall
Copy link
Contributor Author

/ok to test

@gmarkall gmarkall added 3 - Ready for Review Ready for review by team and removed 2 - In Progress Currently a work in progress labels Jul 18, 2025
@gmarkall gmarkall marked this pull request as ready for review July 18, 2025 12:17
@copy-pr-bot
Copy link

copy-pr-bot bot commented Jul 18, 2025

Auto-sync is disabled for ready for review pull requests in this repository. Workflows must be run manually.

Contributors can view more details about this message here.

gmarkall added 2 commits July 18, 2025 13:22
The docs state that `pointer` should be a `c_void_p`, but the rest of
the driver binding code expects the pointer to be represented as a
`CUdeviceptr` when the NVIDIA bindings are in use.

If we're given a `c_void_p` by the user when using the NVIDIA bindings,
we can work around this by converting it to a `CUdeviceptr`.

This was first noticed when testing PyArrow with Numba-CUDA. See
apache/arrow#47128
@gmarkall gmarkall force-pushed the memorypointer-type-fix branch from e8f88e5 to 0f8ea88 Compare July 18, 2025 12:22
@gmarkall
Copy link
Contributor Author

/ok to test

@kkraus14 kkraus14 merged commit 3129f55 into NVIDIA:main Jul 18, 2025
39 checks passed
gmarkall added a commit to gmarkall/numba-cuda that referenced this pull request Jul 18, 2025
- Add deadlock warnings to Stream.add_callback and Stream.async_done docstrings (NVIDIA#321)
- `MemoryPointer`: ensure `CUdeviceptr` used with NVIDIA binding (NVIDIA#328)
- Fix indexing GPUs with CUdevice object (NVIDIA#319)
- Fix bindings: consistency of contexts, streams, and events, similar to NVIDIA#295 (NVIDIA#296)
- Fix nvrtc resolution when CUDA_HOME env is set (NVIDIA#314)
@gmarkall gmarkall mentioned this pull request Jul 18, 2025
gmarkall added a commit that referenced this pull request Jul 18, 2025
- Add deadlock warnings to Stream.add_callback and Stream.async_done docstrings (#321)
- `MemoryPointer`: ensure `CUdeviceptr` used with NVIDIA binding (#328)
- Fix indexing GPUs with CUdevice object (#319)
- Fix bindings: consistency of contexts, streams, and events, similar to #295 (#296)
- Fix nvrtc resolution when CUDA_HOME env is set (#314)
atmnp pushed a commit to atmnp/numba-cuda that referenced this pull request Jul 21, 2025
…A#328)

* `MmemoryPointer` ensure `CUdeviceptr` used with NVIDIA binding

The docs state that `pointer` should be a `c_void_p`, but the rest of
the driver binding code expects the pointer to be represented as a
`CUdeviceptr` when the NVIDIA bindings are in use.

If we're given a `c_void_p` by the user when using the NVIDIA bindings,
we can work around this by converting it to a `CUdeviceptr`.

This was first noticed when testing PyArrow with Numba-CUDA. See
apache/arrow#47128

* Correct device pointer value usage in EMM test
atmnp pushed a commit to atmnp/numba-cuda that referenced this pull request Jul 21, 2025
- Add deadlock warnings to Stream.add_callback and Stream.async_done docstrings (NVIDIA#321)
- `MemoryPointer`: ensure `CUdeviceptr` used with NVIDIA binding (NVIDIA#328)
- Fix indexing GPUs with CUdevice object (NVIDIA#319)
- Fix bindings: consistency of contexts, streams, and events, similar to NVIDIA#295 (NVIDIA#296)
- Fix nvrtc resolution when CUDA_HOME env is set (NVIDIA#314)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

3 - Ready for Review Ready for review by team

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants