Spec issue with "VK_IMAGE_LAYOUT_ DEPTH_READ_ONLY _STENCIL_ATTACHMENT_OPTIMAL"

[DevLewa]

Hi!
I’m posting here in hopes of getting clarification with regards to the usage of VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL

The spec states: (VkImageLayout(3)):

VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL specifies a layout for depth/stencil format images allowing read and write access to the stencil aspect as a stencil attachment, and read only access to the depth aspect as a depth attachment or in shaders as a sampled image, combined image/sampler, or input attachment. It is equivalent to VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_OPTIMAL and VK_IMAGE_LAYOUT_STENCIL_ATTACHMENT_OPTIMAL.

Which from my understanding makes the depth-aspect of a depth/stencil image read only (which in turn allows us to access it as a read-only attachment and/or a sampler to pass to a shader) while the stencil part remains in read/write mode for the attachment only. (Which is the exact usecase that is required for deferred rendering for example.)

Now the part that i don’t understand: (https://vulkan.lunarg.com/doc/view/1.2.176.1/windows/1.2-extensions/vkspec.html#renderpass-attachment-nonattachment)

For depth/stencil attachments, each aspect can be used separately as attachments and non-attachments as long as the non-attachment accesses are also via an image subresource in either the VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL layout or the VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL layout, and the attachment resource uses whichever of those two layouts the image accesses do not.

Specifically i assumed that if you want to use a depth/stencil image as a depth read-only attachment AND at the same time as a sampler (to pass to the shader in the case of position reconstruction for deferred rendering) while having read/write access of the stencil aspect during the renderpass i would have to set both the attachment layout and descriptorimage layout to VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL

But the spec seems to suggest that if you (for example) set the layout of the descriptorimage to
VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL
(because you want to only read the depth) you HAVE to set the layout of the attachment to
VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL
which doesn’t really make sense as the attachment layout states that the stencil aspect is then read only (which is not what we want to achieve.)

This was also implemented into the validation layers (at around 1.2.160?) in the descriptor_sets validation checks (which forces you to have those two different layouts in the descriptor and attachment):

    //image layout is the layout of the descriptorimage.
    if ((image_layout == VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL &&
    	 subpasses[att_index].layout ==
    		 VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL) ||
    	(subpasses[att_index].layout ==
    		 VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL &&
    	 image_layout == VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL)) {
    	continue;
    }

This issue was also mentioned on github:

Unclear depth\stancil usage in attachment + non-attachment

Can someone clarify if this is an oversight or some limitation/ongoing issue with the spec?

/Edit: Just realised that i haven’t posted this in the correct sub-category on the forum. My bad. Will not happen again.

[krOoze]

Can’t hurt if you poke the Issue. Not much point informally discussing things that Khronos needs to officially address.

[DevLewa]

Didn’t expect to get an answer of the original author of said issue on Github.

I’ve poked around the spec and validation layers to find a solution and i think i’ve found something.
I think the this rule …

For depth/stencil attachments, each aspect can be used separately as attachments and non-attachments as long as the non-attachment accesses are also via an image subresource in either the VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL layout or the VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL layout, and the attachment resource uses whichever of those two layouts the image accesses do not.

… only applies if you try to use the same imageview for the attachment and non-attachment (sampler). (I noticed that the validation layers check for that and then throw the error if the layouts don’t follow said rule.)

I was able to get it working (with the current SDK and validation layers) by using two seperate imageviews for the attachment/non-attachment part. (Using the same imageview for the attachment and non-attachment was in this case already against the spec as the sampler can only have 1 aspect bit enabled while the attachment has two.)
Basically for the depth-stencil buffer create an imageview with the VK_IMAGE_ASPECT_DEPTH_BIT | VK_IMAGE_ASPECT_STENCIL_BIT bits set. This is our imageview which will be used for the attachment.

For the sampler/descriptor create a second imageview with just the VK_IMAGE_ASPECT_DEPTH_BIT bit set. (both of the imageviews point to the same VkImage)

In the renderpass transition the image to VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL and also use this layout in the VkAttachmentReference struct.

Now for the non-attachment/sampler part (VkDescriptorImageInfo) we use the second imageview (with only the depth-aspect bit set), and set the image layout of the descriptorImageInfo struct to VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL

This compiles fine/works without any issues (as far as i can see) and also passes the most recent validation layer checks. (Although i’m still not entirely sure if this is spec conform due to the wording of those rules.)

[krOoze]

Well I have like the third of the Issues there and am like one of about three people to consistently answer here, so statistics at work…

AIS, not much point discussing stuff at length. We all see the same specification, and if we cannot arrive independently at the same interpretation (or at any interpretation in the first place), then that is a problem only the spec makers can fix.

I am sorry to say that validation layer devs do not always know any better. And oftentimes when not sure they just make stuff up, rather than issue a ticket against the spec to resolve it. So taking layers as some authoritative source (which it isn’t) is bit of a slippery slope.

It is conceivable they need to be a seprate Image View, as well as the contrary is conceivable. It boils down to point nr. 5 in the issue, and what constitutes a “use”. The read access having only the one aspect sure sounds like a reasonable code style though…

And the attachment and nonattachment having the same VK_IMAGE_LAYOUT_*_READ_ONLY_*_ATTACHMENT_OPTIMAL seems the only logical way. I believe that before VK_KHR_separate_depth_stencil_layouts extension the depth and the stencil aspect is not allowed to have differing layouts anyway.

Anyway I poked the Issue thread for ya, and for my part that is the best I can do. As you see I am not eager to get too much into extra-specification guesswork.