Depth buffer missing or incorrect barriers in some cases.

[DGriffin91]

In my renderer, I sample the depth buffer as a texture. I've noticed that this seems to result in incorrect barriers. I've tried to make a more minimal example of the kind of thing I'm doing based on the multipass example. This is also based on #81

multipass.rs

In my renderer this seems to result in the depth buffer not being written to for some passes.

VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL
SYNC_FRAGMENT_SHADER_SHADER_SAMPLED_READ, prior_usage: SYNC_LATE_FRAGMENT_TESTS_DEPTH_STENCIL_ATTACHMENT_WRITE

VUID-VkImageMemoryBarrier-oldLayout-01197(ERROR / SPEC): msgNum: 307231540 - Validation Error: [ VUID-VkImageMemoryBarrier-oldLayout-01197 ] Object 0: handle = 0x18c31e421a0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0xea7170000000031, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x124ffb34 | vkCmdPipelineBarrier(): pImageMemoryBarriers[0].image (VkImage 0xea7170000000031[]) cannot transition the layout of aspect=2, level=0, layer=0 
from VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL. The Vulkan spec states: If srcQueueFamilyIndex and dstQueueFamilyIndex define 
a queue family ownership transfer or oldLayout and newLayout define an image layout transition, oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED or the current layout of the image subresources affected by the barrier (https://vulkan.lunarg.com/doc/view/1.3.280.0/windows/1.3-extensions/vkspec.html#VUID-VkImageMemoryBarrier-oldLayout-01197)
    Objects: 2
        [0] 0x18c31e421a0, type: 6, name: NULL
        [1] 0xea7170000000031, type: 10, name: NULL
VUID-vkCmdBeginRenderPass-initialLayout-00900(ERROR / SPEC): msgNum: -1246962192 - Validation Error: [ VUID-vkCmdBeginRenderPass-initialLayout-00900 ] Object 0: handle = 0x18c31e421a0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x210d07000000003a, type = VK_OBJECT_TYPE_RENDER_PASS; Object 2: handle = 0x89e60f0000000042, type = VK_OBJECT_TYPE_FRAMEBUFFER; Object 3: handle = 0xea7170000000031, type = VK_OBJECT_TYPE_IMAGE; Object 4: handle = 0x5eb05e000000003b, type = VK_OBJECT_TYPE_IMAGE_VIEW; | MessageID = 0xb5acddf0 | vkCmdBeginRenderPass(): pCreateInfo->pAttachments[1] You cannot start a render pass using attachment 1 where the render pass initial layout is VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_OPTIMAL and the previous known layout of the attachment is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL. The layouts must match, or the render pass initial layout for the attachment must be 
VK_IMAGE_LAYOUT_UNDEFINED. The Vulkan spec states: If the initialLayout member of any of the VkAttachmentDescription structures specified when creating the render pass specified in the renderPass member of pRenderPassBegin is not VK_IMAGE_LAYOUT_UNDEFINED, then each such initialLayout must be equal to the current layout of the corresponding attachment image subresource of the framebuffer specified in the framebuffer member of pRenderPassBegin (https://vulkan.lunarg.com/doc/view/1.3.280.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdBeginRenderPass-initialLayout-00900)
    Objects: 5
        [0] 0x18c31e421a0, type: 6, name: NULL
        [1] 0x210d07000000003a, type: 18, name: NULL
        [2] 0x89e60f0000000042, type: 24, name: NULL
        [3] 0xea7170000000031, type: 10, name: NULL
        [4] 0x5eb05e000000003b, type: 14, name: NULL
SYNC-HAZARD-READ-AFTER-WRITE(ERROR / SPEC): msgNum: -455515022 - Validation Error: [ SYNC-HAZARD-READ-AFTER-WRITE ] Object 0: handle = 0x5eb05e000000003b, type = VK_OBJECT_TYPE_IMAGE_VIEW; | MessageID = 0xe4d96472 | vkCmdDraw():  Hazard READ_AFTER_WRITE for VkImageView 0x5eb05e000000003b[], in VkCommandBuffer 0x18c31e421a0[], and VkPipeline 0x603cd90000000044[], VkDescriptorSet 0x944a2c0000000039[], type: VK_DESCRIPTOR_TYPE_COMBINED_IMAGE_SAMPLER, imageLayout: VK_IMAGE_LAYOUT_DEPTH_READ_ONLY_OPTIMAL, binding #0, index 0. Access info (usage: SYNC_FRAGMENT_SHADER_SHADER_SAMPLED_READ, prior_usage: SYNC_LATE_FRAGMENT_TESTS_DEPTH_STENCIL_ATTACHMENT_WRITE, write_barriers: 
0, command: vkCmdDrawIndexed, seq_no: 9, reset_no: 1).
    Objects: 1
        [0] 0x5eb05e000000003b, type: 14, name: NULL
VUID-vkAcquireNextImageKHR-semaphore-01779(ERROR / SPEC): msgNum: 1461184347 - Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0x3fbcd60000000028, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR():  Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://vulkan.lunarg.com/doc/view/1.3.280.0/windows/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779)
    Objects: 1
        [0] 0x3fbcd60000000028, type: 5, name: NULL

[attackgoat]

I ran into this recently with a depth pass and was able to resolve it by changing src/graph/resolver.rs:1971 to use the "late" access instead of "early":

let next_access = late.access;

I haven't thought very deeply about what else this might break, so I haven't pushed the fix up yet.

[DGriffin91]

So it looks like with that there is one less validation error, but the rest remain and depth still seems to not be written.

The validation error that goes away with let next_access = late.access;:

VUID-VkImageMemoryBarrier-oldLayout-01197(ERROR / SPEC): msgNum: 307231540 - Validation Error: [ VUID-VkImageMemoryBarrier-oldLayout-01197 ] Object 0: handle = 0x200555071f0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0xea7170000000031, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0x124ffb34 | vkCmdPipelineBarrier(): pImageMemoryBarriers[0].image (VkImage 0xea7170000000031[]) cannot transition the layout 
of aspect=2, level=0, layer=0 from VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_OPTIMAL when the previous known layout is VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL. The Vulkan spec states: If srcQueueFamilyIndex and dstQueueFamilyIndex define a queue family ownership transfer or oldLayout and newLayout define an image layout transition, oldLayout must be VK_IMAGE_LAYOUT_UNDEFINED or the current layout of 
the image subresources affected by the barrier (https://vulkan.lunarg.com/doc/view/1.3.280.0/windows/1.3-extensions/vkspec.html#VUID-VkImageMemoryBarrier-oldLayout-01197)

[DGriffin91]

I updated #81 to also check depth both ways and a couple other small changes and now the depth seems to be written/read correctly.

I still get one depth related validation error:

VUID-vkCmdBeginRenderPass-initialLayout-00900(ERROR / SPEC): msgNum: -1246962192 - Validation Error: [ VUID-vkCmdBeginRenderPass-initialLayout-00900 ] Object 0: handle = 0x24a6b5e2c80, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0x92c9c400000001ea, type = VK_OBJECT_TYPE_RENDER_PASS; Object 2: handle = 0x2cebe2000000020e, type = VK_OBJECT_TYPE_FRAMEBUFFER; Object 3: handle = 0xad25e500000001ad, type = VK_OBJECT_TYPE_IMAGE; Object 4: handle = 0xb64ded0000000200, type = VK_OBJECT_TYPE_IMAGE_VIEW; | MessageID = 0xb5acddf0 | vkCmdBeginRenderPass(): pCreateInfo->pAttachments[1] You cannot start a render pass using attachment 1 where the render pass initial layout is VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_OPTIMAL and the previous known layout of the attachment is VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL. The layouts must match, or the render pass initial layout for the attachment must be VK_IMAGE_LAYOUT_UNDEFINED. The Vulkan spec states: If the initialLayout member of any of the VkAttachmentDescription structures specified when creating the render pass specified in the renderPass member of pRenderPassBegin is not VK_IMAGE_LAYOUT_UNDEFINED, then each such initialLayout must be equal to the current layout of the corresponding attachment image subresource of the framebuffer specified in the framebuffer member of pRenderPassBegin (https://vulkan.lunarg.com/doc/view/1.3.280.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdBeginRenderPass-initialLayout-00900)

If I use let next_access = late.access; then the above error goes away and I but get a new one:

SYNC-HAZARD-READ-AFTER-WRITE(ERROR / SPEC): msgNum: -455515022 - Validation Error: [ SYNC-HAZARD-READ-AFTER-WRITE ] Object 0: handle = 0x45d6d1000000004c, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0xe4d96472 | vkCmdBeginRenderPass():  Hazard READ_AFTER_WRITE in subpass 0 for attachment 0 aspect color during load with loadOp VK_ATTACHMENT_LOAD_OP_LOAD. Access info (usage: SYNC_COLOR_ATTACHMENT_OUTPUT_COLOR_ATTACHMENT_READ, prior_usage: SYNC_IMAGE_LAYOUT_TRANSITION, write_barriers: SYNC_COLOR_ATTACHMENT_OUTPUT_COLOR_ATTACHMENT_WRITE, command: vkCmdPipelineBarrier, seq_no: 3, VkImage 0x908683000000001d[], VkImage 0xab64de0000000020[], VkImage 0x2cfba2000000001c[], reset_no: 1).

[attackgoat]

The logic in #89 may be the correct fix for this case. If possible, could you test against this branch?

[DGriffin91]

@attackgoat It looks like I get the same series of validation errors (and then device lost) on this pr as on main.

VUID-VkAttachmentDescription2-format-09332(ERROR / SPEC): msgNum: 1728109804 - Validation Error: [ VUID-VkAttachmentDescription2-format-09332 ] | MessageID = 0x6700dcec | vkCreateRenderPass2(): pCreateInfo->pAttachments[0].format is VK_FORMAT_UNDEFINED.
The Vulkan spec states: If externalFormatResolve is not enabled, format must not be VK_FORMAT_UNDEFINED (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkAttachmentDescription2-format-09332)
VUID-VkAttachmentDescription2-finalLayout-00843(ERROR / SPEC): msgNum: -468539520 - Validation Error: [ VUID-VkAttachmentDescription2-finalLayout-00843 ] | MessageID = 0xe412a780 | vkCreateRenderPass2(): pCreateInfo->pAttachments[1].finalLayout is VK_IMAGE_LAYOUT_UNDEFINED.
The Vulkan spec states: finalLayout must not be VK_IMAGE_LAYOUT_UNDEFINED or VK_IMAGE_LAYOUT_PREINITIALIZED (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkAttachmentDescription2-finalLayout-00843)
VUID-VkSubpassDescription2-pDepthStencilAttachment-02900(ERROR / SPEC): msgNum: 1872834363 - Validation Error: [ VUID-VkSubpassDescription2-pDepthStencilAttachment-02900 ] | MessageID = 0x6fa12f3b | vkCreateRenderPass2(): pCreateInfo->pAttachments[1].format (VK_FORMAT_UNDEFINED) format features are VkFormatFeatureFlags2(0) (referenced by pCreateInfo->pSubpasses[1].pDepthStencilAttachment).
The Vulkan spec states: If pDepthStencilAttachment is not NULL and the attachment is not VK_ATTACHMENT_UNUSED then it must have an image format whose potential format features contain VK_FORMAT_FEATURE_DEPTH_STENCIL_ATTACHMENT_BIT (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkSubpassDescription2-pDepthStencilAttachment-02900)
VUID-VkFramebufferCreateInfo-width-00886(ERROR / SPEC): msgNum: 683787591 - Validation Error: [ VUID-VkFramebufferCreateInfo-width-00886 ] | MessageID = 0x28c1c547 | vkCreateFramebuffer(): pCreateInfo->width (4294967295) exceeds physical device limits (32768).
The Vulkan spec states: width must be less than or equal to maxFramebufferWidth (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkFramebufferCreateInfo-width-00886)
VUID-VkFramebufferCreateInfo-height-00888(ERROR / SPEC): msgNum: 1131526661 - Validation Error: [ VUID-VkFramebufferCreateInfo-height-00888 ] | MessageID = 0x4371ba05 | vkCreateFramebuffer(): pCreateInfo->height (4294967295) exceeds physical device limits (32768).
The Vulkan spec states: height must be less than or equal to maxFramebufferHeight (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkFramebufferCreateInfo-height-00888)
VUID-VkFramebufferCreateInfo-flags-03205(ERROR / SPEC): msgNum: -2007720704 - Validation Error: [ VUID-VkFramebufferCreateInfo-flags-03205 ] Object 0: handle = 0x2b424a0000000034, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0x88549d00 | vkCreateFramebuffer(): pCreateInfo->pNext<VkFramebufferAttachmentsCreateInfo>.pAttachmentImageInfos[0].pViewFormats does not include format VK_FORMAT_UNDEFINED used by the corresponding attachment for renderPass (VkRenderPass 0x2b424a0000000034[]).
The Vulkan spec states: If flags includes VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT, at least one element of the pViewFormats member of any element of the pAttachmentImageInfos member of a VkFramebufferAttachmentsCreateInfo structure included in the pNext chain must be equal to the corresponding value of VkAttachmentDescription::format used to create renderPass (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkFramebufferCreateInfo-flags-03205)
    Objects: 1
        [0] 0x2b424a0000000034, type: 18, name: NULL
VUID-VkFramebufferCreateInfo-flags-04541(ERROR / SPEC): msgNum: -76383122 - Validation Error: [ VUID-VkFramebufferCreateInfo-flags-04541 ] Object 0: handle = 0x2b424a0000000034, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0xfb727c6e | vkCreateFramebuffer(): pCreateInfo->pAttachments[0] has a width of only 800, but framebuffer has a width of 4294967295.
The Vulkan spec states: If flags includes VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT, the width member of any element of the pAttachmentImageInfos member of a VkFramebufferAttachmentsCreateInfo structure in the pNext chain that is used as an input, color, resolve or depth/stencil attachment in renderPass must be greater than or equal to width (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkFramebufferCreateInfo-flags-04541)
    Objects: 1
        [0] 0x2b424a0000000034, type: 18, name: NULL
VUID-VkFramebufferCreateInfo-flags-04542(ERROR / SPEC): msgNum: -1189072919 - Validation Error: [ VUID-VkFramebufferCreateInfo-flags-04542 ] Object 0: handle = 0x2b424a0000000034, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0xb9202fe9 | vkCreateFramebuffer(): pCreateInfo->pAttachments[0] has a height of only 600, but framebuffer has a height of 4294967295.
The Vulkan spec states: If flags includes VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT, the height member of any element of the pAttachmentImageInfos member of a VkFramebufferAttachmentsCreateInfo structure in the pNext chain that is used as an input, color, resolve or depth/stencil attachment in renderPass must be greater than or equal to height (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkFramebufferCreateInfo-flags-04542)
    Objects: 1
        [0] 0x2b424a0000000034, type: 18, name: NULL
VUID-VkRenderPassBeginInfo-framebuffer-03216(ERROR / SPEC): msgNum: -1519791923 - Validation Error: [ VUID-VkRenderPassBeginInfo-framebuffer-03216 ] Object 0: handle = 0x2b424a0000000034, type = VK_OBJECT_TYPE_RENDER_PASS; Object 1: handle = 0x9f9b41000000003c, type = VK_OBJECT_TYPE_FRAMEBUFFER; Object 2: handle = 0x944a2c0000000039, type = VK_OBJECT_TYPE_IMAGE_VIEW; Object 3: handle = 0xa2eb680000000026, type = VK_OBJECT_TYPE_IMAGE; | MessageID = 0xa569d0cd | vkCmdBeginRenderPass(): pRenderPassBegin->pNext<VkRenderPassAttachmentBeginInfo>.pAttachments[0].format is VK_FORMAT_B8G8R8A8_UNORM, but the VkRenderPass was created with a pAttachments[0].format of VK_FORMAT_UNDEFINED.
The Vulkan spec states: If framebuffer was created with a VkFramebufferCreateInfo::flags value that included VK_FRAMEBUFFER_CREATE_IMAGELESS_BIT, each element of the pAttachments member of a VkRenderPassAttachmentBeginInfo structure included in the pNext chain must be a VkImageView of an image created with a value of VkImageViewCreateInfo::format equal to the corresponding value of VkAttachmentDescription::format in renderPass (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkRenderPassBeginInfo-framebuffer-03216)
    Objects: 4
        [0] 0x2b424a0000000034, type: 18, name: NULL
        [1] 0x9f9b41000000003c, type: 24, name: NULL
        [2] 0x944a2c0000000039, type: 14, name: NULL
        [3] 0xa2eb680000000026, type: 10, name: NULL
VUID-VkViewport-width-01771(ERROR / SPEC): msgNum: 1097903316 - Validation Error: [ VUID-VkViewport-width-01771 ] Object 0: handle = 0x2600c4c57a0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x4170acd4 | vkCmdSetViewport(): pViewports[0].width (4294967296.000000) exceeds VkPhysicalDeviceLimits::maxViewportDimensions[0] (32768).
The Vulkan spec states: width must be less than or equal to VkPhysicalDeviceLimits::maxViewportDimensions[0] (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkViewport-width-01771)
    Objects: 1
        [0] 0x2600c4c57a0, type: 6, name: NULL
VUID-VkViewport-height-01773(ERROR / SPEC): msgNum: -1548099769 - Validation Error: [ VUID-VkViewport-height-01773 ] Object 0: handle = 0x2600c4c57a0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0xa3b9df47 | vkCmdSetViewport(): pViewports[0].height absolute value (4294967296.000000) exceeds VkPhysicalDeviceLimits::maxViewportDimensions[1] (32768).
The Vulkan spec states: The absolute value of height must be less than or equal to VkPhysicalDeviceLimits::maxViewportDimensions[1] (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-VkViewport-height-01773)
    Objects: 1
        [0] 0x2600c4c57a0, type: 6, name: NULL
VUID-vkCmdSetScissor-offset-00596(ERROR / SPEC): msgNum: -1590826638 - Validation Error: [ VUID-vkCmdSetScissor-offset-00596 ] Object 0: handle = 0x2600c4c57a0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0xa12de972 | vkCmdSetScissor(): pScissors[0] offset.x (0) + extent.width (4294967295) is 4294967295 which will overflow int32_t.
The Vulkan spec states: Evaluation of (offset.x + extent.width) must not cause a signed integer addition overflow for any element of pScissors (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdSetScissor-offset-00596)
    Objects: 1
        [0] 0x2600c4c57a0, type: 6, name: NULL
VUID-vkCmdSetScissor-offset-00597(ERROR / SPEC): msgNum: 719760766 - Validation Error: [ VUID-vkCmdSetScissor-offset-00597 ] Object 0: handle = 0x2600c4c57a0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x2ae6ad7e | vkCmdSetScissor(): pScissors[0] offset.y (0) + extent.height (4294967295) is 4294967295 which will overflow int32_t.
The Vulkan spec states: Evaluation of (offset.y + extent.height) must not cause a signed integer addition overflow for any element of pScissors (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdSetScissor-offset-00597)
    Objects: 1
        [0] 0x2600c4c57a0, type: 6, name: NULL
VUID-vkCmdDrawIndexed-maintenance4-08602(ERROR / SPEC): msgNum: 1055782659 - Validation Error: [ VUID-vkCmdDrawIndexed-maintenance4-08602 ] Object 0: handle = 0x2600c4c57a0, type = VK_OBJECT_TYPE_COMMAND_BUFFER; Object 1: handle = 0xf443490000000006, type = VK_OBJECT_TYPE_PIPELINE_LAYOUT; Object 2: handle = 0x59ffe0000000003d, type = VK_OBJECT_TYPE_PIPELINE; | MessageID = 0x3eedf703 | vkCmdDrawIndexed():  Shader in VK_SHADER_STAGE_VERTEX_BIT uses push-constant statically but vkCmdPushConstants was not called yet for pipeline layout VkPipelineLayout 0xf443490000000006[].
The Vulkan spec states: If the maintenance4 feature is not enabled, then for each push constant that is statically used by a bound shader, a push constant value must have been set for the same pipeline bind point, with a VkPipelineLayout that is compatible for push constants, with the VkPipelineLayout used to create the current VkPipeline or the VkDescriptorSetLayout and VkPushConstantRange arrays used to create the current VkShaderEXT , as described in Pipeline Layout Compatibility (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-vkCmdDrawIndexed-maintenance4-08602)
    Objects: 3
        [0] 0x2600c4c57a0, type: 6, name: NULL
        [1] 0xf443490000000006, type: 17, name: NULL
        [2] 0x59ffe0000000003d, type: 19, name: NULL
SYNC-HAZARD-WRITE-AFTER-WRITE(ERROR / SPEC): msgNum: 1544472022 - Validation Error: [ SYNC-HAZARD-WRITE-AFTER-WRITE ] Object 0: handle = 0x2723ba0000000037, type = VK_OBJECT_TYPE_RENDER_PASS; | MessageID = 0x5c0ec5d6 | vkCmdNextSubpass():  Hazard WRITE_AFTER_WRITE vs. layout transition in subpass 1 for attachment 1 aspect color during load with loadOp VK_ATTACHMENT_LOAD_OP_DONT_CARE.
    Objects: 1
        [0] 0x2723ba0000000037, type: 18, name: NULL
 ERROR screen_13::driver::device > Device lost
 ERROR screen_13::driver::device > Device lost
 ERROR screen_13::driver::device > Device lost
 ERROR screen_13::driver::device > Device lost
 ERROR screen_13::driver::device > Device lost
 ERROR screen_13::driver::device > Device lost
 ERROR screen_13::driver::device > Device lost
VUID-vkDestroyDevice-device-05137(ERROR / SPEC): msgNum: 1215490720 - Validation Error: [ VUID-vkDestroyDevice-device-05137 ] Object 0: handle = 0x2600c3ea720, type = VK_OBJECT_TYPE_COMMAND_BUFFER; | MessageID = 0x4872eaa0 | vkDestroyDevice():  OBJ ERROR : For VkDevice 0x2606cdde640[], VkCommandBuffer 0x2600c3ea720[] has not been destroyed.
The Vulkan spec states: All child objects created on device must have been destroyed prior to destroying device (https://vulkan.lunarg.com/doc/view/1.3.296.0/windows/1.3-extensions/vkspec.html#VUID-vkDestroyDevice-device-05137)
    Objects: 1
        [0] 0x2600c3ea720, type: 6, name: NULL

I've updated the my version of the multipass example so it runs on current screen-13: multipass.zip

Unfortunately I don't have time to look into this more right now but hopefully will not this coming week but the one after.