-
Notifications
You must be signed in to change notification settings - Fork 787
[SYCL] Implement sycl_ext_oneapi_memcpy2d extension #7370
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
Changes from all commits
455139f
6a2222a
970b68a
62decf0
f58953a
285ff31
6dde11a
24e218e
d9e7d00
a9b4a3b
6f3ad00
eb364c9
0bd93fe
8e36fed
a1a0076
cc9ac20
5c02839
acbb364
3ef3420
2447cc7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -68,9 +68,15 @@ | |
// 12.20 Added piextQueueCreate API to be used instead of piQueueCreate, also | ||
// added PI_EXT_INTEL_DEVICE_INFO_MAX_COMPUTE_QUEUE_INDICES for piDeviceGetInfo. | ||
// Both are needed to support sycl_ext_intel_queue_index extension. | ||
// 12.21 Added new piextUSMEnqueueFill2D, piextUSMEnqueueMemset2D, and | ||
// piextUSMEnqueueMemcpy2D functions. Added new | ||
// PI_EXT_ONEAPI_CONTEXT_INFO_USM_FILL2D_SUPPORT, | ||
// PI_EXT_ONEAPI_CONTEXT_INFO_USM_MEMSET2D_SUPPORT, and | ||
// PI_EXT_ONEAPI_CONTEXT_INFO_USM_MEMCPY2D_SUPPORT context info query | ||
// descriptors. | ||
|
||
#define _PI_H_VERSION_MAJOR 12 | ||
#define _PI_H_VERSION_MINOR 20 | ||
#define _PI_H_VERSION_MINOR 21 | ||
|
||
#define _PI_STRING_HELPER(a) #a | ||
#define _PI_CONCAT(a, b) _PI_STRING_HELPER(a.b) | ||
|
@@ -335,7 +341,11 @@ typedef enum { | |
PI_CONTEXT_INFO_REFERENCE_COUNT = 0x1080, | ||
// Atomics capabilities extensions | ||
PI_CONTEXT_INFO_ATOMIC_MEMORY_ORDER_CAPABILITIES = 0x10010, | ||
PI_CONTEXT_INFO_ATOMIC_MEMORY_SCOPE_CAPABILITIES = 0x10011 | ||
PI_CONTEXT_INFO_ATOMIC_MEMORY_SCOPE_CAPABILITIES = 0x10011, | ||
// Native 2D USM memory operation support | ||
PI_EXT_ONEAPI_CONTEXT_INFO_USM_FILL2D_SUPPORT = 0x30000, | ||
PI_EXT_ONEAPI_CONTEXT_INFO_USM_MEMSET2D_SUPPORT = 0x30001, | ||
PI_EXT_ONEAPI_CONTEXT_INFO_USM_MEMCPY2D_SUPPORT = 0x30002 | ||
} _pi_context_info; | ||
|
||
typedef enum { | ||
|
@@ -1809,6 +1819,62 @@ __SYCL_EXPORT pi_result piextUSMGetMemAllocInfo( | |
pi_context context, const void *ptr, pi_mem_alloc_info param_name, | ||
size_t param_value_size, void *param_value, size_t *param_value_size_ret); | ||
|
||
/// USM 2D fill API | ||
/// | ||
/// \param queue is the queue to submit to | ||
/// \param ptr is the ptr to fill | ||
/// \param pitch is the total width of the destination memory including padding | ||
/// \param pattern is a pointer with the bytes of the pattern to set | ||
/// \param pattern_size is the size in bytes of the pattern | ||
/// \param width is width in bytes of each row to fill | ||
/// \param height is height the columns to fill | ||
/// \param num_events_in_waitlist is the number of events to wait on | ||
/// \param events_waitlist is an array of events to wait on | ||
/// \param event is the event that represents this operation | ||
__SYCL_EXPORT pi_result piextUSMEnqueueFill2D(pi_queue queue, void *ptr, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The similar "buffer" API use "Rect" instead of "2D". I think we should unify names if possible (especially for Unified Runtime). Tag @kbenzie There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @veselypeta this is relevant to oneapi-src/unified-runtime#107 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @smaslov-intel the difference with There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does it not make sense to add 3D for USM? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 3D could make sense, that would be outside of the scope of this extension though. I'm less sure if combining the 2D and 3D entry points into a rect entry point is the right way to go though. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. if we were to split 2D/3D then maybe we should do the same to the existing Rect API four buffers |
||
size_t pitch, size_t pattern_size, | ||
const void *pattern, size_t width, | ||
size_t height, | ||
pi_uint32 num_events_in_waitlist, | ||
const pi_event *events_waitlist, | ||
pi_event *event); | ||
|
||
/// USM 2D Memset API | ||
/// | ||
/// \param queue is the queue to submit to | ||
/// \param ptr is the ptr to fill | ||
/// \param pitch is the total width of the destination memory including padding | ||
/// \param value the value to fill into the region in \param ptr | ||
/// \param width is width in bytes of each row to fill | ||
/// \param height is height the columns to fill | ||
/// \param num_events_in_waitlist is the number of events to wait on | ||
/// \param events_waitlist is an array of events to wait on | ||
/// \param event is the event that represents this operation | ||
__SYCL_EXPORT pi_result piextUSMEnqueueMemset2D( | ||
pi_queue queue, void *ptr, size_t pitch, int value, size_t width, | ||
size_t height, pi_uint32 num_events_in_waitlist, | ||
const pi_event *events_waitlist, pi_event *event); | ||
|
||
/// USM 2D Memcpy API | ||
/// | ||
/// \param queue is the queue to submit to | ||
/// \param blocking is whether this operation should block the host | ||
/// \param dst_ptr is the location the data will be copied | ||
/// \param dst_pitch is the total width of the destination memory including | ||
/// padding | ||
/// \param src_ptr is the data to be copied | ||
/// \param src_pitch is the total width of the source memory including padding | ||
/// \param width is width in bytes of each row to be copied | ||
/// \param height is height the columns to be copied | ||
/// \param num_events_in_waitlist is the number of events to wait on | ||
/// \param events_waitlist is an array of events to wait on | ||
/// \param event is the event that represents this operation | ||
__SYCL_EXPORT pi_result piextUSMEnqueueMemcpy2D( | ||
pi_queue queue, pi_bool blocking, void *dst_ptr, size_t dst_pitch, | ||
const void *src_ptr, size_t src_pitch, size_t width, size_t height, | ||
pi_uint32 num_events_in_waitlist, const pi_event *events_waitlist, | ||
pi_event *event); | ||
|
||
/// API to get Plugin internal data, opaque to SYCL RT. Some devices whose | ||
/// device code is compiled by the host compiler (e.g. CPU emulators) may use it | ||
/// to access some device code functionality implemented in/behind the plugin. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder, why
0x30000
and not0x20000
, for example? Is it documented anywhere which values should be picked up for new capabilities?Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we have any rules necessarily. All these values are taken from OpenCL so we normally just try and move around what values are in OpenCL when adding extension values. In theory it should be fine as long as they don't conflict with any values in the same category, but it's good to keep a buffer.