Fixup command-buffer enqueue error after PR-1382#1471
Merged
bashbaug merged 1 commit intoKhronosGroup:mainfrom Oct 14, 2025
Merged
Fixup command-buffer enqueue error after PR-1382#1471bashbaug merged 1 commit intoKhronosGroup:mainfrom
bashbaug merged 1 commit intoKhronosGroup:mainfrom
Conversation
KhronosGroup#1382 added support for deferring setting arguments on a kernel command which is updatable. To achieve this we added an extra command-buffer state, "finalized" which is entered when a command-buffer has been finalized but doesn't yet have all it's arguments set. However, if a user tries to enqueue a command-buffer in this state it shouldn't be valid. Therefore update our current wording about when an command-buffer can be enqueued to say the specifically the executable state, when all arguments are available. Rather than defined as after the finalization operation, which could result in the command-buffer being in either the finalization or executable state. We already have a NOTE above to this effect, which I've removed as it felt like it didn't add any extra value above the error definition, but can added back if folks think it's worthwhile.
EwanC
added
the
cl_khr_command_buffer
EwanC
added a commit
to EwanC/OpenCL-CTS
that referenced
this pull request
Oct 7, 2025
Tests the scenario outlined in KhronosGroup#2520 (comment) to verify the functionality added in OpenCL-Docs PR KhronosGroup/OpenCL-Docs#1382. Note that this bumps the required cl_khr_command_buffer_mutable_dispatch minor version by 2 because KhronosGroup#2477 is not yet merged which test the intermediate version. This also assumes the proposed OpenCL-Docs change in KhronosGroup/OpenCL-Docs#1471 is merged, as the PR does a negative test for command-buffer enqueue while the command-buffer is in the finalized state. Closes KhronosGroup#2520
Contributor
|
Merging as discussed in the October 14th teleconference. |
github-project-automation
bot
moved this to Done
in OpenCL command-buffer extensions roadmap
EwanC
added a commit
to EwanC/OpenCL-CTS
that referenced
this pull request
Oct 17, 2025
Tests the scenario outlined in KhronosGroup#2520 (comment) to verify the functionality added in OpenCL-Docs PR KhronosGroup/OpenCL-Docs#1382. Note that this bumps the required cl_khr_command_buffer_mutable_dispatch minor version by 2 because KhronosGroup#2477 is not yet merged which test the intermediate version. This also assumes the proposed OpenCL-Docs change in KhronosGroup/OpenCL-Docs#1471 is merged, as the PR does a negative test for command-buffer enqueue while the command-buffer is in the finalized state. Closes KhronosGroup#2520
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#1382 added support for deferring setting arguments on a kernel command which is updatable. To achieve this we added an extra command-buffer state, "finalized" which is entered when a command-buffer has been finalized but doesn't yet have all it's arguments set.
However, if a user tries to enqueue a command-buffer in this state it shouldn't be valid. Therefore update our current wording about when an command-buffer can be enqueued to say the specifically the executable state, when all the arguments are set. Rather than defined as only after the finalization operation, which could result in the command-buffer being in either the finalization or executable state.
We have a NOTE a few lines above to this effect already, which I'm not really sure