vulkan - 为什么输入附件需要绑定(bind)描述符集？

Question

VkRenderPassCreateInfo包含用于深度，颜色和输入附件的附件索引。相应的图像视图在VkFramebufferCreateInfo::pAttachments中引用。

在着色器中，input_attachment_index标识着色器正在使用哪个输入附件。

假定在渲染过程中绑定了帧缓冲区，这应该允许将图像视图的标识用于输入附件，就像对深度和颜色附件一样。

我不明白为什么Vulkan还需要在描述符集布局中并因此在绑定描述符集中提及输入附件(而不是其他附件)。

我觉得我在这里想念什么吗？输入附件需要绑定描述符是什么？

Answer 1

它与管道布局和兼容性有关。

就目前而言，管道布局完全由VkPipelineLayoutCreateInfo定义。此结构包含一些标志，一个VkDescriptorSetLayout数组和一个VkPushConstantRange数组。这意味着管道的布局实际上并不关心着色器中定义的内容。它只关心描述符(和推送常量)。显然，着色器必须匹配描述符，但这是着色器要处理的问题。

Vulkan根据两个管道之间的管道布局兼容性来定义描述符兼容性。这意味着共享相同管线布局的两个管线是兼容的，而不管那些管线(或任何其他管线状态)中的着色器的内容如何。

因此，如果我们从描述符集中删除输入附件，则现在拥有此着色器正在使用的概念资源，而该资源不是描述符。对于将输入附件实现为专用操作的硬件(TBR，其中输入附件只是从本地切片存储器中读取)，这很好。对于将输入附件实现为实际从纹理读取的硬件，这不是很好。为什么？

由于布局兼容性规则。请记住:它们不是基于着色器中的内容；它们是基于着色器的。它们仅基于管道布局中的内容。因此，如果我有两个使用相同布局的管道，则它们必须兼容。但是，如果一个管道有一个使用输入附件的片段着色器，而另一个则不使用，则您如何实现它以匹配布局兼容性规则，同时又保留这种隐藏的纹理？

管道布局和描述符集映射到实现中的某种资源绑定机制。因此，布局定义了如何将各种描述符集应用于实现定义的资源绑定。如果我们将纹理绑定看做是一个值的数组，则设置0的纹理将在设置1之前分配，设置2在其之后分配，依此类推。

如果输入附件不是描述符，那么如何将输入附件纹理(同样，对于将输入附件视为纹理的实现)绑定到实现定义的资源绑定范围呢？

可以在子阶段开始时完成，因为子阶段知道它使用的所有输入附件。输入的附件纹理将绑定到特定的纹理阵列位置，并且在该子遍期间不会更改。假设我们有一个输入附件，它选择纹理数组索引0进行绑定。

但是那不可能发生。布局兼容性规则不允许这样做。不使用输入附件的管道将假定索引集0可以自由使用描述符集。因此，它们将与使用输入附件的管道不兼容。但是Vulkan不允许它们不兼容，因为兼容性仅是为管道布局定义的，而不是为管道对象本身的属性(如着色器)定义的。

可以通过每个管道绑定调用来完成。也就是说，每次绑定使用输入附件的管道时，它也会有效地将纹理绑定到特定的数组索引。对于不同的管道，该数组索引将有所不同。

但是，这同样不可能发生，这要归功于布局兼容性规则。如果我有使用某些描述符集布局0和1的管道A，以及使用相同初始描述符集布局0的管道B，则Vulkan说我可以将描述符集绑定到集0和1(与布局匹配)，并且我可以以任何顺序使用那些绑定了描述符集的管道。我不必在管道更改之间进行任何描述符集重新绑定。

如果管道B使用输入附件，则按照上述规则，它将在纹理数组中为该输入附件分配一个附加索引。但是该数组索引当前可能由描述符集1使用，而管道B对此不了解。因此，绑定管道B将破坏描述符集1。这违反了规范。

管道布局兼容性是Vulkan的一项非常有用的功能。它使您知道何时需要绑定描述符集，以及何时可以更改管道而无需更改集。这些都是好东西，对于运行时性能很有用。

而且，它们在无法将输入附件实现为纹理的世界中根本无法工作。因此，Vulkan要求您使其明确(因为对事物明确是Vulkan的重点)。在没有使其纹理化的实现中，它只是完全忽略了那些描述符。

还应注意 according to this presentation (PDF)，即使TBR有时也可以将输入附件视为纹理提取。当子通道无法“融合”在一起时，会发生这种情况。当无法将附件数据保留在子遍之间的图块中时，就会发生这种情况。这基于渲染通道本身的属性，因此可以预先确定。

这就是为什么它是输入附件。