KhronosGroup
New Command-buffer query for supported queue properties
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.
Change needs discussion on the working-group teleconference call before proceeding.
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.