Forums - Vulkan subpasses merging issue

1 post / 0 new
Vulkan subpasses merging issue
vojtech.cimbura
Join Date: 27 Jul 23
Posts: 1
Posted: Wed, 2023-11-01 08:45

Hello.

we try to use subpasses to avoid memory transfers for attachments in a forward rendering pipeline, but our current implementation does not enable subpass merging, so memory transfers are happening (based on a SDP capture). All passes write to either the backbuffer or main depth-stencil target, or both. There are 6 passes we are trying to merge, each one of them modifies a renderpass attachment (either the backbuffer or the depth-stencil). There is not a possiblity to utilize input attachments easily as those two attachments are modified in subpasses.

We also tried to get help using the Vulkan Adreno Layer to see the reason why subpasses are not merged, but the only output is that subpasses are not qualified for merging, without providing a reason why. If we try to use VK_EXT_debug_utils at the same time, we just get a segfault inside Vulkan internal calls (e.g. VkGetImageMemoryRequirements). Our devices do not support VK_EXT_subpass_merge_feedback extension.

Questions:

  1. How do we get diagnostics from the validation layers about subpass merging, if our attempts using Qualcomm recommended debug tools failed? We are looking for the reason why individual subpasses are not merged.
  2. Is it required to use input attachments to achieve subpass merging?
  3. Is it possible to achieve subpass merging while using a RT / DS both as input and color / depth attachment? I.e. the subpass would read and write to the same attachment without writing to GMEM (data are kept on tile memory)?
  4. If you cannot R/W from/to an input and color/depth attachment at the same time to achieve subpass merging, what would you suggest the approach should be for subpass merging in a forward renderer?

I'd appreciate any feedback or tips. If necessary, I can provide more detailed information about the renderer setup.

  • Up4
  • Down0

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.