Refactor command-buffer queue compatability #1292
Conversation
api/opencl_runtime_layer.asciidoc
Outdated
| creation, with the exception of any vendor extension defined queue properties | ||
| that explcitly define semantics for this purpose. | ||
|
|
||
| The command-queues used on command-buffer creation must be replaced on |
There was a problem hiding this comment.
Why say "must be replaced"? Can't the user use the same queue objects for creation and execution?
There was a problem hiding this comment.
I'll try reword this. I was trying to communicate that since the queues used on command-buffer creation are really placeholders used to inform the device and dependencies of commands, those placeholders must be replaced with queues which will actually submit work to the device.
There was a problem hiding this comment.
But must these queues be placeholders? Can't they be real queues to be used later for enqueuing the command buffer?
There was a problem hiding this comment.
The queue objects throughout the API must be valid cl_command_queue objects, so everything is a real queue, but their role in command creation API is placeholder in the sense that the purpose of using the queue object in the API is not for submitting work to the device but representing the devices and dependencies of commands.
There was a problem hiding this comment.
I understand, but the question is: must the queues used for recording and replaying be different? If yes, then your wording is OK; if not, you should replace "must be replaced" with "may be replaced".
There was a problem hiding this comment.
I think besides "must" and "may", there can also be "recommended". As in, it is, for some reason, worse if the queue is reused.
There was a problem hiding this comment.
There is no requirement that the queues must be different, they only may be different as I say in the next sentence, so I'll reword this sentence.
There was a problem hiding this comment.
Changed this line to say "When enqueuing a command-buffer, a list of command-queues to execute the command-buffer on can be passed by the user, otherwise the command-queues set on command-buffer creation are used by default for execution. A user passed list may contain different command-queues, ..."
As proposed in KhronosGroup#1142 the PR changes the semantics of the command-queues parameters used for command-buffer creation and enqueue. The queues used on command-buffer creation now only inform the device and dependencies of commands, rather than restricting the properties set on the queues used for command-buffer enqueue. This is based ontop on the change in KhronosGroup#850 to add supported queue property semantics.
Clarify wording around default list of command-queues used for command-buffer enqueue.
EwanC
force-pushed
the
refactor_queue_compatability
branch
from
aad1eef to
ffd3647
Compare
EwanC
changed the base branch from
EwanC/tmp/command-buffer_supported_queue_props
to
main
Generated changes from XML update in matching PR KhronosGroup/OpenCL-Docs#1292
Update cl_khr_command_buffer tests to reflect changes from KhronosGroup/OpenCL-Docs#1292 Required headers change KhronosGroup/OpenCL-Headers#271 to enable tests with version 0.9.7
As proposed in #1142 the PR changes the semantics of the command-queues parameters used for command-buffer creation and enqueue.
The queues used on command-buffer creation now only inform the device and dependencies of commands, rather than restricting the properties set on the queues used for command-buffer enqueue.
Related PRs: