Synchronization issues reported by Vulkan Validation Layers

I'm a RADV developer who investigated https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33618#note_2797044. After enabling VVL (also export VK_LAYER_VALIDATE_SYNC=1) I found a few errors that probably explain the rendering issue.

SYNC-HAZARD-WRITE-AFTER-READ(ERROR / SPEC): msgNum: 929810911 - Validation Error: [ SYNC-HAZARD-WRITE-AFTER-READ ] Objects: VkQueue 0x71166410e780, VkCommandBuffer 0x711664442420 | MessageID = 0x376bc9df
vkQueueSubmit2(): WRITE_AFTER_READ hazard detected. vkCmdPipelineBarrier2[vk_tex_clear_ex] (from the secondary VkCommandBuffer 0x711664442420) writes to VkImage 0xd5b26f0000000010, which was previously read by vkAcquireNextImageKHR (submitted on VkQueue 0x71166410e780). 
The current synchronization waits at VK_PIPELINE_STAGE_2_BOTTOM_OF_PIPE_BIT|VK_PIPELINE_STAGE_2_CLEAR_BIT, but to prevent this hazard, it must wait at VK_PIPELINE_STAGE_2_NONE. An execution dependency is sufficient to prevent this hazard.
    Objects: 2
        [0] 0x71166410e780, type: 4, name: NULL
        [1] 0x711664442420, type: 6, name: NULL

SYNC-HAZARD-WRITE-AFTER-WRITE(ERROR / SPEC): msgNum: 1544472022 - Validation Error: [ SYNC-HAZARD-WRITE-AFTER-WRITE ] Objects: VkQueue 0x71166410e780, VkCommandBuffer 0x711664490610 | MessageID = 0x5c0ec5d6
vkQueueSubmit2(): WRITE_AFTER_WRITE hazard detected. vkCmdPipelineBarrier2[pl_vulkan_hold_ex] (from VkCommandBuffer 0x711664490610 submitted on the current VkQueue 0x711664231d40) writes to VkImage 0xd5b26f0000000010, which was previously written during an image layout transition initiated by another vkCmdPipelineBarrier2[vk_pass_run] command (from VkCommandBuffer 0x7116644811a0 submitted on VkQueue 0x71166410e780). 
No sufficient synchronization is present to ensure that a layout transition does not conflict with a prior layout transition.
    Objects: 2
        [0] 0x71166410e780, type: 4, name: NULL
        [1] 0x711664490610, type: 6, name: NULL

Looks like these are real issues that should be fixed. Tested with liplacebo (02f4f986) and with that RADV MR applied (which just uncovers the bug).

mentioned in commit haasn/libplacebo@e6382086

mentioned in merge request !688 (merged)

Can you verify that !688 (merged) fixes the issue?

It doesn't fix it and you still have a VVL error:

Validation Error: [ SYNC-HAZARD-WRITE-AFTER-WRITE ] | MessageID = 0x5c0ec5d6
vkQueueSubmit2(): WRITE_AFTER_WRITE hazard detected. vkCmdPipelineBarrier2[pl_vulkan_hold_ex] (from VkCommandBuffer 0x7fa4e4309520 submitted on the current VkQueue 0x7fa4e4231fe0) writes to VkImage 0xe7e6d0000000000f, which was previously written during an image layout transition initiated by another vkCmdPipelineBarrier2[vk_pass_run] command (from VkCommandBuffer 0x7fa4e43abdc0 submitted on VkQueue 0x7fa4e410e940). 
No sufficient synchronization is present to ensure that a layout transition does not conflict with a prior layout transition.
Objects: 2
    [0] VkQueue 0x7fa4e410e940
    [1] VkCommandBuffer 0x7fa4e4309520

Also,

Validation Error: [ SYNC-HAZARD-WRITE-AFTER-PRESENT ] | MessageID = 0x42f2f4ed
vkQueueSubmit2(): WRITE_AFTER_PRESENT hazard detected. vkCmdPipelineBarrier2[vk_pass_run] (from VkCommandBuffer 0x7fa4e425e740 submitted on the current VkQueue 0x7fa4e410e940) writes to VkImage 0x980f360000000011, which was previously written by vkQueuePresentKHR (submitted on VkQueue 0x7fa4e4232510). 
No sufficient synchronization is present to ensure that a layout transition does not conflict with a prior swapchain present operation.
Objects: 2
    [0] VkQueue 0x7fa4e4232510
    [1] VkCommandBuffer 0x7fa4e425e740

I see; it works inside libplacebo now but still errors when used via mpv.

I'll have to dig deeper into the issue; this error does not make much sense yet.

mentioned in commit haasn/libplacebo@fd01c75c

closed with merge request !688 (merged)

closed with commit fd01c75c

Did you update your MR since last time I checked?

reopened

Still broken with master (16ef0a26).

I only see validation errors now about the overlays. Are your issues related to overlays? Can you tests with mpv --no-config --gpu-api=vulkan --video-osd=no --script-opt=osc-visibility=never --sub-visibility=no --vo=gpu-next <file> to confirm?

No VVL errors with mpv --no-config --gpu-api=vulkan --video-osd=no --sub-visibility=no --vo=gpu-next, though --script-opt=osc-visibility=never is an unknown option here.

Do you know where the errors come from?

@kasper93 ping