Use array for clUpdateMutableCommandsKHR#245
Conversation
Implementation change to prototype specification changes proposed in KhronosGroup/OpenCL-Docs#1041 Uses OpenCL-Docs and OpenCL-Header changes from * KhronosGroup/OpenCL-Docs#1045 * KhronosGroup/OpenCL-Headers#245
CTS change to reflect proposed change from KhronosGroup/OpenCL-Docs#1041 Taking advantage of the extension version macros to avoid breaking existing implementations immediately. This reflects PRs: * KhronosGroup/OpenCL-Docs#1045 * KhronosGroup/OpenCL-Headers#245
CTS change to reflect proposed change from KhronosGroup/OpenCL-Docs#1041 Taking advantage of the extension version macros to avoid breaking existing implementations immediately. This reflects PRs: * KhronosGroup/OpenCL-Docs#1045 * KhronosGroup/OpenCL-Headers#245
Implementation change to prototype specification changes proposed in KhronosGroup/OpenCL-Docs#1041 Uses OpenCL changes from * KhronosGroup/OpenCL-Docs#1045 * KhronosGroup/OpenCL-Headers#245 * KhronosGroup/OpenCL-CTS#1984
Proposal to pass the update configs to `clUpdateMutableCommandsKHR` as an array, rather than pointer changed linked list. See KhronosGroup/OpenCL-Docs#1041 for motivation and KhronosGroup/OpenCL-Docs#1045 for OpenCL-Docs PR.
Implementation change to prototype specification changes proposed in KhronosGroup/OpenCL-Docs#1041 Uses OpenCL changes from * KhronosGroup/OpenCL-Docs#1045 * KhronosGroup/OpenCL-Headers#245 * KhronosGroup/OpenCL-CTS#1984
Implementation change to prototype specification changes proposed in KhronosGroup/OpenCL-Docs#1041 Uses OpenCL changes from * KhronosGroup/OpenCL-Docs#1045 * KhronosGroup/OpenCL-Headers#245 * KhronosGroup/OpenCL-CTS#1984
Implementation change to prototype specification changes proposed in KhronosGroup/OpenCL-Docs#1041 Uses OpenCL changes from * KhronosGroup/OpenCL-Docs#1045 * KhronosGroup/OpenCL-Headers#245 * KhronosGroup/OpenCL-CTS#1984
bashbaug
left a comment
There was a problem hiding this comment.
LGTM
Do we need to stage these changes with changes in any other repos, such as the C++ bindings (OpenCL-CLHPP) or the CTS tests?
I'll take care of updating the command buffer emulation layer.
Should probably be staged with CTS PR KhronosGroup/OpenCL-CTS#1984, I don't have a OpenCL-CLHPP PR but will look into making one there. I'm not that familiar with the C++ bindings, but I'd expect that would break without an update. Edit: created a OpenCL-CLHPP PR here will update KhronosGroup/OpenCL-CLHPP#298 |
In OpenCL-Docs PR KhronosGroup/OpenCL-Docs#1045 the API for `cl_khr_command_buffer_mutable_dispatch` API `clUpdateMutableCommandsKHR` changed in a breaking way. When the headers update OpenCL-Headers PR KhronosGroup/OpenCL-Headers#245 the bindings will break if they are not updated to reflect this change. Bindings updated in this PR to pass to arrays of templated length to the C++ method. The underlying `.data()` pointers of these parameters can be passed through to the OpenCL API.
In OpenCL-Docs PR KhronosGroup/OpenCL-Docs#1045 the API for `cl_khr_command_buffer_mutable_dispatch` API `clUpdateMutableCommandsKHR` changed in a breaking way. When the headers update OpenCL-Headers PR KhronosGroup/OpenCL-Headers#245 the bindings will break if they are not updated to reflect this change. Bindings updated in this PR to pass to arrays of templated length to the C++ method. The underlying `.data()` pointers of these parameters can be passed through to the OpenCL API.
CTS change to reflect proposed change from KhronosGroup/OpenCL-Docs#1041 Taking advantage of the extension version macros to avoid breaking existing implementations immediately. This reflects PRs: * KhronosGroup/OpenCL-Docs#1045 * KhronosGroup/OpenCL-Headers#245
bashbaug
left a comment
There was a problem hiding this comment.
Merging as discussed in the September 3rd teleconference + email.
In OpenCL-Docs PR KhronosGroup/OpenCL-Docs#1045 the API for `cl_khr_command_buffer_mutable_dispatch` API `clUpdateMutableCommandsKHR` changed in a breaking way. When the headers update OpenCL-Headers PR KhronosGroup/OpenCL-Headers#245 the bindings will break if they are not updated to reflect this change. Bindings updated in this PR to pass to arrays of templated length to the C++ method. The underlying `.data()` pointers of these parameters can be passed through to the OpenCL API.
CTS changes to reflect the spec changes merged in KhronosGroup/OpenCL-Docs#1045 and requires header updates from KhronosGroup/OpenCL-Headers#245 Tested using OCK implementation from uxlfoundation/oneapi-construction-kit#501
Update OpenCL adapter code to reflect the 2 API breaking changes to the command-buffer family of extensions that have been made upstream: * [Add properties parameter to all command-buffer commands](KhronosGroup/OpenCL-Headers#260) * [Use array for clUpdateMutableCommandsKHR](KhronosGroup/OpenCL-Headers#245)
Update OpenCL adapter code to reflect the 2 API breaking changes to the command-buffer family of extensions that have been made upstream: * [Add properties parameter to all command-buffer commands](KhronosGroup/OpenCL-Headers#260) * [Use array for clUpdateMutableCommandsKHR](KhronosGroup/OpenCL-Headers#245)
Proposal to pass the update configs to
clUpdateMutableCommandsKHRas an array, rather than pointer changed linked list.Generated from XML changes in KhronosGroup/OpenCL-Docs#1045
See KhronosGroup/OpenCL-Docs#1041 for motivation.
Related PRs: