Skip to content

Commit

Permalink
Add some description for behaviour of the urMemGetNativeHandle for CU…
Browse files Browse the repository at this point in the history
…DA and HIP
  • Loading branch information
hdelan committed Jan 12, 2024
1 parent 2910cd4 commit a63c1e2
Show file tree
Hide file tree
Showing 3 changed files with 39 additions and 1 deletion.
19 changes: 19 additions & 0 deletions scripts/core/CUDA.rst
Original file line number Diff line number Diff line change
Expand Up @@ -148,6 +148,25 @@ take the extra global offset argument. Use of the global offset is not
recommended for non SYCL compiler toolchains. This parameter can be ignored if
the user does not wish to use the global offset.

Interoperability
================

Unified Runtime offers a number of entry points in order to get native handles
for UR objects. The native handle may refer to a number of different native CUDA
types, depending on the entry point called.

- ${x}MemGetNativeHandle stores a ``CUdeviceptr`` in the ${x}_native_handle_t
argument passed. The ``CUdeviceptr`` will be resident on the
${x}_device_handle_t provided as an argument, if the device shares a context
with the ${x}_mem_handle_t. If the ${x}_device_handle_t argument passed to
${x}MemGetNativeHandle is ``nullptr``,
``UR_RESULT_ERROR_UNSUPPORTED_FEATURE`` will be returned.

..
TODO: add more descriptions of the native types that will be stored in
ur_native_handle_t types for different calls to urTypeGetNative and
urTypeCreateWithNativeHandle.
Other Notes
===========

Expand Down
19 changes: 19 additions & 0 deletions scripts/core/HIP.rst
Original file line number Diff line number Diff line change
Expand Up @@ -91,6 +91,25 @@ take the extra global offset argument. Use of the global offset is not
recommended for non SYCL compiler toolchains. This parameter can be ignored if
the user does not wish to use the global offset.

Interoperability
================

Unified Runtime offers a number of entry points in order to get native handles
for UR objects. The native handle may refer to a number of different native HIP
types, depending on the entry point called.

- ${x}MemGetNativeHandle stores a ``hipDeviceptr_t`` in the
${x}_native_handle_t argument passed. The ``hipDeviceptr_t`` will be resident
on the ${x}_device_handle_t provided as an argument, if the device shares a
context with the ${x}_mem_handle_t. If the ${x}_device_handle_t argument
passed to ${x}MemGetNativeHandle is ``nullptr``,
``UR_RESULT_ERROR_UNSUPPORTED_FEATURE`` will be returned.
..
TODO: add more descriptions of the native types that will be stored in
ur_native_handle_t types for different calls to urTypeGetNative and
urTypeCreateWithNativeHandle.

Other Notes
===========

Expand Down
2 changes: 1 addition & 1 deletion scripts/core/memory.yml
Original file line number Diff line number Diff line change
Expand Up @@ -435,7 +435,7 @@ params:
- type: $x_device_handle_t
name: hDevice
desc: |
[in] handle of the device that the native handle will be resident on.
[in] handle of the device on which the native handle will reside.
- type: $x_native_handle_t*
name: phNativeMem
desc: |
Expand Down

0 comments on commit a63c1e2

Please sign in to comment.