From 24792fb2c981a7cfd7947cc1552c7235a20ca0c3 Mon Sep 17 00:00:00 2001 From: Ben Ashbaugh Date: Mon, 18 Nov 2024 17:44:18 -0800 Subject: [PATCH] editorial updates --- extensions/cl_khr_unified_svm.asciidoc | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/extensions/cl_khr_unified_svm.asciidoc b/extensions/cl_khr_unified_svm.asciidoc index e47323e3..88ac3c24 100644 --- a/extensions/cl_khr_unified_svm.asciidoc +++ b/extensions/cl_khr_unified_svm.asciidoc @@ -311,7 +311,7 @@ Add to Table 5 - List of supported param_names by *clGetDeviceInfo*: | `CL_SVM_CAPABILITY_DEVICE_READ_KHR` | This type of SVM is accessible on the device for reading. | `CL_SVM_CAPABILITY_DEVICE_WRITE_KHR` - | This type of SVM is writeable on the device for writing. + | This type of SVM is accessible on the device for writing. | `CL_SVM_CAPABILITY_DEVICE_ATOMIC_ACCESS_KHR` | This type of SVM is accessible on the device using atomic built-in functions. | `CL_SVM_CAPABILITY_CONCURRENT_ACCESS_KHR` @@ -922,7 +922,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 as the `pattern` argument to API functions to fill a `cl_mem`, SVM allocation, or USM allocation, such as *clEnqueueFillBuffer*? + -- *UNRESOLVED*: @@ -936,8 +936,7 @@ Trending "yes" for host USM allocations, both when the host USM allocation is fr . Should we support passing traditional `cl_mem_flags` via the USM allocation properties? + -- -*UNRESOLVED*: -Trending "no", this functionality is better expressed by optional access properties. +`RESOLVED`: We decided not to accept any `cl_mem_flags` or `cl_svm_mem_flags`, and added access properties instead. -- . Exactly how do the additional SVM types affect the memory model? @@ -1011,7 +1010,7 @@ Note: The following issues were added to the KHR USM extension: . Should we add a synchronous memadvise function? Do we need to support memadvise at all? + -- -*RESOLVED*: +`RESOLVED`: We decided not to support a memadvise function in the initial version of this specification. For reference, for other APIs: @@ -1029,7 +1028,7 @@ For reference, for other APIs: . Should we move more of the *clSVMAllocWithProperties* arguments to properties? + -- -*RESOLVED*: +`RESOLVED`: We moved the access flags and alignment to properties, so the only required arguments are now the properties, the SVM type index, and the SVM allocation size. -- @@ -1044,7 +1043,7 @@ This is especially important if the required SVM capabilities contains e.g. "dev . Should we support a mechanism to enable indirect access for all SVM allocation types with a single call? + -- -*RESOLVED*: Yes, we should. We now have: +`RESOLVED`: Yes, we should. We now have: * `CL_KERNEL_EXEC_INFO_SVM_INDIRECT_ACCESS_KHR`, added by this extension, which enables indirect access for all SVM allocations made through the driver (by calling *clSVMAlloc* or *clSVMAllocWithPropertiesKHR*). Indirect access for these types of allocations is **disabled** by default. @@ -1055,7 +1054,7 @@ Indirect access for these types of allocations is **enabled** by default, though . How should an SVM allocation with the access flag *NOWRITE* be initialized? + -- -*RESOLVED*: For this extension, if an allocation is created with the *HOST_NOWRITE* flag, then it can only be initialized on the device. +`RESOLVED`: For this extension, if an allocation is created with the *HOST_NOWRITE* flag, then it can only be initialized on the device. If an allocation is created with the *DEVICE_NOWRITE* flag, then it can only be initialized on the host. This extension does not support initialize an allocation with both the *HOST_NOWRITE* and *DEVICE_NOWRITE* flags.