Does it make sense to have READ_BIT in source access mask?

Vulkan
1

Memory barriers are supposed to prevent read-after-write and write-after-write hazards. After a read operation, the data is unchanged so there should be no need to make it available.

But the spec and validation layers do allow READ_BIT flags in srcAccessMask. Some implicit dependencies are defined as:

VkSubpassDependency implicitDependency = {
    .srcSubpass = lastSubpass; // Last subpass attachment is used in
    .dstSubpass = VK_SUBPASS_EXTERNAL;
    .srcStageMask = VK_PIPELINE_STAGE_ALL_COMMANDS_BIT;
    .dstStageMask = VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT;
    .srcAccessMask = VK_ACCESS_INPUT_ATTACHMENT_READ_BIT |
        VK_ACCESS_COLOR_ATTACHMENT_READ_BIT |
        VK_ACCESS_COLOR_ATTACHMENT_WRITE_BIT |
        VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_READ_BIT |
        VK_ACCESS_DEPTH_STENCIL_ATTACHMENT_WRITE_BIT;
    .dstAccessMask = 0;
    .dependencyFlags = 0;
};

I’ve also seen this after mipmap generation in the Khronos Vulkan samples:

// After the loop, all mip layers are in TRANSFER_SRC layout, so transition all to SHADER_READ
vkb::insert_image_memory_barrier(
    blit_command,
    texture.image,
    VK_ACCESS_TRANSFER_READ_BIT, // srcAccessMask
    VK_ACCESS_SHADER_READ_BIT, // dstAccessMask
    VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL,
    VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL,
    VK_PIPELINE_STAGE_TRANSFER_BIT,
    VK_PIPELINE_STAGE_FRAGMENT_SHADER_BIT,
    {VK_IMAGE_ASPECT_COLOR_BIT, 0, texture.mip_levels, 0, 1});

Is the READ_BIT redundant in such cases, or am I missing something?

2

This was discussed on VulkanDocs, and the conclusion was READ in srcAccessMask is no-op. Such flags can be safely removed from srcAccessMask. I’ve opened an issue to clarify the spec.

3

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.