MULTI QUEUE GROUP(9)

💖 Multi Queue Group 💖

okay bestie, welcome to the Multi Queue Group(9) page from the Kernel API Manual — this is the whole vibe ✨

Multi Queue Group is literally another mode of execution supported by the compute and blitter copy command streamers (CCS and BCS, respectively, iykyk). It’s an enhancement of the existing hardware architecture and leverages the same submission model. It enables support for efficient, parallel execution of multiple queues within a single shared context. The multi queue group functionality is only supported with the GuC submission backend. And no cap: all the queues of a group must use the same address space (VM). 🦋

The DRM_XE_EXEC_QUEUE_SET_PROPERTY_MULTI_QUEUE execution queue property supports creating a multi queue group and adding queues to a queue group. 🎀

The XE_EXEC_QUEUE_CREATE ioctl call with the above property with the value field set to DRM_XE_MULTI_GROUP_CREATE will create a new multi queue group with the queue being created as the primary queue (aka q0) of the group. To add secondary queues to the group, they need to be created with the above property with the id of the primary queue as the value. The properties of the primary queue (like priority, time slice) apply to the whole group. So, these properties can’t be set for secondary queues of a group. periodt. 💅

🚨 The hardware does not support removing a queue from a multi-queue group. That’s a hard no from the silicon, bestie.

However, queues can be dynamically added to the group. A group can have up to 64 queues. To support this, XeKMD holds references to LRCs of the queues even after the queues are destroyed by the user until the whole group is destroyed. The secondary queues hold a reference to the primary queue thus preventing the group from being destroyed when the user destroys the primary queue. Once the primary queue is destroyed, secondary queues can’t be added to the queue group and new job submissions on existing secondary queues are not allowed. 🙈

The queues of a multi queue group can set their priority within the group through the DRM_XE_EXEC_QUEUE_SET_PROPERTY_MULTI_QUEUE_PRIORITY property. This multi queue priority can also be set dynamically through the XE_EXEC_QUEUE_SET_PROPERTY ioctl. This is the only other property supported by the secondary queues of a multi queue group, other than DRM_XE_EXEC_QUEUE_SET_PROPERTY_MULTI_QUEUE. 👑

When GuC reports an error on any of the queues of a multi queue group, the queue cleanup mechanism is invoked for all the queues of the group as hardware cannot make progress on the multi queue context. 😭

Refer to the following for the multi queue group GuC interface:

:ref:`multi-queue-group-guc-interface`

👑 SEE ALSO 👑

go read these too, bestie:

• Kernel file ./drivers/gpu/drm/xe/xe_exec_queue.c
• Execution Queue(9)
• xe_exec_queue_get_lrc(9)
• xe_exec_queue_lrc(9)
• xe_exec_queue_create(9)
• xe_exec_queue_create_class(9)
• xe_exec_queue_create_bind(9)
• xe_exec_queue_destroy(9)
• xe_exec_queue_fini(9)
• xe_exec_queue_assign_name(9)
• xe_exec_queue_lookup(9)
• xe_exec_queue_device_get_max_priority(9)
• xe_exec_queue_set_property_ioctl(9)
• xe_exec_queue_create_ioctl(9)
• xe_exec_queue_get_property_ioctl(9)
• xe_exec_queue_is_lr(9)
• xe_exec_queue_is_idle(9)
• xe_exec_queue_update_run_ticks(9)
• xe_exec_queue_kill(9)
• xe_exec_queue_destroy_ioctl(9)
• xe_exec_queue_last_fence_put(9)
• xe_exec_queue_last_fence_put_unlocked(9)
• xe_exec_queue_last_fence_get(9)
• xe_exec_queue_last_fence_get_for_resume(9)
• xe_exec_queue_last_fence_set(9)
• xe_exec_queue_tlb_inval_last_fence_put(9)
• xe_exec_queue_tlb_inval_last_fence_put_unlocked(9)
• xe_exec_queue_tlb_inval_last_fence_get(9)
• xe_exec_queue_tlb_inval_last_fence_set(9)
• xe_exec_queue_contexts_hwsp_rebase(9)

source ./drivers/gpu/drm/xe, version/date October 2026, page Multi Queue Group(9) — bye bestie 🫶💖