New Command-buffer query for supported queue properties

[EwanC]

This change introduces a new device query related to the command-buffer extension - CL_DEVICE_COMMAND_BUFFER_SUPPORTED_QUEUE_PROPERTIES_KHR. This is different from CL_DEVICE_COMMAND_BUFFER_REQUIRED_QUEUE_PROPERTIES_KHR, as we want to convey to the user that an implementation allows using a queue property with a command-buffer, but it is not mandatory to use the property with a command-buffer.

This mechanism supersedes reporting queue related values from the CL_DEVICE_COMMAND_BUFFER_CAPABILITIES_KHR query. The flaw with CL_DEVICE_COMMAND_BUFFER_CAPABILITIES_KHR is that it contains bits explicitly added by the command-buffer extension for reporting support for queue properties. This is a brittle design, as any new queue property added in future would need to have a new bit added here in the command-buffer extension to report support when used with command-buffers.

Instead, a better design is to have a new query reporting queue properties supported, CL_DEVICE_COMMAND_BUFFER_SUPPORTED_QUEUE_PROPERTIES_KHR, and keeping CL_DEVICE_COMMAND_BUFFER_CAPABILITIES_KHR for capabilities unrelated to the command-queue properties.

The CL_COMMAND_BUFFER_CAPABILITY_OUT_OF_ORDER_KHR use-case can now be covered by returning CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE from CL_DEVICE_COMMAND_BUFFER_SUPPORTED_QUEUE_PROPERTIES_KHR, so it is removed.

Make CL_QUEUE_PROFILING_ENABLE the mandated minimum capability reported from CL_DEVICE_COMMAND_BUFFER_SUPPORTED_QUEUE_PROPERTIES_KHR, to keep existing command-buffer extension requirement to implement profiling, which is inline with minimum requirements for host queues.

Related OpenCL repo PRs:

• Command-buffer supported queue properties OpenCL-Headers#265
• Command-buffer supported queue properties query OpenCL-CLHPP#307
• Command-buffer query for supported queue properties OpenCL-CTS#2101

[bashbaug]

I lost track of this one, my apologies. Is it ready to go?

[EwanC]

I lost track of this one, my apologies. Is it ready to go?

No worries, I've deliberately been holding back from adding it to the WG agenda because of the Mobica CTS project adding command-buffer tests. I think doing an API change in the middle of that work is a complication we should avoid. So once that's done, I think we could make this API change and I can make the according CTS update myself to reflect it.

[bcalidas]

Are the queue properties for executing a command buffer mandated to be the same as the queue properties while recording the command buffer.

[EwanC]

Yes we currently have this wording in the spec about being compatible

Command-buffers are created using an ordered list of command-queues that commands are recorded to and execute on by default. These command-queues can be replaced on command-buffer enqueue with different command-queues, provided for each element in the replacement list the substitute command-queue is compatible with the command-queue used on command-buffer creation. Where a compatible command-queue is defined as a command-queue with identical properties targeting the same device and in the same OpenCL context.

And then the actual error condition to clEnqueueCommandBufferKHR is

CL_INCOMPATIBLE_COMMAND_QUEUE_KHR if any element of queues is not compatible with the command-queue set on command_buffer creation at the same list index.

I've ignored that clSetCommandQueueProperty exists because its been depreciated since OpenCL 1.1, as that could change a command-queue's properties after creation. Maybe I should put a note about not using that.