Vulkan 中的 Queue 族实际上是什么?
What is actually a Queue family in Vulkan?
我目前正在学习 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个Queue family,一个queue family有16个queue,都可以进行图形、计算、传输和稀疏绑定操作(不知道最后两个是什么)
另一个有 1 个队列,只能传输(不管是什么)
最后一个有 8 个能够进行计算操作的队列。
每个队列系列是什么?我知道这是我们发送执行命令(如绘制和交换缓冲区)的地方,但这是一个有点宽泛的解释,我想要一个更详细的答案。
额外的 2 个标志是什么?转移和稀疏出价?
最后,为什么我们要 have/need 多个命令队列?
要了解队列系列,您首先必须了解队列。
队列是您向其提交命令缓冲区的对象,提交至队列的命令缓冲区相对于彼此按顺序[*1] 执行。提交到不同队列的命令缓冲区相对于彼此是无序的,除非您明确地将它们与 VkSemaphore
同步。一次只能从一个线程向队列提交工作,但不同线程可以同时向不同队列提交工作。
每个队列只能执行某些类型的操作。图形队列可以 运行 由 vkCmdDraw*
命令启动的图形管道。计算队列可以 运行 计算由 vkCmdDispatch*
启动的管道。传输队列可以从 vkCmdCopy*
执行传输(复制)操作。稀疏绑定队列可以使用 vkQueueBindSparse
改变稀疏资源与内存的绑定(注意这是直接提交给队列的操作,而不是命令缓冲区中的命令)。一些队列可以执行多种操作。在规范中,每个可以提交到队列的命令都有一个 "Command Properties" table 列出了哪些队列类型可以执行命令。
队列族只是描述了一组具有相同属性的队列。所以在你的例子中,设备支持三种队列:
一种可以做图形、计算、传输和稀疏绑定操作,最多可以创建16个这种类型的队列。
另一种只能做中转操作,这种队列只能创建一个。通常这用于离散 GPU 上主机和设备内存之间的异步 DMAing 数据,因此传输可以与独立的 graphics/compute 操作同时完成。
最后,您最多可以创建 8 个只能进行计算操作的队列。
一些队列可能只对应主机端调度器中的单独队列,其他队列可能对应硬件中实际的独立队列。例如,许多 GPU 只有一个硬件图形队列,因此即使您从具有图形功能的队列系列中创建两个 VkQueue,提交到这些队列的命令缓冲区将独立地通过内核驱动程序的命令缓冲区调度程序进行处理,但会以一些串行方式执行在 GPU 上排序。但是一些 GPU 具有多个仅计算硬件队列,因此用于仅计算队列系列的两个 VkQueue 实际上可能会独立并并发地贯穿 GPU。 Vulkan 不会暴露这一点。
最重要的是,根据您的并发量来决定您可以使用多少个队列。对于许多应用程序来说,一个 "universal" 队列就足够了。更高级的可能有一个图形+计算队列,一个用于异步计算工作的单独的仅计算队列,以及一个用于异步 DMA 的传输队列。然后将您想要的映射到可用的;您可能需要自己进行多路复用,例如在没有纯计算队列系列的设备上,您可以创建多个图形+计算队列,或者将您的异步计算作业序列化到您自己的单个图形+计算队列中。
[*1] 有点过于简单化了。他们按顺序开始,但之后可以独立进行并乱序完成。但是不能保证不同队列的独立进程。这个问题就到此为止吧。
队列接受包含给定类型操作的命令缓冲区(由系列标志给出)。提交到队列的命令有一个提交顺序,因此它们受制于流水线障碍、子通道依赖性和事件的同步(而跨队列必须使用信号量或更好的)。
有一个技巧:COMPUTE
和 GRAPHICS
总是可以隐式接受 TRANSFER
工作负载(即使 QueueFamilyProperties
没有列出它。请参阅下面的注释 Specification of VkQueueFlagBits).
传输用于复制和 Blit 命令。稀疏类似于分页;它允许将多个内存句柄绑定到单个图像,并且它允许稍后重新绑定不同的内存。
在规范中,下面给出的 vkCmd*
命令总是说明哪些是 "Supported Queue Types"。
Queue Family 是一组与自身有特殊关系的队列。有些东西仅限于单个队列族,例如图像(它们必须在队列族之间传输)或命令池(创建命令缓冲区仅供给定队列族使用,而不供其他人使用)。理论上,在某些奇特的设备上,可能会有更多具有相同标志的队列系列。
这几乎是 Vulkan 规范所保证的一切。请参阅 KhronosGroup/Vulkan-Docs#569
中的问题
提供了一些特定于供应商的材料,例如:
- AMD 的 Leveraging asynchronous queues for concurrent execution
- NVIDIA 的 Moving to Vulkan: Asynchronous compute
GPU 具有异步图形引擎、计算引擎和 Copy\DMA 引擎。图形和计算当然会竞争 GPU 的相同计算单元。
他们通常只有一个图形前端。这是图形操作的瓶颈,因此这意味着没有必要使用多个图形队列。
计算有两种操作模式:同步计算(公开为 GRAPHICS|COMPUTE
系列)和异步计算(公开为 COMPUTE
-only 系列)。首先是安全的选择。第二个可以给你大约 10% 的性能,但更棘手,需要更多的努力。 AMD 文章建议始终以第一个为基准。
理论上可以有与 GPU 上的计算单元一样多的计算队列。但 AMD 认为,两个以上的异步计算队列没有任何好处,并公开了那么多。 NVIDIA 似乎与完整数字一致。
Copy\DMA 引擎(公开为 TRANSFER
-only 系列)主要用于 CPU⇄GPU 传输。它们通常无法实现 GPU 内部副本的全部吞吐量。因此,除非有一些驱动程序魔法,否则异步传输系列应该用于 CPU⇄GPU 传输(获得异步 属性,能够不受阻碍地在其旁边执行图形)。对于内部 GPU 副本,在大多数情况下使用 GRAPHICS|TRANSFER
系列应该更好。
我目前正在学习 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个Queue family,一个queue family有16个queue,都可以进行图形、计算、传输和稀疏绑定操作(不知道最后两个是什么)
另一个有 1 个队列,只能传输(不管是什么)
最后一个有 8 个能够进行计算操作的队列。
每个队列系列是什么?我知道这是我们发送执行命令(如绘制和交换缓冲区)的地方,但这是一个有点宽泛的解释,我想要一个更详细的答案。
额外的 2 个标志是什么?转移和稀疏出价?
最后,为什么我们要 have/need 多个命令队列?
要了解队列系列,您首先必须了解队列。
队列是您向其提交命令缓冲区的对象,提交至队列的命令缓冲区相对于彼此按顺序[*1] 执行。提交到不同队列的命令缓冲区相对于彼此是无序的,除非您明确地将它们与 VkSemaphore
同步。一次只能从一个线程向队列提交工作,但不同线程可以同时向不同队列提交工作。
每个队列只能执行某些类型的操作。图形队列可以 运行 由 vkCmdDraw*
命令启动的图形管道。计算队列可以 运行 计算由 vkCmdDispatch*
启动的管道。传输队列可以从 vkCmdCopy*
执行传输(复制)操作。稀疏绑定队列可以使用 vkQueueBindSparse
改变稀疏资源与内存的绑定(注意这是直接提交给队列的操作,而不是命令缓冲区中的命令)。一些队列可以执行多种操作。在规范中,每个可以提交到队列的命令都有一个 "Command Properties" table 列出了哪些队列类型可以执行命令。
队列族只是描述了一组具有相同属性的队列。所以在你的例子中,设备支持三种队列:
一种可以做图形、计算、传输和稀疏绑定操作,最多可以创建16个这种类型的队列。
另一种只能做中转操作,这种队列只能创建一个。通常这用于离散 GPU 上主机和设备内存之间的异步 DMAing 数据,因此传输可以与独立的 graphics/compute 操作同时完成。
最后,您最多可以创建 8 个只能进行计算操作的队列。
一些队列可能只对应主机端调度器中的单独队列,其他队列可能对应硬件中实际的独立队列。例如,许多 GPU 只有一个硬件图形队列,因此即使您从具有图形功能的队列系列中创建两个 VkQueue,提交到这些队列的命令缓冲区将独立地通过内核驱动程序的命令缓冲区调度程序进行处理,但会以一些串行方式执行在 GPU 上排序。但是一些 GPU 具有多个仅计算硬件队列,因此用于仅计算队列系列的两个 VkQueue 实际上可能会独立并并发地贯穿 GPU。 Vulkan 不会暴露这一点。
最重要的是,根据您的并发量来决定您可以使用多少个队列。对于许多应用程序来说,一个 "universal" 队列就足够了。更高级的可能有一个图形+计算队列,一个用于异步计算工作的单独的仅计算队列,以及一个用于异步 DMA 的传输队列。然后将您想要的映射到可用的;您可能需要自己进行多路复用,例如在没有纯计算队列系列的设备上,您可以创建多个图形+计算队列,或者将您的异步计算作业序列化到您自己的单个图形+计算队列中。
[*1] 有点过于简单化了。他们按顺序开始,但之后可以独立进行并乱序完成。但是不能保证不同队列的独立进程。这个问题就到此为止吧。
队列接受包含给定类型操作的命令缓冲区(由系列标志给出)。提交到队列的命令有一个提交顺序,因此它们受制于流水线障碍、子通道依赖性和事件的同步(而跨队列必须使用信号量或更好的)。
有一个技巧:COMPUTE
和 GRAPHICS
总是可以隐式接受 TRANSFER
工作负载(即使 QueueFamilyProperties
没有列出它。请参阅下面的注释 Specification of VkQueueFlagBits).
传输用于复制和 Blit 命令。稀疏类似于分页;它允许将多个内存句柄绑定到单个图像,并且它允许稍后重新绑定不同的内存。
在规范中,下面给出的 vkCmd*
命令总是说明哪些是 "Supported Queue Types"。
Queue Family 是一组与自身有特殊关系的队列。有些东西仅限于单个队列族,例如图像(它们必须在队列族之间传输)或命令池(创建命令缓冲区仅供给定队列族使用,而不供其他人使用)。理论上,在某些奇特的设备上,可能会有更多具有相同标志的队列系列。
这几乎是 Vulkan 规范所保证的一切。请参阅 KhronosGroup/Vulkan-Docs#569
中的问题提供了一些特定于供应商的材料,例如:
- AMD 的 Leveraging asynchronous queues for concurrent execution
- NVIDIA 的 Moving to Vulkan: Asynchronous compute
GPU 具有异步图形引擎、计算引擎和 Copy\DMA 引擎。图形和计算当然会竞争 GPU 的相同计算单元。
他们通常只有一个图形前端。这是图形操作的瓶颈,因此这意味着没有必要使用多个图形队列。
计算有两种操作模式:同步计算(公开为 GRAPHICS|COMPUTE
系列)和异步计算(公开为 COMPUTE
-only 系列)。首先是安全的选择。第二个可以给你大约 10% 的性能,但更棘手,需要更多的努力。 AMD 文章建议始终以第一个为基准。
理论上可以有与 GPU 上的计算单元一样多的计算队列。但 AMD 认为,两个以上的异步计算队列没有任何好处,并公开了那么多。 NVIDIA 似乎与完整数字一致。
Copy\DMA 引擎(公开为 TRANSFER
-only 系列)主要用于 CPU⇄GPU 传输。它们通常无法实现 GPU 内部副本的全部吞吐量。因此,除非有一些驱动程序魔法,否则异步传输系列应该用于 CPU⇄GPU 传输(获得异步 属性,能够不受阻碍地在其旁边执行图形)。对于内部 GPU 副本,在大多数情况下使用 GRAPHICS|TRANSFER
系列应该更好。