@@ -277,6 +277,39 @@ native handle to a driver handle. For example, OpenCL platform
277277may expose an extension ${x}ProgramCreateWithNativeHandle to retrieve
278278a cl_program.
279279
280+ Memory
281+ ======
282+
283+ UR Mem Handles
284+ --------------
285+
286+ A ${x}_mem_handle_t can represent an untyped memory buffer object, created by
287+ ${x}MemBufferCreate, or a memory image object, created by ${x}MemImageCreate.
288+ A ${x}_mem_handle_t manages the internal allocation and deallocation of native
289+ memory objects across all devices in a ${x}_context_handle_t. A
290+ ${x}_mem_handle_t may only be used by queues that share the same
291+ ${x}_context_handle_t.
292+
293+ If multiple queues in the same ${x}_context_handle_t use the same
294+ ${x}_mem_handle_t across dependent commands, a dependency must be defined by the
295+ user using the enqueue entry point's phEventWaitList parameter. Provided that
296+ dependencies are explicitly passed to UR entry points, a UR adapter will manage
297+ memory migration of native memory objects across all devices in a context, if
298+ memory migration is indeed necessary in the backend API.
299+
300+ .. parsed-literal ::
301+
302+ // Q1 and Q2 are both in hContext
303+ ${x}_mem_handle_t hBuffer;
304+ ${x}MemBufferCreate(hContext,,,,&hBuffer);
305+ ${x}EnqueueMemBufferWrite(Q1, hBuffer,,,,,,, &outEv);
306+ ${x}EnqueueMemBufferRead(Q2, hBuffer,,,,, 1, &outEv /*phEventWaitList */, );
307+
308+ As such, the buffer written to in ${x}EnqueueMemBufferWrite can be
309+ successfully read using ${x}EnqueueMemBufferRead from another queue in the same
310+ context, since the event associated with the write operation has been passed as
311+ a dependency to the read operation.
312+
280313Memory Pooling
281314----------------------------------
282315
0 commit comments