想象一下一个用例,其中附件作为保留附件包含在RenderPass的第一个子过程中。我将“第一个子通道”定义为子通道A,其中存在一个带有N个子通道的RenderPass,并且在其子通道之间存在依赖关系,必须首先执行A。
现在,这个用例对我来说没有意义。但是,我去寻找规范中的清晰度,到目前为止,我还没有遇到任何禁止它的东西。在我的代码中,我现在通过检测到该事件时发出断言失败来处理此问题。但是,我真的很想从Spec的口中得知,这实际上不是法律/明智的事情。我想避免做出假设。
如果有人知道我在哪里可以找到有关此用例的可靠信息,请指向我。
存在保留附件以处理以下情况:
你有一个可操作附件的子通道A。你有一个子通道C,它使用A生成的附件中的数据。因此,A和C之间存在一定的依赖关系。但是,你还有一个子通道B,它依赖于A生成的其他一些数据,并且C依赖于也是如此(因此,可以基于A-> B和B-> C依赖关系隐含A和C的依赖关系)。
也就是说,子通道B必须在A和C之间执行。但是,也可以说,子通道B本身不使用A为C生成的特定附件。
因为执行图要求B在A和C之间执行,所以实现此执行图的任何硬件都可能需要在子遍B内分配一些存储,以确保保留此附件的内容。特别是在基于图块的渲染器上,这样的存储通常非常宝贵。因此,Vulkan API要求你在子传递B的定义中明确声明,即使B不将其用于任何操作,在执行B时也必须保留A的附件。
这是唯一保留附件的地方。即使这样,Vulkan规范中也没有任何内容禁止在这种情况下使用保留附件。你不会在规范中找到任何声明禁止这样做的陈述,只有关于保留附件的必要性的陈述。
现在,这并不意味着你应该只在任何地方推送保留附件。你必须在需要时使用它们,仅此而已。
谢谢,谢谢你的回答。我确实了解它们的用法。我从Spec中寻求特定答案的特殊原因是,我正在构建RenderGraph编译器之类的东西,并且我希望支持定义和使用RenderPasses时可能进行的所有操作。如果这不是违法的,也许可以以某种晦涩难懂的方式使用该功能,以达到某些晦涩难懂的目标,而我对此并不陌生,认为这是可能的。这更像是一种健壮性。
规范中有很多地方专门禁止事物使用,我希望可以更加清楚此用例的合法性。在宏伟的计划中,这并不是什么大不了的事情。如果可能的话,最好是有一个明确的答案。由于我目前正在做的工作,我有时间对渲染通道的细节进行深入思考。编译器应该能够处理所引发的任何法律工作,并且由于某些细节可能很小,因此需要以某种方式处理它们。