Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add documentation of getPtr to overview.md #375

Merged
merged 10 commits into from
Jan 16, 2025
17 changes: 17 additions & 0 deletions cuda_bindings/docs/source/overview.md
Original file line number Diff line number Diff line change
Expand Up @@ -312,6 +312,23 @@ maximize performance ({numref}`Figure 1`).
Screenshot of Nsight Compute CLI output of CUDA Python example.
```

## Getting the address of underlying C objects from the low-level bindings
ksimpson-work marked this conversation as resolved.
Show resolved Hide resolved

Within the low-level object wrappers there are a number of cdef classes which effectively provide a PyObject interface to cuda types such as CUdevice, which will be used an example
in this section. The definition is as follows:
ksimpson-work marked this conversation as resolved.
Show resolved Hide resolved

```cython
cdef class CUdevice:
...

def __int__(self):
return <int>self._ptr[0]
def getPtr(self):
return <void_ptr>self._ptr
```

There is an important distinction between the `getPtr()` method and the behaviour of `__int__()`. If the user wants to get the address of the underlying C object, wrapped in the cdef python class, they should call `int(CUdeviceInstance)`, which returns a pointer to the object, while calling `CUdeviceInstance.getPtr()` returns the `void**` address of the pointer to the object.
ksimpson-work marked this conversation as resolved.
Show resolved Hide resolved

## Future of CUDA Python

The current bindings are built to match the C APIs as closely as possible.
Expand Down