Please consider adding support for VK_KHR_dynamic_rendering_local_read

[ShabbyX]

Description

The VK_KHR_dynamic_rendering_local_read extension closes a big gap between VK_KHR_dynamic_rendering and VkRenderPass objects. For applications that use input attachments, this extension is an absolute necessity to enable them to move to dynamic rendering (which is already part of core Vulkan 1.3).

Please consider adding support for this extension. It's likely not too difficult to implement, but it does include an annoyance with color and input attachment index mapping. In particular, unlike the subpass mapping of color locations to render pass attachments, the mapping in this extension does not affect blend states etc matching dynamic rendering attachments.

Environment

• RenderDoc version: v1.33
• Operating System: Linux
• Graphics API: Vulkan

[ShabbyX]

Some gotchas and findings:

• When reading from input attachments (in shader debugger), if input attachments are read from the descriptor set, then VkRenderingInputAttachmentIndexInfoKHR can largely be ignored. It may still need to be used to extract the format of the attachments correctly.

• Depth/stencil input attachments now don't need an input_attachment_index. Lack of that decoration + type (float vs int) implicitly defines depth and stencil input attachments.

• VkRenderingAttachmentLocationInfoKHR remaps the render pass attachments to "locations". The shader references locations (for example writing to locations 2 and 5), which needs care to map to attachments (which for example could be at index 1 and 0 respectively)

• vkCmdClearAttachments, blend state, etc still reference the attachment index, NOT the location. This is the only real deviation from subpasses.

• The mappings, if any, should be specified in the pipeline (if not shader object), and matching mappings should be specified either as command buffer inheritance info or via vkCmdSet* functions.

• In some cases, the mappings can be nullptr, meaning identity mapping.

• If VkRenderingAttachmentLocationInfoKHR maps an attachment to VK_ATTACHMENT_UNUSED, it must be disabled! The application doesn't have to explicitly mask writes to the attachment.