Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify implementation deferal of clUpdateMutableCommandsKHR #1315

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

EwanC
Copy link
Contributor

@EwanC EwanC commented Feb 13, 2025

Address point 1) of #1309 by clarifying when an implementation may defer propogating the changes from clUpdateMutableCommandsKHR.

I belive the only semantic implication of this is the removing the restriction

This is only possible with a command-buffer created with the CL_COMMAND_BUFFER_SIMULTANEOUS_USE_KHR flag, as without this the enqueued command-buffer must complete before any modification occurs.

So that implementations without simultaneous use support can still defer.

@EwanC EwanC requested a review from joshqti February 13, 2025 09:36
Address point 1) of KhronosGroup#1309
by clarifying when an implementation may defer propogating
the changes from `clUpdateMutableCommandsKHR`.

I belive the only semantic implication of this is the removing the
restriction
> This is only possible with a command-buffer created with the CL_COMMAND_BUFFER_SIMULTANEOUS_USE_KHR flag, as without this the enqueued command-buffer must complete before any modification occurs.

So that implementations without simultaneous use support can still
defer.
@EwanC EwanC force-pushed the cmd-buf_update_deffer branch from be696dc to 8396018 Compare February 13, 2025 09:39
Comment on lines +16202 to +16205
Implementations may defer some of the work to allow {clUpdateMutableCommandsKHR}
to return immediately, provided the user observable behavior in subsequent
command-buffer usage is specification conformant. Deferring work helps keep
device occupancy high by avoiding blocking in host code.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depending on folks preferences for verbosity this could be shortened further by omitting the following parts

  1. ", provided the user observable behavior in subsequent command-buffer usage is specification conformant" - This is implicit.
  2. "Deferring work helps keep device occupancy high by avoiding blocking in host code." - This is the motivation behind the semantic, but not the semantic itself, so removing it wouldn't affect specified behavior.

@EwanC EwanC added the cl_khr_command_buffer Relating to the command-buffer family of extension label Feb 13, 2025
@joshqti
Copy link
Contributor

joshqti commented Feb 25, 2025

This looks good to us

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cl_khr_command_buffer Relating to the command-buffer family of extension
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants