command_buffer: Add clCommandSVMMemcpy and clCommandSVMMemFill #915
Conversation
EwanC
added
the
cl_khr_command_buffer
I also thought about USM support when I saw this PR, I think support could be useful in the context of SYCL-Graphs where you can capture SYCL USM memcpy/memfill nodes, and want to propagate that down to commands in the underlying command-buffer representation. A layered vendor extension for this makes sense to me if there are dependencies on both a vendor & KHR extension. We also have an existing ticket for the interaction of USM with |
Also updated the date of the revision.
|
Thanks! I added the mention of System SVM as suggested by Ben. |
|
related OpenCL-CTS tests are here |
ext/cl_khr_command_buffer.asciidoc
Outdated
| include::{generated}/api/protos/clCommandSVMMemcpyKHR.txt[] | ||
| include::{generated}/api/protos/clCommandSVMMemFillKHR.txt[] |
There was a problem hiding this comment.
I'm getting an asciidoctor warning building the specs that I think is caused by these two lines:
asciidoctor: WARNING: generated/api/protos/clCommandSVMMemcpyKHR.txt: line 4: id assigned to block already in use: clCommandSVMMemcpyKHR
asciidoctor: WARNING: generated/api/protos/clCommandSVMMemFillKHR.txt: line 4: id assigned to block already in use: clCommandSVMMemFillKHR
Basically, these generated snippets include a "label" for the API entry points to this means that they can only be included once. If we want to support including them multiple times - here, for example, and in the description of each API - then we'll need to do something to the spec tooling to allow this.
For now I would recommend just describing each API "manually", as is done above.
ext/cl_khr_command_buffer.asciidoc
Outdated
| @@ -378,6 +380,11 @@ cl_int clGetCommandBufferInfoKHR( | |||
| size_t* param_value_size_ret); | |||
| ---- | |||
|
|
|||
| The following SVM entry points are included only from version 2.0, adding selected commands | |||
There was a problem hiding this comment.
Is "from version 2.0" the right description? Or, should this be "from version 0.9.4"?
There was a problem hiding this comment.
Clarified. It now mentions both the min OpenCL version as well as the minimum ext version.
| successfully. Otherwise, it returns the errors defined by | ||
| {clEnqueueSVMMemcpy} except: |
There was a problem hiding this comment.
Do we need to say anything about an OpenCL 3.0 device that does not support SVM here, or is this one of the errors that was inherited by clEnqueueSVMMemcpy?
For reference, I believe the relevant error is:
CL_INVALID_OPERATION if the device associated with command queue does not support SVM.
Same comment also applies to the new SVM fill API.
There was a problem hiding this comment.
I believe we don't need to explicitly state it, but it should be inherited from the 3.0 spec error description.
Copy-pasted the function fingerprints instead of including the generated finger print twice to avoid an asciidoctor warning produced due to the duplicated label. Clarified that the SVM entry points are supported only starting OpenCL 2.0 and the ext 0.9.4 onwards.
|
Merging as discussed in the October 3rd teleconference. |
This extends the command buffer extension with two SVM commands.