Vulkan 中的队列家族实际上是什么？

Question

我目前正在学习 vulkan，现在我只是分解每个命令并检查结构以尝试理解它们的含义。

现在我正在分析 QueueFamilies，我有以下代码：

vector<vk::QueueFamilyProperties> queue_families = device.getQueueFamilyProperties();
for(auto &q_family : queue_families)
{
    cout << "Queue number: "  + to_string(q_family.queueCount) << endl;
    cout << "Queue flags: " + to_string(q_family.queueFlags) << endl;
}

这会产生这个输出：

Queue number: 16
Queue flags: {Graphics | Compute | Transfer | SparseBinding}
Queue number: 1
Queue flags: {Transfer}
Queue number: 8
Queue flags: {Compute}

所以，天真地我是这样理解的：

共有 3 个队列族，一个队列族有 16 个队列，都能够进行图形、计算、传输和稀疏绑定操作（不知道最后 2 个是什么）

另一个有 1 个队列，只能传输（不管是什么）

最后一个有 8 个能够进行计算操作的队列。

每个队列族是什么？我知道这是我们发送执行命令（如绘图和交换缓冲区）的地方，但这是一个有点宽泛的解释，我想要一个更详细的答案。

额外的 2 个标志是什么？转移和稀疏投标？

最后，为什么我们有/需要多个命令队列？

Answer 1

要了解队列族，首先必须了解队列。

队列是您提交命令缓冲区的对象，提交到队列的命令缓冲区按顺序[*1] 相对于彼此执行。提交到不同队列的命令缓冲区相对于彼此是无序的，除非您明确将它们与VkSemaphore 同步。一次只能从一个线程向一个队列提交工作，但不同的线程可以同时向不同的队列提交工作。

每个队列只能执行某些类型的操作。图形队列可以运行由vkCmdDraw* 命令启动的图形管道。计算队列可以运行由vkCmdDispatch* 启动的计算管道。传输队列可以从vkCmdCopy* 执行传输（复制）操作。稀疏绑定队列可以使用vkQueueBindSparse 更改稀疏资源到内存的绑定（注意这是直接提交到队列的操作，而不是命令缓冲区中的命令）。一些队列可以执行多种操作。在规范中，每个可以提交到队列的命令都有一个“命令属性”表，其中列出了哪些队列类型可以执行该命令。

队列族只是描述了一组具有相同属性的队列。所以在你的例子中，设备支持三种队列：

• 一种可以进行图形、计算、传输和稀疏绑定操作，并且您最多可以创建 16 个该类型的队列。

• 另一种只能做传输操作，你只能创建一个这种队列。通常这是为了在离散 GPU 上的主机和设备内存之间异步 DMA 处理数据，因此传输可以与独立的图形/计算操作同时完成。

• 最后，您可以创建最多 8 个只能进行计算操作的队列。

一些队列可能只对应于主机端调度程序中的单独队列，其他队列可能对应于硬件中实际的独立队列。例如，许多 GPU 只有一个硬件图形队列，因此即使您从支持图形的队列系列中创建两个 VkQueue，提交到这些队列的命令缓冲区将独立地通过内核驱动程序的命令缓冲区调度程序进行处理，但会以某些串行方式执行在 GPU 上订购。但是一些 GPU 有多个只计算硬件队列，因此一个只计算队列系列的两个 VkQueue 可能实际上独立并同时通过 GPU 进行。 Vulkan 没有公开这一点。

最重要的是，根据您的并发量来决定您可以使用多少个队列。对于许多应用程序来说，他们只需要一个“通用”队列。更高级的可能有一个图形+计算队列，一个用于异步计算工作的单独的仅计算队列，以及一个用于异步 DMA 的传输队列。然后将您想要的内容映射到可用的内容上；您可能需要自己进行多路复用，例如在没有仅计算队列系列的设备上，您可以创建多个图形+计算队列，或者自己将异步计算作业序列化到单个图形+计算队列中。

[*1] 有点过于简单化了。它们按顺序开始，但之后允许独立进行并无序完成。但是不能保证不同队列的独立进度。这个问题我就不说了。

Answer 2

队列是一个接受包含给定类型（由家族标志给出）操作的命令缓冲区的东西。提交到队列的命令具有提交顺序，因此它们会受到管道障碍、子通道依赖和事件的同步（而必须使用跨队列的信号量或更好）。

有一个技巧：COMPUTE 和GRAPHICS 总是可以隐式接受TRANSFER 工作负载（即使QueueFamilyProperties 没有列出它。请参阅下面的注释Specification of VkQueueFlagBits）。

Transfer 用于 Copy 和 Blit 命令。稀疏类似于分页；它允许将多个内存句柄绑定到单个图像，并且允许稍后重新绑定不同的内存。

在规范中，下面给出的vkCmd* 命令总是说明哪些是“支持的队列类型”。

队列族是一组与自身有特殊关系的队列。有些事情仅限于单个队列族，例如图像（它们必须在队列族之间传输）或命令池（仅创建命令缓冲区以供给定队列族使用，不供其他队列使用）。理论上，在一些奇特的设备上，可能会有更多具有相同标志的队列系列。

这几乎是 Vulkan 规范所保证的一切。在KhronosGroup/Vulkan-Docs#569查看与此相关的问题

---

给出了一些特定于供应商的材料，例如：

• AMD 的Leveraging asynchronous queues for concurrent execution
• NVIDIA 的Moving to Vulkan: Asynchronous compute

GPU 具有异步图形引擎、计算引擎和 Copy\DMA 引擎。图形和计算当然会竞争 GPU 的相同计算单元。

他们通常只有一个图形前端。这是图形操作的瓶颈，因此这意味着使用多个图形队列是没有意义的。

Compute 有两种操作模式：同步计算（公开为GRAPHICS|COMPUTE 系列）和异步计算（公开为COMPUTE-only 系列）。第一个是安全的选择。第二个可以给你大约 10% 的性能，但更棘手，需要更多的努力。 AMD 文章建议始终将第一个作为基线。

理论上可以有与 GPU 上的计算单元一样多的计算队列。但是 AMD 认为两个以上的异步计算队列并没有任何好处，并公开了这么多。 NVIDIA 似乎与完整的数字一致。

Copy\DMA 引擎（公开为 TRANSFER-only 系列）主要用于 CPU⇄GPU 传输。他们通常无法实现 GPU 内部副本的全部吞吐量。因此，除非有一些驱动程序魔法，否则 Async Transfer Family 应该用于 CPU⇄GPU 传输（以获得 Async 属性，能够不受阻碍地在其旁边执行 Graphics）。对于 GPU 内部的副本，大多数情况下使用 GRAPHICS|TRANSFER 系列会更好。