VK_KHR_dynamic_rendering_local_read (DRLR) closes the gap left by VK_KHR_dynamic_rendering (DR) where input attachments couldn't be used. As the Vulkan API moves towards dynamic rendering, usage of DRLR will increase and DR will eventually replace now-legacy VkRenderPass objects.
This change adds support for DRLR to RenderDoc. At a high level, DRLR allows the render pass color attachments to be mapped to "locations". Since the rest of the API does not use these remapped locations (notably, blend and vkCmdClearAttachments use the attachment index), I opted for RenderDoc to continue referencing the attachment by its index in the UI. However, where location matters (i.e. connection to the shader), the mapping is specified in the UI:
Additionally, an attachment can be mapped to VK_ATTACHMENT_UNUSED, in which case writes to it are automatically disabled. In this case, RenderDoc would tag the attachment as [disabled] and automatically set the Write Mask to ____:
DRLR additionally includes a mapping of attachments to InputAttachmentIndex decorations in the shader. For depth/stencil, the shader is no longer required to specify this decoration at all, in which case the corresponding API (VkRenderingInputAttachmentIndexInfoKHR) would also specify nullptr for the mapping. If VK_ATTACHMENT_UNUSED is specified in the mapping, the attachment is not expected to be used as input attachment. In the code, an additional flag for depth and stencil is present to differentiate between nullptr and VK_ATTACHMENT_UNUSED, with the format being an "implicit" mapping.
Notably, RenderDoc does not actually care about input attachment indices, but rather uses set/binding information to read from input attachments (e.g. during shader debugging), so the input index mapping information only ends up being used for the html export from the pipeline tab.
Description
VK_KHR_dynamic_rendering_local_read (DRLR) closes the gap left by VK_KHR_dynamic_rendering (DR) where input attachments couldn't be used. As the Vulkan API moves towards dynamic rendering, usage of DRLR will increase and DR will eventually replace now-legacy VkRenderPass objects.
This change adds support for DRLR to RenderDoc. At a high level, DRLR allows the render pass color attachments to be mapped to "locations". Since the rest of the API does not use these remapped locations (notably, blend and vkCmdClearAttachments use the attachment index), I opted for RenderDoc to continue referencing the attachment by its index in the UI. However, where location matters (i.e. connection to the shader), the mapping is specified in the UI:
Additionally, an attachment can be mapped to VK_ATTACHMENT_UNUSED, in which case writes to it are automatically disabled. In this case, RenderDoc would tag the attachment as
[disabled]
and automatically set the Write Mask to____
:DRLR additionally includes a mapping of attachments to
InputAttachmentIndex
decorations in the shader. For depth/stencil, the shader is no longer required to specify this decoration at all, in which case the corresponding API (VkRenderingInputAttachmentIndexInfoKHR
) would also specifynullptr
for the mapping. If VK_ATTACHMENT_UNUSED is specified in the mapping, the attachment is not expected to be used as input attachment. In the code, an additional flag for depth and stencil is present to differentiate betweennullptr
andVK_ATTACHMENT_UNUSED
, with the format being an "implicit" mapping.Notably, RenderDoc does not actually care about input attachment indices, but rather uses set/binding information to read from input attachments (e.g. during shader debugging), so the input index mapping information only ends up being used for the html export from the pipeline tab.
Fixes #3341