Layout discrepancy in dynamic_rendering_local_read

[mbty-hi]

There is a discrepancy between the layout swapchain_buffers[i].image gets transitioned to before the render/gets transitioned from after it, and what is declared as part of the related VkRenderingAttachmentInfoKHR in the dynamic_rendering_local_read sample (VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL vs. VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR). Despite that, the sample runs without warnings on machine, though it must be said that it still runs fine if I replace the VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL with about any other layout, or even if I wholly remove the two explicit transitions for this resource. Similarly, I can replace VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR with other layouts without Vulkan complaining. However, switching the nearby VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_OPTIMAL for a VK_LAYOUT_UNDEFINED results in a black screen (understandably). I wonder if this could be a matter of layouts actually being the same behind the scenes (resulting in ignored transitions/accidental compatibility) + incomplete layers, though I may well be misunderstanding something more fundamental.

[SaschaWillems]

Thanks for bringing this up. We'll take a look and fix if necessary.

As for changing things and not seeing issues: What happens depends on how much GPU architectures rely in image layouts. Some might not rely on them at all (vendor A), while others (vendor B) might be very strict about them being correct. That would explain why only certain changes cause issues on your setup.

[asuessenbach]

On Win11, using NVIDIA GPU, I get this VVL error:

vkCmdBeginRenderingKHR(): pRenderingInfo->pColorAttachments[0] (VkImage 0x50000000005, layer 0, mip 0) is expected to have layout VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ but previous known layout is VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL.
The Vulkan spec states: For each element of pRenderingInfo->pColorAttachments, if imageView is not VK_NULL_HANDLE, that image view must be in the layout specified by imageLayout (https://docs.vulkan.org/spec/latest/chapters/renderpass.html#VUID-vkCmdBeginRendering-pRenderingInfo-09592)

[asuessenbach]

One could easily silence the VVL by changing the imageLayout for the first color_attachment (which is the swapchain buffer), like this in dynamic_rendering_local_read.cpp, line 856:
color_attachment_info[j].imageLayout = (j == 0) ? VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL : VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR;

But I don't know enough about local read rendering, if that's the correct way to use that extension.

If it needs to be VK_IMAGE_LAYOUT_RENDERING_LOCAL_READ_KHR, we would need to adjust some parts of the framework.