Encountering several vulkan validation errors (including some sync hazards) with dlss_g

I am encountering these validation errors in my streamline integration with frame gen turned on.

Most of these are happening in the streamline sample as well.

I could not find a way to debug these further, because they happen via dlss_g.

They don't seem safe to ignore (especially the sync hazards).

There is a continous spew of most of these, but you have to turn on sync validation as well as disable the duplicate message limit (the default is 10 in the vulkan sdk)

   // if validation is enabled, enable sync validation as well
    VkValidationFeatureEnableEXT enables[] = { VK_VALIDATION_FEATURE_ENABLE_SYNCHRONIZATION_VALIDATION_EXT };
    VkValidationFeaturesEXT features = {};
    features.sType = VK_STRUCTURE_TYPE_VALIDATION_FEATURES_EXT;
    features.enabledValidationFeatureCount = 1;
    features.pEnabledValidationFeatures = enables;

    const VkBool32 enable_message_limit = false;

    const VkLayerSettingEXT settings[] =
    {
        {"VK_LAYER_KHRONOS_validation", "enable_message_limit", VK_LAYER_SETTING_TYPE_BOOL32_EXT, 1, &enable_message_limit }
    };

    const VkLayerSettingsCreateInfoEXT layerSettingsCreateInfo = {
    VK_STRUCTURE_TYPE_LAYER_SETTINGS_CREATE_INFO_EXT, nullptr,
    static_cast<uint32_t>(std::size(settings)), settings };
    features.pNext = &layerSettingsCreateInfo;
	if (m_EnableValidationLayers) {
		t_CreateInfo.enabledLayerCount = m_ValidationLayerUsed.getNum();
		t_CreateInfo.ppEnabledLayerNames = m_ValidationLayerUsed.getNum() ? m_ValidationLayerUsed.getDataPtr() : NULL;
		t_CreateInfo.pNext = &features;
	}
	else {
		t_CreateInfo.enabledLayerCount = 0;
	}

	VkResult res = vkCreateInstance(&t_CreateInfo, NULL, &m_Instance);

1.
[12-01-45][streamline][warn][tid:39628][23s:666ms:220us]vulkan.cpp:976[debugUtilsMessengerCallback] vkQueueSubmit2(): pSubmits[0].pCommandBufferInfos[0].commandBuffer command buffer VkCommandBuffer 0x20ac251140 expects VkImage 0x1ab00000001ab[sl.dlssg.fake-swapchain-buffer] (subresource: aspectMask = VK_IMAGE_ASPECT_COLOR_BIT, mipLevel = 0, arrayLayer = 0) to be in layout VK_IMAGE_LAYOUT_PRESENT_SRC_KHR--instead, current layout is VK_IMAGE_LAYOUT_GENERAL.
The Vulkan spec states: If a descriptor with type equal to any of VK_DESCRIPTOR_TYPE_SAMPLE_WEIGHT_IMAGE_QCOM, VK_DESCRIPTOR_TYPE_BLOCK_MATCH_IMAGE_QCOM, VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE, VK_DESCRIPTOR_TYPE_STORAGE_IMAGE, or VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT is accessed as a result of this command, all image subresources identified by that descriptor must be in the image layout identified when the descriptor was written (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/drawing.html#VUID-vkCmdDraw-None-09600)

2.						
[12-50-51][streamline][warn][tid:38748][30s:832ms:613us]vulkan.cpp:1027[debugUtilsMessengerCallback] vkCmdClearColorImage(): WRITE_AFTER_WRITE hazard detected. vkCmdClearColorImage writes to VkImage 0x27b200000027b2, which was previously written during an image layout transition initiated by vkCmdPipelineBarrier.
The current synchronization allows VK_ACCESS_2_SHADER_READ_BIT|VK_ACCESS_2_SHADER_STORAGE_WRITE_BIT accesses at VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT, but to prevent this hazard, it must allow VK_ACCESS_2_TRANSFER_WRITE_BIT accesses at VK_PIPELINE_STAGE_2_CLEAR_BIT.
Image clear subresource range 0: {
aspectMask = VK_IMAGE_ASPECT_COLOR_BIT, baseMipLevel = 0, levelCount = 1, baseArrayLayer = 0, layerCount = 1
}

3.
[12-52-44][streamline][warn][tid:37772][32s:766ms:864us]vulkan.cpp:1008[debugUtilsMessengerCallback] vkCmdCopyImage(): READ_AFTER_WRITE hazard detected. vkCmdCopyImage reads VkImage 0x1a800000001a8[sl.dlssg.fake-swapchain-buffer], which was previously written during an image layout transition initiated by vkCmdPipelineBarrier.
The current synchronization allows VK_ACCESS_2_SHADER_READ_BIT|VK_ACCESS_2_SHADER_STORAGE_WRITE_BIT accesses at VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT, but to prevent this hazard, it must allow VK_ACCESS_2_TRANSFER_READ_BIT accesses at VK_PIPELINE_STAGE_2_COPY_BIT.
Image copy region 0: {
  offset = {x = 0, y = 0, z = 0},
  extent = {width = 2560, height = 1600, depth = 1},
  subresource = {aspectMask = VK_IMAGE_ASPECT_COLOR_BIT, mipLevel = 0, baseArrayLayer = 0, layerCount = 1}
}

4.
[12-55-48][streamline][warn][tid:16420][30s:871ms:897us]vulkan.cpp:1017[debugUtilsMessengerCallback] vkCmdCopyImage(): WRITE_AFTER_WRITE hazard detected. vkCmdCopyImage writes to VkImage 0x319e000000319e[m_pDLFGOutputs], which was previously written during an image layout transition initiated by vkCmdPipelineBarrier.
The current synchronization allows VK_ACCESS_2_SHADER_READ_BIT|VK_ACCESS_2_SHADER_STORAGE_WRITE_BIT accesses at VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT, but to prevent this hazard, it must allow VK_ACCESS_2_TRANSFER_WRITE_BIT accesses at VK_PIPELINE_STAGE_2_COPY_BIT.
Image copy region 0: {
  offset = {x = 0, y = 0, z = 0},
  extent = {width = 2560, height = 1600, depth = 1},
  subresource = {aspectMask = VK_IMAGE_ASPECT_COLOR_BIT, mipLevel = 0, baseArrayLayer = 0, layerCount = 1}
}

5.
[14-36-36][streamline][warn][tid:35196][43s:509ms:714us]vulkan.cpp:1036[debugUtilsMessengerCallback] vkCmdPipelineBarrier(): WRITE_AFTER_WRITE hazard detected. vkCmdPipelineBarrier performs image layout transition on the VkImage 0x21d400000021d4[m_pDLFGOutputs], which was previously written by vkCmdCopyImage.
No sufficient synchronization is present to ensure that a layout transition does not conflict with a prior write (VK_ACCESS_2_TRANSFER_WRITE_BIT) at VK_PIPELINE_STAGE_2_COPY_BIT.
pImageMemoryBarriers[0]: {
  source accesses = VK_ACCESS_2_SHADER_READ_BIT|VK_ACCESS_2_SHADER_STORAGE_WRITE_BIT accesses at VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT,
  destination accesses = VK_ACCESS_2_SHADER_READ_BIT|VK_ACCESS_2_SHADER_STORAGE_WRITE_BIT accesses at VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT,
  srcStageMask = VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
  dstStageMask = VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
}

6.
[12-59-42][streamline][warn][tid:25408][52s:632ms:403us]vulkan.cpp:1026[debugUtilsMessengerCallback] vkCmdFillBuffer(): WRITE_AFTER_WRITE hazard detected. vkCmdFillBuffer writes to dstBuffer VkBuffer 0x33270000003327, which was previously written by another vkCmdFillBuffer command.
No sufficient synchronization is present to ensure that a write (VK_ACCESS_2_TRANSFER_WRITE_BIT) at VK_PIPELINE_STAGE_2_CLEAR_BIT does not conflict with a prior write of the same type at the same stage.
Buffer access region: {
  offset = 0
  size = 8192000
}

7.
[14-40-13][streamline][warn][tid:24000][29s:239ms:167us]vulkan.cpp:1045[debugUtilsMessengerCallback] vkQueueSubmit(): pSubmits[0].pSignalSemaphores[1] (VkSemaphore 0x17c000000017c[SL_present_semaphore]) is being signaled by VkQueue 0x5bd45880, but it may still be in use by VkSwapchainKHR 0x19e000000019e.
Here are the most recently acquired image indices: 0, 0, 0, 0, 0, 0, [0], 1.
(brackets mark the last use of VkSemaphore 0x17c000000017c[SL_present_semaphore] in a presentation operation)
Swapchain image 0 was presented but was not re-acquired, so VkSemaphore 0x17c000000017c[SL_present_semaphore] may still be in use and cannot be safely reused with image index 1.
Vulkan insight: One solution is to assign each image its own semaphore. Here are some common methods to ensure that a semaphore passed to vkQueuePresentKHR is not in use and can be safely reused:
		a) Use a separate semaphore per swapchain image. Index these semaphores using the index of the acquired image.
		b) Consider the VK_EXT_swapchain_maintenance1 extension. It allows using a VkFence with the presentation operation.
The Vulkan spec states: Each binary semaphore element of the pSignalSemaphores member of any element of pSubmits must be unsignaled when the semaphore signal operation it defines is executed on the device (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkQueueSubmit-pSignalSemaphores-00067)

8.
[14-44-47][streamline][warn][tid:7820][40s:069ms:355us]vulkan.cpp:1052[debugUtilsMessengerCallback] vkQueueSubmit(): pSubmits[0].pCommandBuffers[0] command buffer VkCommandBuffer 0x209e423bd0[dlssg.pacer_command_buffer] expects VkImage 0x3c590000003c59[m_pDLFGOutputs] (subresource: aspectMask = VK_IMAGE_ASPECT_COLOR_BIT, mipLevel = 0, arrayLayer = 0) to be in layout VK_IMAGE_LAYOUT_GENERAL--instead, current layout is VK_IMAGE_LAYOUT_UNDEFINED.
The Vulkan spec states: If a descriptor with type equal to any of VK_DESCRIPTOR_TYPE_SAMPLE_WEIGHT_IMAGE_QCOM, VK_DESCRIPTOR_TYPE_BLOCK_MATCH_IMAGE_QCOM, VK_DESCRIPTOR_TYPE_SAMPLED_IMAGE, VK_DESCRIPTOR_TYPE_STORAGE_IMAGE, or VK_DESCRIPTOR_TYPE_INPUT_ATTACHMENT is accessed as a result of this command, all image subresources identified by that descriptor must be in the image layout identified when the descriptor was written (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/drawing.html#VUID-vkCmdDraw-None-09600)

Start with the Streamline sample integration and the Vulkan validation setup shown in the issue, enabling synchronization validation and disabling the duplicate message limit to reproduce the warnings. Trace the reported DLSS-G, fake swapchain, output-image, buffer, and semaphore messages, then verify that the validation errors and synchronization hazards no longer occur.