command list are per device not per queue

[airlied]

Why are command lists per device not per queue?

If you have multi-queue hardware with say separate compute and copy queues, you can't record the final command buffer until submit time, this means driver have to keep some sort of meta queue that isn't the real underlying hw queue.

Vulkan puts the command lists per queue for this reason, so that when you record a a compute or transfer (copy) command list it can be baked down to actual hw commands for the queue the command is intended to be executed on.

[airlied]

I do see that there is the flags on the command queues ZE_COMMAND_LIST_FLAG_COPY_ONLY but I don't see why that is better than just tying it to the queue, especially from an extensibility into the future point of view.

[gatorfax]

Yes, you're correct that this area needed more work. We have a specification update coming soon that introduces the concept of “command queue groups”, which is similar to Vulkan’s VkQueueFamilyProperties.

More details will be published in the programming guide, but the summary is the command list creation will be tied to a command queue group. This will allow drivers to fully encode the hardware commands without knowing ahead of time which specific hardware queue the command list will be submitted to.

This model provides the flexibility for libraries to create persistent, re-usable command lists without knowing which physical command queue an application may actually submit it to. We have users that are counting on this capability.

[gatorfax]

Here is the latest documentation:

• Programming Guide: Command Queues
• zeDeviceGetCommandQueueGroupProperties
• ze_command_queue_group_properties_t
• ze_command_queue_desc_t
• ze_command_list_desc_t