Incorrect SYNC-HAZARD-WRITE-AFTER-READ error with vkCmdPipelineBarrier2 applied to suballocated buffers

[HuYuxin]

Environment:

• OS: Linux
• GPU and driver version: NVIDIA, Driver Version: 535.183.01. Vulkan Instance Version: 1.3.283
• SDK or header version if building from repo: 2d73636
• Options enabled (synchronization, best practices, etc.):

Describe the Issue

To reproduce:

1. Sync latest ANGLE: https://github.com/google/angle
2. Cherry-pick these two changes:
   https://chromium-review.googlesource.com/c/angle/angle/+/5832709/4 (patchset 4)
   https://chromium-review.googlesource.com/c/angle/angle/+/5832710/10 (patchset 10)
3. Set below gn args gn args out/LinuxDebug

dcheck_always_on = true
is_component_build = true
is_debug = false
symbol_level = 1
angle_enable_cl=true

4. Compile with command autoninja -C out/LinuxDebug angle_end2end_tests
5. Run test with command out/LinuxDebug/angle_end2end_tests --gtest_filter="LineLoopIndirectTest.UShortIndexIndirectBuffer/ES3_1_Vulkan" --verbose --local-output

Observe that the test failed with this validation error:

[ SYNC-HAZARD-WRITE-AFTER-READ ] Validation Error: [ SYNC-HAZARD-WRITE-AFTER-READ ] Object 0: handle = 0x5557db026030, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x200000000020, type = VK_OBJECT_TYPE_BUFFER; | MessageID = 0x376bc9df | vkCmdCopyImageToBuffer():  Hazard WRITE_AFTER_READ for dstBuffer VkBuffer 0x200000000020[], region 0. Access info (usage: SYNC_COPY_TRANSFER_WRITE, prior_usage: SYNC_INDEX_INPUT_INDEX_READ, read_barriers: VK_PIPELINE_STAGE_2_BOTTOM_OF_PIPE_BIT, command: vkCmdDrawIndexedIndirect, seq_no: 8, reset_no: 3, resource: VkBuffer 0x200000000020[]).

Expected behavior

Test should pass without the SYNC-HAZARD-WRITE-AFTER-READ validation error.

Valid Usage ID
If applicable, please include the validation messages encountered leading up to the issue

[ SYNC-HAZARD-WRITE-AFTER-READ ] Validation Error: [ SYNC-HAZARD-WRITE-AFTER-READ ] Object 0: handle = 0x5557db026030, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x200000000020, type = VK_OBJECT_TYPE_BUFFER; | MessageID = 0x376bc9df | vkCmdCopyImageToBuffer():  Hazard WRITE_AFTER_READ for dstBuffer VkBuffer 0x200000000020[], region 0. Access info (usage: SYNC_COPY_TRANSFER_WRITE, prior_usage: SYNC_INDEX_INPUT_INDEX_READ, read_barriers: VK_PIPELINE_STAGE_2_BOTTOM_OF_PIPE_BIT, command: vkCmdDrawIndexedIndirect, seq_no: 8, reset_no: 3, resource: VkBuffer 0x200000000020[]).

Additional context

The renderdoc capture shows that VVL thinks there is a missing execution barrier on the VkBuffer:

VkBuffer used as index buffer for vkCmdDrawIndexed()
--- VVL thinks there is a missing execution barrier---
VkBuffer used as dest buffer for vkCmdCopyImageToBuffer()

However, the two buffers are suballocated. Even they belong to the same big VkBuffer, they are actually pointing to different memories.

We think that using VK_KHR_Synchronization2 exposed this issue in VVL. Before we use VK_KHR_Synchronization2, the srcStageMask and dstStageMask are shared between VkMemoryBarrier, VkBufferMemoryBarier, and VkImageMemoryBarrier. in the vkCmdPipelineBarrier () call. Between the vkCmdDrawIndex() and vkCmdCopyImageToBuffer(), even if only image barrier is needed, the srcStageMask and dstStageMask values also apply to the VkMemoryBarrier and VkBufferMemoryBarrier, and it fulfills VVL's validation on buffer execution barrier (even there is no execution barrier needed on buffer because they are suballocated and point to different memories). After switching to VK_KHR_Synchronization2, the srcStageMask and dstStageMask are packed within the VkMemoryBarrier2, VkBufferMemoryBarier2, VkImageMemoryBarrier2. So now if VkMemoryBarrier2 is null, there is no execution barrier applied to VkBuffer, and VVL incorrectly thinks that there is a missing execution barrier on the buffer.

[ShabbyX]

There's likely some relationship with #3605

Basically, the range of a buffer resource is not taken into account in syncval (it seems)

[artem-lunarg]

I wonder if #3605 was fixed by #8141, we indeed did not compute offsets correctly for dynamic descriptors (but I did not look closely at these issues yet, so could be a wrong suggestion). This issue should be something different because it is based on the latest code.

[ShabbyX]

I wonder if #3605 was fixed by #8141, we indeed did not compute offsets correctly for dynamic descriptors (but I did not look closely at these issues yet, so could be a wrong suggestion). This issue should be something different because it is based on the latest code.

Yes, looks like the dynamic offset part is fixed: https://chromium-review.googlesource.com/c/angle/angle/+/5873529

We're still getting false positives because the vertex buffer ranges are not taken into account (it seems)