Hello Chris,

Thanks for the careful and detailed PR.
It's going to be a little hard for me to parse that whole repro, and I don't understand much of Vulkan. My observation is that I don't get the issue on stock examples. I would appreciate a repro based on stock examples, if that's feasible, because this is going to be more self-explanatory in term of narrowing the cause, and would be information we can rely on for years as if we frequently come back on those issues.

Right now if I try to enable dynamic rendering using this patch + grab the whole VulkanValidationSettings block from your code, I do get a bunch of
SYNC-HAZARD-WRITE-AFTER-READ errors regardless of using multi-viewports.

[vulkan] Debug report from ObjectType: 4
Message: Validation Error: [ SYNC-HAZARD-WRITE-AFTER-READ ] Object 0: handle = 0x1a86a8cdc20, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0x376bc9df | vkQueueSubmit():  Hazard WRITE_AFTER_READ for entry 0, VkCommandBuffer 0x1a86d1d80b0[], Submitted access info (submitted_usage: SYNC_IMAGE_LAYOUT_TRANSITION, command: vkCmdPipelineBarrier, seq_no: 1, reset_no: 308). Access info (prior_usage: SYNC_PRESENT_ENGINE_SYNCVAL_PRESENT_ACQUIRE_READ_SYNCVAL, read_barriers: VK_PIPELINE_STAGE_2_COLOR_ATTACHMENT_OUTPUT_BIT|VK_PIPELINE_STAGE_2_BOTTOM_OF_PIPE_BIT, , batch_tag: 3672, vkAcquireNextImageKHR aquire_tag:3672: VkSwapchainKHR 0xf56c9b0000000004[], image_index: 0image: VkImage 0xe7f79a0000000005[]).

SYNC-HAZARD-WRITE-AFTER-READ(ERROR / SPEC): msgNum: 929810911 - Validation Error: [ SYNC-HAZARD-WRITE-AFTER-READ ] Object 0: handle = 0x1a86a8cdc20, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0x376bc9df | vkQueueSubmit():  Hazard WRITE_AFTER_READ for entry 0, VkCommandBuffer 0x1a86d1deb80[], Submitted access info (submitted_usage: SYNC_IMAGE_LAYOUT_TRANSITION, command: vkCmdPipelineBarrier, seq_no: 1, reset_no: 308). Access info (prior_usage: SYNC_PRESENT_ENGINE_SYNCVAL_PRESENT_ACQUIRE_READ_SYNCVAL, read_barriers: VK_PIPELINE_STAGE_2_COLOR_ATTACHMENT_OUTPUT_BIT|VK_PIPELINE_STAGE_2_BOTTOM_OF_PIPE_BIT, , batch_tag: 3684, vkAcquireNextImageKHR aquire_tag:3684: VkSwapchainKHR 0xf56c9b0000000004[], image_index: 1image: VkImage 0xf443490000000006[]).
    Objects: 1
        [0] 0x1a86a8cdc20, type: 4, name: NULL

And they don't go away with your patch. So I am hardly even able to look at the primary issue #8176.

This is generally so utterly confusing to me that, given the much appreciated meticulousness of your PR, I'm tempted to trust you and merge and see what other reports come next from users, but it would be great if I could repro something locally and on a known test bed.

Hello Omar,
Thanks for your reply.

I’ve created a patch (from my fork, branch fix/vulkan-validation-error-pipeline-barrier) where I updated both the glfw_vulkan and sdl3_vulkan examples to test the fix.
PR-8600_imgui_examples_and_fix_impl_vulkan.patch

While working on it, I encountered issues with dynamic rendering function loading. Specifically, dynamic rendering functions are currently loaded using vkGetInstanceProcAddr, but since functions like vkCmdXXXX are device-level commands, they must be loaded using vkGetDeviceProcAddr.

Current (incorrect) line:
ImGui_ImplVulkan_LoadDynamicRenderingFunctions(info->ApiVersion, [](const char* function_name, void* user_data) { return vkGetInstanceProcAddr((VkInstance)user_data, function_name); }, (void*)info->Instance);

Correct version:
ImGui_ImplVulkan_LoadDynamicRenderingFunctions(info->ApiVersion, [](const char* function_name, void* user_data) { return vkGetDeviceProcAddr((VkDevice)user_data, function_name); }, (void*)info->Device);

I also encountered a problem related to layout transitions i added. Since the examples use ImGui_ImplVulkanH_* methods (which aren’t typically used in end-users code), the ImGui_ImplVulkan_Data and InitInfo I relied on weren’t always available (this should never happen if end-users don't use these helpers' functions). So, to avoid any possible issue, I moved the transition logic into ImGui_ImplVulkanH_CreateOrResizeWindow, where we have access to a queue family and can get a queue for command submission.

All these changes are included in the patch to test in the examples.

Thank you Christian for the thoughful and useful amount of details!
I've merged the loading parts now : d1dc2a3 and will look at the rest later.

Thank you Christian. I have merged this as bbc89b6 (part thats in master) + 37fba4b.

Thanks a lot for the careful amount of details and repro, this is very much appreciated and useful.

Happy to have contributed!
Dear ImGui it's really a great project. keep up the good work!