Vulkan的RenderPass和Command是否在GPU上并行执行

Question

第一个问题，我有两个renderPass，我没有设置它们的依赖关系，这两个renderPass是在GPU中并行执行，还是按照vkQueueSubmit执行时提交的commanbuffer顺序执行。例如：

1，渲染通道 1

2，渲染通道 2

3，渲染通道 3

那么 gpu 会按顺序执行 1,2,3 吗？ 或者同样，乱序并行执行 2,1,3?

第二个问题，renderPass只有一个，一个command buffer，vkCmdBeginRenderPass和vkCmdEndRenderPass之间记录在command buffer中的命令是在GPU上并行执行还是按照vkQueueSubmit执行的顺序执行.比如记录命令的顺序是：

1、vkCmdBindPipeline

2、vkCmdBindDescriptorSets

3、vkCmdDrawIndexed

4、vkCmdBindPipeline

5、vkCmdBindDescriptorSets

6、vkCmdDrawIndexed

所以在 GPU 中我们按顺序执行 1、2、3、4、5、6？ 或者再次，乱序 5,4,1,2,6,3 并并行执行？

Answer 1

就 Vulkan 规范而言，没有显式同步 的内容并发 执行。这意味着串行、并行、pre-empted 或 driver 希望的任何其他方式。这允许在任何东西上实现 Vulkan，包括例如单核 CPU，并允许 driver 可能想到的任何 weird-ass 优化。

Vulkan 的这种显式同步特性只有极少的例外。不妨一一列举：

1. Host Write Ordering Guarantees — 通过 vkMapMemory 指针写入对于任何后续 vkQueueSubmit 工作都是可见的，没有管道屏障
2. Rasterization Order — 在单个子通道中，无需同步两个 vkCmdDraw*s
之间的颜色和深度附件
3. 显而易见的东西——比如片段着色器在没有任何显式同步命令的情况下看到顶点着色器的输出。或者如果你使用 COHERENT 内存那么它是连贯的（按照文档描述的方式）。

vkCmdBind*命令只是状态设置命令。他们不执行任何事情。它们只会更改后续命令的上下文。 IE。 3 处的 vkCmdDrawIndexed 在由 1 和 2 绑定的管道和描述符集的上下文中执行，绘制 6 在由 2 绑定并随后由 5 修改的管道 4 和描述符集的上下文中执行。绘制在 3 和 6可能以任何顺序执行（或并行或pre-empted）。

根据 Vulkan 原则，尽管 driver 没有动力变得聪明，double-guess 你；特别是如果检查会花费资源。如果您先记录 vkCmdDraw*，则 driver 会部分假设您知道自己在做什么，然后只需先开始执行抽奖即可。