Streamline
Streamline copied to clipboard
NVIDIAGameWorks
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)
