Skip to content

Commit 97a43e1

Browse files
committed
cleanup to reflect issues that are now resolved.
In particular, this commit documents changes to the core SVM APIs as a result of this extension, especially those involving NULL pointers.
1 parent b467ad9 commit 97a43e1

1 file changed

Lines changed: 130 additions & 4 deletions

File tree

extensions/cl_khr_unified_svm.asciidoc

Lines changed: 130 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -48,6 +48,7 @@ Ben Ashbaugh, Intel (ben 'dot' ashbaugh 'at' intel 'dot' com)
4848
* Pekka Jääskeläinen, Intel
4949
* Nikhil Joshi, NVIDIA
5050
* Balaji Calidas, Qualcomm Technologies Inc.
51+
* Jose Lopez, Qualcomm Technologies Inc.
5152
* TODO
5253
// spell-checker: enable
5354

@@ -437,6 +438,90 @@ In this table:
437438

438439
TODO: Probably ought to substantially rewrite portions of Section 5.6.1 and perhaps 5.6.2.
439440

441+
==== Section 5.6.1 - SVM Sharing Granularity: Coarse- and Fine- Grained Sharing
442+
443+
Change the {clSVMAlloc} error condition from:
444+
445+
* _size_ is 0 or > {CL_DEVICE_MAX_MEM_ALLOC_SIZE} value for any device in _context_.
446+
447+
to:
448+
449+
* _size_ is 0 or > {CL_DEVICE_MAX_MEM_ALLOC_SIZE} value for any device in _context_, unless the device supports {cl_khr_unified_svm_EXT}.
450+
When a device supports {cl_khr_unified_svm_EXT}, there is no defined upper limit on the size of an SVM allocation.
451+
452+
453+
Modify the description of {clSVMFree} to refer both to allocations made by {clSVMAlloc} and {clSVMAllocWithPropertiesKHR}.
454+
455+
456+
Modify the description of {clEnqueueSVMFree} to refer both to allocations made by {clSVMAlloc} and {clSVMAllocWithPropertiesKHR}.
457+
Additionally, modify the description of _svm_pointers_ from:
458+
459+
* _svm_pointers_ and _num_svm_pointers_ specify shared virtual memory pointers
460+
to be freed. ...
461+
462+
to:
463+
464+
* _svm_pointers_ and _num_svm_pointers_ specify shared virtual memory pointers
465+
to be freed. ... +
466+
If a pointer in _svm_pointers_ is a `NULL` pointer, then no action occurs for that pointer.
467+
468+
469+
Modify the description of {clEnqueueSVMMemcpy} to refer both to allocations made by {clSVMAlloc} and {clSVMAllocWithPropertiesKHR}.
470+
Additionally, change the {clEnqueueSVMMemcpy} error conditions from:
471+
472+
* {CL_INVALID_VALUE}
473+
** if _dst_ptr_ is `NULL`
474+
** if _src_ptr_ is `NULL`
475+
476+
to:
477+
478+
* {CL_INVALID_VALUE}
479+
** if _dst_ptr_ is `NULL` and either _size_ is non-zero or the device associated with _command_queue_ does not support {cl_khr_unified_svm_EXT}
480+
** if _src_ptr_ is `NULL` and either _size_ is non-zero or the device associated with _command_queue_ does not support {cl_khr_unified_svm_EXT}
481+
482+
483+
Modify the description of {clEnqueueSVMMemFill} to refer both to allocations made by {clSVMAlloc} and {clSVMAllocWithPropertiesKHR}.
484+
Change the {clEnqueueSVMMemFill} error condition from:
485+
486+
* {CL_INVALID_VALUE}
487+
** if _svm_ptr_ is `NULL`
488+
489+
to:
490+
491+
* {CL_INVALID_VALUE}
492+
** if _svm_ptr_ is `NULL` and either _size_ is non-zero or the device associated with _command_queue_ does not support {cl_khr_unified_svm_EXT}
493+
494+
495+
Modify the description of {clEnqueueSVMMemFill} to refer both to allocations made by {clSVMAlloc} and {clSVMAllocWithPropertiesKHR}.
496+
Change the {clEnqueueSVMMemFill} error condition from:
497+
498+
* {CL_INVALID_VALUE}
499+
** if _svm_ptr_ is `NULL`
500+
501+
to:
502+
503+
* {CL_INVALID_VALUE}
504+
** if _svm_ptr_ is `NULL` and either _size_ is non-zero or the device associated with _command_queue_ does not support {cl_khr_unified_svm_EXT}
505+
506+
507+
Modify the descriptions of {clEnqueueSVMMap} and {clEnqueueSVMUnmap} to refer both to allocations made by {clSVMAlloc} and {clSVMAllocWithPropertiesKHR}.
508+
Additionally, add a new error condition:
509+
510+
* {CL_INVALID_VALUE}
511+
** if _svm_ptr_ does not support mapping and unmapping for access on the host
512+
513+
514+
Modify the description of {clEnqueueSVMMigrateMem} to refer both to allocations made by {clSVMAlloc} and {clSVMAllocWithPropertiesKHR}.
515+
Additionally, modify the description of _svm_pointers_ from:
516+
517+
* _svm_pointers_ is a pointer to an array of pointers. ...
518+
519+
to:
520+
521+
* _svm_pointers_ is a pointer to an array of pointers to migrate. ... +
522+
If a pointer in _svm_pointers_ is a `NULL` pointer and either _sizes_ is `NULL` or the size in _sizes_ is zero, then it is ignored.
523+
524+
440525
==== Allocating SVM With Properties:
441526

442527
The function
@@ -727,10 +812,6 @@ The suggested SVM type may be {CL_UINT_MAX}, indicating that there is no SVM all
727812
** if _required_capabilities_ contains an invalid SVM capability
728813
** if _desired_capabilities_ contains an invalid SVM capability
729814
** if _suggested_svm_type_index_ is `NULL`
730-
* {CL_INVALID_BUFFER_SIZE}
731-
// TODO: update depending on the updated queries for available SVM sizes:
732-
** if _size_ is greater than {CL_DEVICE_MAX_MEM_ALLOC_SIZE} for any OpenCL device in _context_ that supports the specified SVM type
733-
** if _size_ is greater than {CL_DEVICE_MAX_MEM_ALLOC_SIZE} for a device associated with the SVM allocation
734815
* {CL_OUT_OF_RESOURCES}
735816
** if there is a failure to allocate resources required by the OpenCL
736817
implementation on the device
@@ -763,6 +844,51 @@ The following errors may be returned by {clSetKernelExecInfo} for these new _par
763844

764845
* {CL_INVALID_OPERATION} if _param_name_ is {CL_KERNEL_EXEC_INFO_SVM_INDIRECT_ACCESS_KHR} and no devices in the context associated with _kernel_ support SVM.
765846

847+
=== Section 5.9 - Kernel Objects
848+
849+
==== Section 5.9.2 - Setting Kernel Arguments
850+
851+
Change the {clSetKernelArgSVMPointer} error condition from:
852+
853+
* {CL_INVALID_ARG_VALUE}
854+
** if _arg_value_ specified is not a valid value
855+
856+
to:
857+
858+
* {CL_INVALID_ARG_VALUE}
859+
** if _arg_value_ specified is not a valid value and no devices in the context associated with _kernel_ support {cl_khr_unified_svm_EXT}
860+
861+
862+
Update the first paragraph of description of {CL_KERNEL_EXEC_INFO_SVM_PTRS} from:
863+
864+
Specifies a set of pointers to SVM allocations that may be accessed
865+
by the kernel in addition to those set directly as kernel arguments.
866+
Each of the pointers can be the pointer returned by {clSVMAlloc} or can
867+
be a pointer to the middle of an SVM allocation.
868+
It is sufficient to specify one pointer for each SVM allocation.
869+
870+
to:
871+
872+
Specifies a set of pointers to SVM allocations that may be accessed
873+
by the kernel in addition to those set directly as kernel arguments.
874+
Each of the pointers can be the pointer returned by {clSVMAlloc} or {clSVMAllocWithPropertiesKHR} or can
875+
be a pointer to the middle of a SVM allocation.
876+
If a pointer is `NULL` or does not point into a SVM allocation returned by
877+
{clSVMAlloc} or {clSVMAllocWithPropertiesKHR} then it is ignored.
878+
It is sufficient to specify one pointer for each SVM allocation.
879+
880+
881+
Add an informative note after to the description of {clSetKernelExecInfo}:
882+
883+
[NOTE]
884+
====
885+
When the context associated with _kernel_ includes a device that supports {cl_khr_unified_svm_EXT}, any pointer value is considered valid and may be passed directly to a kernel by calling {clSetKernelArgSVMPointer} or indirectly by calling {clSetKernelExecInfo} with {CL_KERNEL_EXEC_INFO_SVM_PTRS}.
886+
887+
In this definition, a valid pointer value means that the function will not return an error.
888+
It still may not be valid to dereference the pointer inside of a kernel if the memory that the pointer points to is not accessible on the device.
889+
====
890+
891+
766892
== Interactions with Other Extensions
767893

768894
TODO

0 commit comments

Comments
 (0)