KhronosGroup / KhronosGroup/Vulkan-ValidationLayers
[Best practices] Possible inaccuracy/bug regarding depth/stencil resolve attachment access masks
- Dominant language
- C++
- Stars
- 1k
- Forks
- 504
- Avg merge
- 11h 35m
- Merged PRs (30d)
- 224
Description
Hi,
Reading the spec in https://docs.vulkan.org/spec/latest/chapters/renderpass.html#renderpass-resolve-operations it says that
> Fixed-function multisample resolve operations for attachments execute in the VK_PIPELINE_STAGE_COLOR_ATTACHMENT_OUTPUT_BIT pipeline stage. ... Reads from the multisample attachment can be synchronized with VK_ACCESS_COLOR_ATTACHMENT_READ_BIT. Access to the single sample attachment can be synchronized with VK_ACCESS_COLOR_ATTACHMENT_READ_BIT and VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT. **These pipeline stage and access types are used whether the attachments are color or depth/stencil attachments.**
So according to this paragraph, if I want to read from the depth/stencil resolve attachment afterwards, I should use `VK_ACCESS_COLOR_ATTACHMENT_READ_BIT` etc. I have a basic state tracker implemented on the host, to keep the last access stage and access masks, so at the end of my renderpass I set those to `VK_PIPELINE_STAGE_2_COLOR_ATTACHMENT_OUTPUT_BIT` and `VK_ACCESS_2_COLOR_ATTACHMENT_WRITE_BIT` as per the spec suggestions that I’ve linked. Then when I’m trying to transition this attachment’s image in order to read/transfer from it, I get the following validation error from the “best practices” checks.
> vkCmdPipelineBarrier2KHR(): pDependencyInfo->pImageMemoryBarriers[0] image is VkImage 0x3270000000327[Depth/Stencil Resolve Texture] and accessMask is VK_ACCESS_2_COLOR_ATTACHMENT_WRITE_BIT, but for layout VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL expected accessMask are VK_ACCESS_2_DEPTH_STENCIL_ATTACHMENT_READ_BIT|
VK_ACCESS_2_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT.
Searching a bit I found https://github.com/KhronosGroup/Vulkan-ValidationLayers/issues/2918 , where the table that associates layouts (`DEPTH_STENCIL_ATTACHMENT_OPTIMAL` in my case) and access masks seems to agree with the message that I'm getting, but these probably do not agree with what the spec is saying, at least in the case of depth/stencil resolve images. Thanks for your time!
Contributor guide
Research direction
Start with the renderpass resolve-operations section in the linked Vulkan specification and compare it with the access-mask/layout expectations described in issue 2918. Trace the best-practices check that produces the reported vkCmdPipelineBarrier2KHR message, then verify that depth/stencil resolve attachments are handled consistently with the specification.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- devtools
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100