Thanks for putting this up, it looks much nicer than the previous solution. If I understand correctly, a depth-stencil view would use the following layout:

• If readonly is false: VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL
• If readonly is true: VK_IMAGE_LAYOUT_GENERAL or VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL depending on the Vulkan WG's answer.

I think it might be best to allow for future expansion where depth and stencil can independently be readonly. This could be done with GPUTextureAspect readOnlyAspects. WDYT?

From meeting: unresolved: want to have benchmarks vs GENERAL layout

Update: I prototyped a solution suggested in KhronosGroup/Vulkan-Docs#1291 (comment), and it appears to work well. So the current spec has no issues, and we can keep it.

Having any kind of benchmarks of image layouts would still be very useful!

I also think it's worth keeping this PR open for discussion, albeit at lower priority than before. It's useful because it works better for D3D12.

Very nice!

So I suppose we would also still ideally like:

• benchmark or analysis of SHADER_READ_ONLY vs DEPTH_STENCIL_READ_ONLY for sampled depth/stencil textures that aren't used as attachments (as SHADER_READ_ONLY could theoretically be more optimal)
• views that are read-only in either or both aspects for D3D12

AFAIU we already have the signals in WebGPU that would allow us to use DEPTH_READ_ONLY_STENCIL_ATTACHMENT_OPTIMAL/DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL when a DS texture is used only as an attachment; is that right?
With an extension, we could allow sampling of the readonly aspect (but that seems low priority).

Thanks @kvark for raising this issue with on the Vulkan repo. If I understand correctly, there is no longer an issue for implementability on Vulkan because the following would work:

For bindgroup creation the VkImageLayout of a depth-stencil texture binding would be:

• VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL for textures both renderable and sampleable.
• VK_IMAGE_LAYOUT_SHADER_READONLY_OPTIMAL for only sampleable textures.

Then for vkCmdBeginRenderPass the VkImageLayout would be:

• VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL if the pass is readonly (or the correct partially readonly layout when we support that in WebGPU).
• VK_IMAGE_LAYOUT_DEPTH_STENCIL_ATTACHMENT_OPTIMAL otherwise.

I don't really have concerns with for D3D12 DSV creation because IMHO there's few enough render passes in a frame that they can be created on demand. So I don't think we need this PR either. (and there's no need for benchmark! woot)

I think that with the Vulkan issue fixed, this can be closed. We haven't had issue implementing readonly depth-stencil in Dawn either.