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

如何解决Vulkan的RenderPass和Command是否在GPU上并行执行

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

1，renderpass1

2，renderpass2

3，renderpass3

那么gpu会按顺序执行1,2,3吗？ 还是再次，乱序并行执行2,1,3？

第二个问题是，只有一个renderPass，一个命令缓冲区，并且记录在vkCmdBeginRenderPass和vkCmdEndRenderPass之间的命令缓冲区中的命令在GPU上并行执行，或者按vkQueueSubmit的顺序执行。例如，记录的命令顺序为：

1，vkCmdBindPipeline

2，vkCmdBindDescriptorSets

3，vkCmdDrawIndexed

4，vkCmdBindPipeline

5，vkCmdBindDescriptorSets

6，vkCmdDrawIndexed

那么在GPU中我们依次执行1,3,4,5,6吗？ 还是再次，顺序为5,6,3并并行进行？

解决方法

就Vulkan规范而言，无显式同步的内容同时执行 。这意味着串行，并行，抢占或驱动程序希望的任何其他方式。这允许在任何东西上实现Vulkan，例如单核CPU，并允许驱动程序可能想到的任何怪异的优化。

Vulkan的这种显式同步特性只有极少数例外。最好枚举它们：

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

vkCmdBind*命令仅是状态设置命令。他们什么都不执行。它们仅更改后续命令的上下文。即{3}处的vkCmdDrawIndexed在以1和2为界的管道和描述符集的上下文中执行，而绘制6在以2和2为界的管道4和描述符集的上下文中执行，然后由5修改。在3和6处的绘制彼此之间可以以任何顺序执行（或并行执行或抢占）。

按照Vulkan的原则，尽管驾驶员没有动机去变得聪明，并且会双重猜测。特别是如果这会花费大量资源进行检查。如果您首先记录vkCmdDraw*，则驱动程序会偏向于假设您知道自己在做什么，而只是首先开始执行该绘制。