KhronosGroup / KhronosGroup/Vulkan-ValidationLayers

[Best practices] Possible inaccuracy/bug regarding depth/stencil resolve attachment access masks

Open
#11,341 0 comments 0 reactions 0 assignees View on GitHub
BestPractices
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.