add new issues regarding error checking for USM pointer kernel args and rect memcpys (#857)

* add an issue regarding error checking for USM pointer kernel args

* add an issue regarding a rect memcpy

Author: bashbaug

extensions/cl_intel_unified_shared_memory.asciidoc

@@ -1062,7 +1062,7 @@ If we did support this then there may be alignment and size granularity requirem
 The _flags_ argument was folded into the _properties_ in revision C.
 --
 
-. What should behavior be for `clGetMemAllocInfoINTEL` if the passed-in _ptr_ is `NULL` or doesn't point into a USM allocation?
+. What should behavior be for *clGetMemAllocInfoINTEL* if the passed-in _ptr_ is `NULL` or doesn't point into a USM allocation?
 +
 --
 `RESOLVED`:
@@ -1156,11 +1156,14 @@ Is `size` equal to zero valid?
 --
 
 . Should we add a device query for a maximum supported USM alignment, or should the maximum supported alignment implicitly be defined by the size of the largest data type supported by the device?
+Should we allow implementation-defined behavior for alignments larger than the size of the largest data type supported by the device?
 +
 --
 *UNRESOLVED*:
 A device query would allow for larger supported alignments, such as page alignment.
 Note that supported alignments should always be a power of two.
+
+Note that there are no maximum supported alignments defined for `posix_memalign` or `_aligned_alloc`, and supported alignments for the standard `aligned_alloc` and `std::aligned_alloc` are implementation-defined.
 --
 
 . Should we add a device query for a maximum supported USM fill pattern size, or should the maximum supported fill pattern size implicitly be defined by the size of the largest data type supported by the device?
@@ -1191,7 +1194,7 @@ If the USM allocation is from a different context then behavior could be undefin
 Trending "yes" for host USM allocations, both when the host USM allocation is from this context and from another context.
 --
 
-. Can a pointer to a device, host, or shared USM allocation be passed to API functions to read from or write to `cl_mem` objects, such as `clEnqueueReadBuffer` or `clEnqueueWriteImage`?
+. Can a pointer to a device, host, or shared USM allocation be passed to API functions to read from or write to `cl_mem` objects, such as *clEnqueueReadBuffer* or *clEnqueueWriteImage*?
 +
 --
 *UNRESOLVED*:
@@ -1204,7 +1207,7 @@ If the shared USM allocation is from the same context this could be an error, su
 If the shared USM allocation is from a different context then behavior could be undefined.
 --
 
-. Can a pointer to a device, host, or shared USM allocation be passed to API functions to fill a `cl_mem`, SVM allocation, or USM allocation, such as `clEnqueueFillBuffer`?
+. Can a pointer to a device, host, or shared USM allocation be passed to API functions to fill a `cl_mem`, SVM allocation, or USM allocation, such as *clEnqueueFillBuffer*?
 +
 --
 *UNRESOLVED*:
@@ -1230,6 +1233,26 @@ Note that some flags will not be valid, such as `CL_MEM_USE_HOST_PTR`.
 *UNRESOLVED*:
 --
 
+. Should it be an error to set an unknown pointer as a kernel argument using *clSetKernelArgMemPointerINTEL* if no devices support shared system allocations?
++
+--
+*UNRESOLVED*:
+Returning an error for an unknown pointer is helpful to identify and diagnose possible programming errors sooner, but passing a pointer to arbitrary memory to a function on the host is not an error until the pointer is dereferenced.
+
+If we relax the error condition for *clSetKernelArgMemPointerINTEL* then we could also consider relaxing the error condition for *clSetKernelExecInfo*(`CL_KERNEL_EXEC_INFO_USM_PTRS_INTEL`) similarly.
+
+Note that if the error condition is removed we can still check for possible programming errors via optional USM checking layers, such as the https://github.com/intel/opencl-intercept-layer/blob/master/docs/controls.md#usmchecking-bool[USMChecking] functionality in the https://github.com/intel/opencl-intercept-layer[OpenCL Intercept Layer].
+--
+
+. Should we support a "rect" memcpy similar to *clEnqueueCopyBufferRect*?
++
+--
+*UNRESOLVED*:
+This would be a fairly straightforward addition if it is useful.
+
+Note that there is no similar SVM "rect" memcpy.
+--
+
 == Revision History
 
 [cols="5,15,15,70"]
@@ -1257,6 +1280,7 @@ Note that some flags will not be valid, such as `CL_MEM_USE_HOST_PTR`.
 |R|2020-08-21|Ben Ashbaugh|Fixed enum name typo in table.
 |S|2020-08-26|Maciej Dziuban|Added initial placement flags for shared allocations.
 |1.0.0|2021-11-07|Ben Ashbaugh|Added version and other minor updates prior to posting on the OpenCL registry.
+|1.0.0|2022-11-08|Ben Ashbaugh|Added new issues regarding error behavior for clSetKernelArgMemPointerINTEL and rect copies.
 |========================================
 
 //************************************************************************