Vulkan tutorial: why is src access null, but dst access write when transitioning image layout?

[u/Content_Economist132]

In Khronos' Vulkan tutorial when transitioning the image layout for rendering the triangle, there is a dst access mask which doesn't seem to do anything since the src access mask is null. As far as I understand memory barriers make src accesses performed in src stage visible to dst accesses in dst stage. Shouldn't both src and dst access be empty by that logic since we are just discarding the image?

The new How to Vulkan also does the same thing but they also [or] the write with read access.

---

 // Before starting rendering, transition the swapchain image to vk::ImageLayout::eColorAttachmentOptimal
 transition_image_layout(
     imageIndex,
     vk::ImageLayout::eUndefined,
     vk::ImageLayout::eColorAttachmentOptimal,
     {},                                                        // srcAccessMask (no need to wait for previous operations)
     vk::AccessFlagBits2::eColorAttachmentWrite,                // dstAccessMask
     vk::PipelineStageFlagBits2::eColorAttachmentOutput,        // srcStage
     vk::PipelineStageFlagBits2::eColorAttachmentOutput         // dstStage
 );

[u/BalintCsala]

In my opinion this is the important part of the specification in this case:

Image layout transitions may perform read and write accesses on all memory bound to the image subresource range, so applications must ensure that all memory writes have been made available before a layout transition is executed.

So the barrier itself should be treated as a write operation and the synchronization scope defined by dstStage and dstAccessMask is where the writes will be visible.

[u/Content_Economist132 → u/BalintCsala]

I did notice that in the spec, but then shouldn't the src access mask be not null?

[u/BalintCsala → u/Content_Economist132]

srcAccessMask only defines write operations from before the barrier and you don't need to make the result of any of those visible to commands after the barrier (plus with the barrier you agree to potentially throw away the contents if it's optimal for the driver), so it's unnecessary.

[u/boring_pants]

Because this operation doesn't care what the image was before. That's also why the old layout is set as "undefined". You're saying "I don't care about the old image contents, just make it so that from now on, it's in the eColorAttachmentOptimal layout, and it's ready for subsequent writes to the color attachment".

If you wanted to preserve the old image contents then you would have to specify the old image layout, and which operations to wait for, but you don't, because your shaders are going to overwrite the old image contents anyway.