VK_DEPENDENCY_BY_REGION_BIT的含义和含义

Question

subpassLoadGLSL 函数可以访问输入附件，该函数在当前片段位置对输入附件进行采样，即接口不提供随机访问。这样做的结果是无法在任意片段位置访问输入附件。

这实际上意味着 [1]：

如果渲染技术需要读取当前片段区域之外的值（这在 tiler 上意味着访问当前渲染 tile 之外的渲染数据），则必须使用单独的渲染通道。

然后，关于VK_DEPENDENCY_BY_REGION_BIT，规范说[2]：

如果同步命令包含dependencyFlags 参数，并指定VK_DEPENDENCY_BY_REGION_BIT 标志，则它为所有帧缓冲区区域定义该同步命令中帧缓冲区空间流水线阶段的帧缓冲区本地依赖性。如果没有包含 dependencyFlags 参数，或者未指定 VK_DEPENDENCY_BY_REGION_BIT 标志，则为这些阶段指定帧缓冲区全局依赖项。

来自 ARM [3] 的 Hans-Kristian Arntzen 建议在平铺架构上，多子通道渲染通道只能与 VK_DEPENDENCY_BY_REGION_BIT 结合使用：

接下来，我们尝试将相邻的渲染通道合并在一起。这对于基于图块的渲染器尤为重要。如果出现以下情况，我们会尝试将通道合并在一起：

• 它们都是图形通道
• 它们共享一些颜色/深度/输入附件
• 存在的唯一深度/模板附件不超过一个
• 它们的依赖关系可以通过 BY_REGION_BIT 实现，即没有“纹理”依赖关系，允许对任意位置进行采样。

现在的问题是：

1. 如果您无论如何都无法访问当前片段位置之外的片段，那么VK_DEPENDENCY_BY_REGION_BIT 的意义何在？

2. 在平铺架构上，不能使用 VK_DEPENDENCY_BY_REGION_BIT 声明子通道依赖关系的多子通道渲染通道是否比功能等效且正确同步的一系列单独的单通道渲染通道提供任何性能优势？

Answer 1

好吧，规范给出了一个例子。如果您想访问片段未涵盖的输入附件示例，则必须使用帧缓冲区全局依赖项（即dependencyFlags = 0，或供应商扩展修复之一）。

虽然最明显的例子是非附件资源，它们自然是随机访问的（您可以访问任何像素）。使用VK_DEPENDENCY_BY_REGION_BIT，只有为同一个片段编写的部分才能确定是可见的。在使用帧缓冲区全局依赖项 (dependencyFlags=0) 时，您可以访问存储缓冲区中由前一个子通道的任何片段着色器调用写入的位置。

dependencyFlags=0 是一种 Render Pass 的软重启。所以一切都一样，我会这样给表演评分：
单个 Subpass ≥ 多个带有 VK_DEPENDENCY_BY_REGION_BIT 的 Subpass ≥ 多个不带 VK_DEPENDENCY_BY_REGION_BIT 的 Subpass ≥ 多个渲染通道。

framebuffer-global subpasses 是否真的提供了任何性能优势，如果不测量特定的实现，我不能说（这可能是一个易腐烂的信息，随着新的 GPU 或驱动程序版本的变化而变化）。虽然这种情况不应该比单独的渲染通道更糟糕，如果驱动程序本身无法对这些特殊子通道做任何事情，这可能是最糟糕的降级。