defold icon indicating copy to clipboard operation
defold copied to clipboard
verified publisher icon defold

Game crashes with Vulkan graphics adapter on Geforce RTX

Open aglitchman opened this issue 9 months ago • 4 comments

Describe the bug (REQUIRED) I decided to test my projects on Vulkan on Windows. On the Intel Arc B580, everything works perfectly, as well as on OpenGL. On the Geforce RTX 3090, the image jerks as if we have a very floating delta time. Plus the engine crashes on its own.

Drivers are latest, 576.52, and I tested previous versions as well. No extra dependencies are used. Vsync is on, 60 hz monitor.

Vulkan Cube demo from SDK runs well.

To Reproduce (REQUIRED) Steps to reproduce the behavior:

  1. Run the attached project.

Expected behavior (REQUIRED) The project should run well.

Defold version (REQUIRED):

  • Version: 1.10.1, 1.10.2 beta

Platforms (REQUIRED):

  • Platforms: Windows 10

Minimal repro case project (OPTIONAL):

vulkan_issue_on_rtx.zip

Logs (OPTIONAL):

INFO:DLIB: Log server started on port 51923
INFO:ENGINE: Target listening with name: ARTSIOM-PC - fe80::9bf4:6333:d43f:a6ef - Windows
INFO:ENGINE: Engine service started on port 51924
INFO:GRAPHICS: Installed graphics device 'ADAPTER_FAMILY_VULKAN'
INFO:ENGINE: Defold Engine 1.10.2 (649461c)
INFO:DLIB: Initialized Remotery (ws://127.0.0.1:17815/rmt)
INFO:GRAPHICS: Vulkan device selected: NVIDIA GeForce RTX 3090
ERROR:ENGINE: Could not find '@render' socket.
ERROR:DLIB: Invalid cache index file 'C:/Users/Artsiom/AppData/Roaming/Defold/http-cache/index'. Removing file.
INFO:ENGINE: Loading data from: build/default
INFO:SOUND: Mix format:
INFO:SOUND:   wFormatTag:       fffe  IEEE_FLOAT/PCM/EXTENSIBLE: 3 / 1 / fffe
INFO:SOUND:   nChannels:        2
INFO:SOUND:   nSamplesPerSec:   48000
INFO:SOUND:   nAvgBytesPerSec:  384000
INFO:SOUND:   nBlockAlign:      8
INFO:SOUND:   wBitsPerSample:   32
INFO:SOUND:   -> Format:        3  IEEE_FLOAT/PCM/EXTENSIBLE: 3 / 1 / fffe
INFO:SOUND:   DSP backend: SSE
INFO:SOUND: Sound
INFO:SOUND:   nSamplesPerSec:   48000
INFO:ENGINE: Initialised sound device 'default'
INFO:DLIB: SSDP: Started on address 172.21.160.1
INFO:DLIB: SSDP: Started on address 172.24.192.1
INFO:DLIB: SSDP: Started on address 192.168.56.1
INFO:DLIB: SSDP: Started on address 192.168.100.140
INFO:DLIB: SSDP: Started on address 192.168.198.1
INFO:DLIB: SSDP: Started on address 192.168.241.1
ERROR:GRAPHICS: Vulkan Error (..\src\vulkan\graphics_vulkan.cpp:1385) VK_ERROR_DEVICE_LOST
Assertion failed: 0, file ..\src\vulkan\graphics_vulkan.cpp, line 1385
INFO:CRASH: Successfully wrote Crashdump to file: C:/Users/Artsiom/AppData/Roaming/Defold/_crash
ERROR:CRASH: CALL STACK:

ERROR:CRASH:  0 0x7FF7AFCD0FB0 dmCrash::GenerateCallstack D:\a\defold\defold\engine\crash\src\backtrace_win32.cpp:144
ERROR:CRASH:  1 0x7FF7B00BCA9C raise /tmp/job4595122215750182228/minkernel/crts/ucrt/src/appcrt/misc/signal.cpp:547
ERROR:CRASH:  2 0x7FF7B00AD084 abort /tmp/job4595122215750182228/minkernel/crts/ucrt/src/appcrt/startup/abort.cpp:71
ERROR:CRASH:  3 0x7FF7B00AC030 common_assert_to_stderr<wchar_t> /tmp/job4595122215750182228/minkernel/crts/ucrt/src/appcrt/startup/assert.cpp:186
ERROR:CRASH:  4 0x7FF7B00ABB48 _wassert /tmp/job4595122215750182228/minkernel/crts/ucrt/src/appcrt/startup/assert.cpp:443
ERROR:CRASH:  5 0x7FF7AFCB0D40 dmGraphics::VulkanFlip D:\a\defold\defold\engine\graphics\src\vulkan\graphics_vulkan.cpp:1393
ERROR:CRASH:  6 0x7FF7AFDC5A60 dmEngine::StepFrame D:\a\defold\defold\engine\engine\src\engine.cpp:2001
ERROR:CRASH:  7 0x7FF7AFDBFC00 dmEngineUpdate D:\a\defold\defold\engine\engine\src\engine.cpp:2449
ERROR:CRASH:  8 0x7FF7AFDC67D0 dmEngine::RunLoop D:\a\defold\defold\engine\engine\src\engine_loop.cpp:83
ERROR:CRASH:  9 0x7FF7AFCBA500 engine_main D:\a\defold\defold\engine\engine\src\engine_main.cpp:152
ERROR:CRASH: 10 0x7FF7B0065EA4 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
ERROR:CRASH: 11 0x7FF9AB787360 BaseThreadInitThunk <unknown>:0
ERROR:CRASH: 12 0x7FF9AD15CC70 RtlUserThreadStart <unknown>:0
ERROR:CRASH:

Crash dump: _crash.zip

Screenshots (OPTIONAL): OpenGL - everything is okay

https://github.com/user-attachments/assets/5271b873-82d6-423c-a824-d52d8a95098d

Vulkan - jittering or it's like we're at 40 fps instead of 60 fps:

https://github.com/user-attachments/assets/01e9c2ee-cc13-4dd4-a5fe-2487bc0c8008

I hope the video shows the non-uniformity of image movement on Vulkan. I note that the "dt" in update is a bit "floating":

DEBUG:SCRIPT: update	0.016685999929905
DEBUG:SCRIPT: update	0.016660999506712
DEBUG:SCRIPT: update	0.016657000407577
DEBUG:SCRIPT: update	0.016659999266267
DEBUG:SCRIPT: update	0.01664499938488
DEBUG:SCRIPT: update	0.016702000051737
DEBUG:SCRIPT: update	0.016695000231266
DEBUG:SCRIPT: update	0.016653999686241
DEBUG:SCRIPT: update	0.016798999160528
DEBUG:SCRIPT: update	0.016914999112487
DEBUG:SCRIPT: update	0.016394000500441
DEBUG:SCRIPT: update	0.016548000276089
DEBUG:SCRIPT: update	0.016698999330401
DEBUG:SCRIPT: update	0.01668299920857
DEBUG:SCRIPT: update	0.016620999202132
DEBUG:SCRIPT: update	0.01672999933362

Additional context (OPTIONAL): There is no extra software like RTSS installed, only Steam and RenderDoc. The screenshot from Vulkan Configurator (just to be sure that there are no hooks from RTSS etc):

Image

aglitchman avatar Jun 10 '25 14:06 aglitchman

I haven't been able to reproduce it so far (I have an Nvidia RTX 3050 Ti, driver 546)

Will try to update drivers as well to see if that triggers it.

Edit: I was able to download the driver, but the "GeForce Experience" refused to install it, and doesn't give a reason as to why it fails...

JCash avatar Jun 16 '25 08:06 JCash

I checked the project on another PC with Windows 11, Ryzen 7500F, Geforce RTX 3090, but driver older - 566.24. The result is the same. Happens at random times, ie the first 2 runs of the build everything was fine and then the game crashes.

But, nothing like this happens on the release build run separately, i.e. it runs ok.

INFO:DLIB: Log server started on port 51762
INFO:ENGINE: Target listening with name: VOLHA-MINI - fe80::6ee2:2c89:f3d7:9db9 - Windows
INFO:ENGINE: Engine service started on port 51763
INFO:GRAPHICS: Installed graphics device 'ADAPTER_FAMILY_VULKAN'
INFO:ENGINE: Defold Engine 1.10.2 (7a0e23b)
INFO:DLIB: Initialized Remotery (ws://127.0.0.1:17815/rmt)
INFO:GRAPHICS: Vulkan device selected: NVIDIA GeForce RTX 3090
INFO:ENGINE: Loading data from: build/default
INFO:SOUND: Mix format:
INFO:SOUND:   wFormatTag:       fffe  IEEE_FLOAT/PCM/EXTENSIBLE: 3 / 1 / fffe
INFO:SOUND:   nChannels:        2
INFO:SOUND:   nSamplesPerSec:   48000
INFO:SOUND:   nAvgBytesPerSec:  384000
INFO:SOUND:   nBlockAlign:      8
INFO:SOUND:   wBitsPerSample:   32
INFO:SOUND:   -> Format:        3  IEEE_FLOAT/PCM/EXTENSIBLE: 3 / 1 / fffe
INFO:SOUND:   DSP backend: SSE
INFO:SOUND: Sound
INFO:SOUND:   nSamplesPerSec:   48000
INFO:ENGINE: Initialised sound device 'default'
INFO:DLIB: SSDP: Started on address 192.168.1.34
ERROR:GRAPHICS: Vulkan Error (..\src\vulkan\graphics_vulkan.cpp:1385) VK_ERROR_DEVICE_LOST
Assertion failed: 0, file ..\src\vulkan\graphics_vulkan.cpp, line 1385
INFO:CRASH: Successfully wrote Crashdump to file: C:/Users/olizz/AppData/Roaming/Defold/_crash
ERROR:CRASH: CALL STACK:

ERROR:CRASH:  0 0x7FF751960FB0 dmCrash::GenerateCallstack D:\a\defold\defold\engine\crash\src\backtrace_win32.cpp:144
ERROR:CRASH:  1 0x7FF751D4CA9C raise /tmp/job12021993384863438098/minkernel/crts/ucrt/src/appcrt/misc/signal.cpp:547
ERROR:CRASH:  2 0x7FF751D3D084 abort /tmp/job12021993384863438098/minkernel/crts/ucrt/src/appcrt/startup/abort.cpp:71
ERROR:CRASH:  3 0x7FF751D3C030 common_assert_to_stderr<wchar_t> /tmp/job12021993384863438098/minkernel/crts/ucrt/src/appcrt/startup/assert.cpp:186
ERROR:CRASH:  4 0x7FF751D3BB48 _wassert /tmp/job12021993384863438098/minkernel/crts/ucrt/src/appcrt/startup/assert.cpp:443
ERROR:CRASH:  5 0x7FF751940D40 dmGraphics::VulkanFlip D:\a\defold\defold\engine\graphics\src\vulkan\graphics_vulkan.cpp:1393
ERROR:CRASH:  6 0x7FF751A55A60 dmEngine::StepFrame D:\a\defold\defold\engine\engine\src\engine.cpp:2001
ERROR:CRASH:  7 0x7FF751A4FC00 dmEngineUpdate D:\a\defold\defold\engine\engine\src\engine.cpp:2449
ERROR:CRASH:  8 0x7FF751A567D0 dmEngine::RunLoop D:\a\defold\defold\engine\engine\src\engine_loop.cpp:83
ERROR:CRASH:  9 0x7FF75194A500 engine_main D:\a\defold\defold\engine\engine\src\engine_main.cpp:152
ERROR:CRASH: 10 0x7FF751CF5EA4 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
ERROR:CRASH: 11 0x7FFEC9FEE8C0 BaseThreadInitThunk <unknown>:0
ERROR:CRASH: 12 0x7FFECB71C320 RtlUserThreadStart <unknown>:0
ERROR:CRASH:

Crashdump - _crash.zip

but the "GeForce Experience" refused to install it, and doesn't give a reason as to why it fails...

For normal operation of the video card Geforce Experience is not necessary - it is a software for “optimizing games”, for recording video from the screen, displaying FPS etc (although in Windows 11 itself is no less good recording via Win+Alt+R or the program “Snipping Tool”, and displaying FPS is in Gamebar). I personally don't use it, I don't even install it to not to bloat the PC.

aglitchman avatar Jun 16 '25 12:06 aglitchman

I haven't been able to reproduce it so far (I have an Nvidia RTX 3050 Ti, driver 546)

If you can tell me how to debug this - then I can try to find the cause myself.

aglitchman avatar Jun 16 '25 12:06 aglitchman

Can you try it with validation layers?

https://github.com/defold/defold/blob/dev/engine/graphics/src/vulkan/README.md

Jhonnyg avatar Jun 21 '25 18:06 Jhonnyg

I installed the Vulkan SDK as you can see in the screenshot in the first post, but it's not clear to me what I should do next? Add --use-validation-layers command-line arg?

For example, I enabled the “Crash Diagnostic” mode and here I attach the crash dump + engine logs

cdl_dump.zip

Image

aglitchman avatar Jun 23 '25 11:06 aglitchman

I don't remember 100% how this works (it "just" works on my machine), but it should be enough that a "VK_SDK_PATH" environment variable is set. Do you see anything in the console?

Jhonnyg avatar Jun 24 '25 15:06 Jhonnyg

Do you see anything in the console?

Yes, and the log is quite large, so I saved it to the archive in the previous message. It is mixed with the engine logs.

aglitchman avatar Jun 24 '25 18:06 aglitchman

@Jhonnyg

I read your comment in the Vulkan adapter about swap chain image count:

        // From the docs:
        // ==============
        // minImageCount: the minimum number of images the specified device supports for a swapchain created for the surface, and will be at least one.
        // maxImageCount: the maximum number of images the specified device supports for a swapchain created for the surface,
        //  and will be either 0, or greater than or equal to minImageCount. A value of 0 means that there is no limit on the number of images,
        //  though there may be limits related to the total amount of memory used by presentable images.

         // The +1 here is to add a little bit of headroom, from vulkan-tutorial.com:
        // "we may sometimes have to wait on the driver to complete internal operations
        // before we can acquire another image to render to"
        uint32_t swap_chain_image_count = capabilities.m_SurfaceCapabilities.minImageCount + 1;

        if (capabilities.m_SurfaceCapabilities.maxImageCount > 0)
        {
            swap_chain_image_count = dmMath::Clamp(swap_chain_image_count,
                capabilities.m_SurfaceCapabilities.minImageCount,
                capabilities.m_SurfaceCapabilities.maxImageCount);
        }

        swap_chain_image_count = dmMath::Min(swap_chain_image_count, (uint32_t) DM_MAX_FRAMES_IN_FLIGHT);

From Vulkan Hardware Capability Viewer / ‘Surface’ tab - the value of minImageCount is 2. Your code wants to use 2+1, but then limits itself to 2 because of DM_MAX_FRAMES_IN_FLIGHT. For such video cards/displays, might it be necessary to set DM_MAX_FRAMES_IN_FLIGHT to 3? Could this be why the image appears to be jerky?

However, on Intel Arc B580, minImageCount is also 2 and everything works fine.

aglitchman avatar Jun 24 '25 19:06 aglitchman

I made a patch that increases max frames in flight to 3, but it didn't help. So my assumption was wrong.

INFO:DLIB: Log server started on port 60589
INFO:ENGINE: Target listening with name: VOLHA-MINI - fe80::6ee2:2c89:f3d7:9db9 - Windows
INFO:ENGINE: Engine service started on port 60590
INFO:GRAPHICS: Installed graphics device 'ADAPTER_FAMILY_VULKAN'
INFO:ENGINE: Defold Engine 1.10.2 (7a0e23b)
INFO:DLIB: Initialized Remotery (ws://127.0.0.1:17815/rmt)
INFO:GRAPHICS: PATCH: Vulkan InitializeVulkan
INFO:GRAPHICS: Vulkan device selected: NVIDIA GeForce RTX 3090
INFO:GRAPHICS: Validation Layer: vkCreateDevice(): pCreateInfo->pNext chain includes a structure with unexpected VkStructureType VK_STRUCTURE_TYPE_APPLICATION_INFO.
pNext -> [VK_STRUCTURE_TYPE_LOADER_DEVICE_CREATE_INFO] -> [VK_STRUCTURE_TYPE_LOADER_DEVICE_CREATE_INFO] -> [VkApplicationInfo]
This error is based on the Valid Usage documentation for version 313 of the Vulkan header.  It is possible that you are using a struct from a private extension or an extension that was added to a later version of the Vulkan header, in which case the use of pCreateInfo->pNext is undefined and may not work correctly with validation enabled.
The Vulkan spec states: Each pNext member of any structure (including this one) in the pNext chain must be either NULL or a pointer to a valid struct for extending VkDeviceCreateInfo (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/devsandqueues.html#VUID-VkDeviceCreateInfo-pNext-pNext)
INFO:GRAPHICS: PATCH: Vulkan UpdateSwapChain
INFO:GRAPHICS: PATCH: Vulkan minImageCount: 2
INFO:GRAPHICS: PATCH: Vulkan maxImageCount: 8
INFO:GRAPHICS: PATCH: Vulkan swap_chain_image_count: 3
ERROR:ENGINE: Could not find '@render' socket.
INFO:GRAPHICS: Validation Layer: vkCreateRenderPass(): pCreateInfo->pAttachments[0] format is VK_FORMAT_B8G8R8A8_UNORM and loadOp is VK_ATTACHMENT_LOAD_OP_LOAD, but initialLayout is VK_IMAGE_LAYOUT_UNDEFINED.
The Vulkan spec states: If format includes a color or depth component and loadOp is VK_ATTACHMENT_LOAD_OP_LOAD, then initialLayout must not be VK_IMAGE_LAYOUT_UNDEFINED (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/renderpass.html#VUID-VkAttachmentDescription-format-06699)
INFO:ENGINE: Loading data from: build/default
INFO:SOUND: Mix format:
INFO:SOUND:   wFormatTag:       fffe  IEEE_FLOAT/PCM/EXTENSIBLE: 3 / 1 / fffe
INFO:SOUND:   nChannels:        2
INFO:SOUND:   nSamplesPerSec:   48000
INFO:SOUND:   nAvgBytesPerSec:  384000
INFO:SOUND:   nBlockAlign:      8
INFO:SOUND:   wBitsPerSample:   32
INFO:SOUND:   -> Format:        3  IEEE_FLOAT/PCM/EXTENSIBLE: 3 / 1 / fffe
INFO:SOUND:   DSP backend: SSE
INFO:SOUND: Sound
INFO:SOUND:   nSamplesPerSec:   48000
INFO:ENGINE: Initialised sound device 'default'
INFO:GRAPHICS: Validation Layer: vkCreateGraphicsPipelines(): pCreateInfos[0].pInputAssemblyState topology is VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST and primitiveRestartEnable is VK_TRUE and the primitiveTopologyListRestart feature was not enabled.
The Vulkan spec states: If the primitiveTopologyListRestart feature is not enabled, and topology is VK_PRIMITIVE_TOPOLOGY_POINT_LIST, VK_PRIMITIVE_TOPOLOGY_LINE_LIST, VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST, VK_PRIMITIVE_TOPOLOGY_LINE_LIST_WITH_ADJACENCY, or VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST_WITH_ADJACENCY, primitiveRestartEnable must be VK_FALSE (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/drawing.html#VUID-VkPipelineInputAssemblyStateCreateInfo-topology-06252)
INFO:GRAPHICS: Validation Layer: vkCreateGraphicsPipelines(): pCreateInfos[0].pInputAssemblyState topology is VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST and primitiveRestartEnable is VK_TRUE and the primitiveTopologyListRestart feature was not enabled.
The Vulkan spec states: If the primitiveTopologyListRestart feature is not enabled, and topology is VK_PRIMITIVE_TOPOLOGY_POINT_LIST, VK_PRIMITIVE_TOPOLOGY_LINE_LIST, VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST, VK_PRIMITIVE_TOPOLOGY_LINE_LIST_WITH_ADJACENCY, or VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST_WITH_ADJACENCY, primitiveRestartEnable must be VK_FALSE (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/drawing.html#VUID-VkPipelineInputAssemblyStateCreateInfo-topology-06252)
INFO:DLIB: SSDP: Started on address 192.168.1.34
INFO:GRAPHICS: Validation Layer: vkResetDescriptorPool(): descriptorPool can't be called on VkDescriptorPool 0x220000000022 that is currently in use by VkCommandBuffer 0x2443a697af0.
The Vulkan spec states: All uses of descriptorPool (via any allocated descriptor sets) must have completed execution (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/descriptorsets.html#VUID-vkResetDescriptorPool-descriptorPool-00313)
INFO:GRAPHICS: Validation Layer: vkBeginCommandBuffer(): on active VkCommandBuffer 0x2443a697af0 before it has completed. You must check command buffer fence before this call.
The Vulkan spec states: commandBuffer must not be in the recording or pending state (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkBeginCommandBuffer-commandBuffer-00049)
INFO:GRAPHICS: Validation Layer: vkResetDescriptorPool(): descriptorPool can't be called on VkDescriptorPool 0x220000000022 that is currently in use by VkCommandBuffer 0x2443a697af0.
The Vulkan spec states: All uses of descriptorPool (via any allocated descriptor sets) must have completed execution (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/descriptorsets.html#VUID-vkResetDescriptorPool-descriptorPool-00313)
INFO:GRAPHICS: Validation Layer: vkBeginCommandBuffer(): on active VkCommandBuffer 0x2443a697af0 before it has completed. You must check command buffer fence before this call.
The Vulkan spec states: commandBuffer must not be in the recording or pending state (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkBeginCommandBuffer-commandBuffer-00049)
INFO:GRAPHICS: Validation Layer: vkResetDescriptorPool(): descriptorPool can't be called on VkDescriptorPool 0x220000000022 that is currently in use by VkCommandBuffer 0x2443a697af0.
The Vulkan spec states: All uses of descriptorPool (via any allocated descriptor sets) must have completed execution (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/descriptorsets.html#VUID-vkResetDescriptorPool-descriptorPool-00313)
INFO:GRAPHICS: Validation Layer: vkBeginCommandBuffer(): on active VkCommandBuffer 0x2443a697af0 before it has completed. You must check command buffer fence before this call.
The Vulkan spec states: commandBuffer must not be in the recording or pending state (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkBeginCommandBuffer-commandBuffer-00049)
INFO:GRAPHICS: Validation Layer: vkResetDescriptorPool(): descriptorPool can't be called on VkDescriptorPool 0x1f000000001f that is currently in use by VkCommandBuffer 0x2443a694aa0.
The Vulkan spec states: All uses of descriptorPool (via any allocated descriptor sets) must have completed execution (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/descriptorsets.html#VUID-vkResetDescriptorPool-descriptorPool-00313)
INFO:GRAPHICS: Validation Layer: vkBeginCommandBuffer(): on active VkCommandBuffer 0x2443a694aa0 before it has completed. You must check command buffer fence before this call.
The Vulkan spec states: commandBuffer must not be in the recording or pending state (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkBeginCommandBuffer-commandBuffer-00049)
INFO:GRAPHICS: Validation Layer: vkQueueSubmit(): pSubmits[0].pSignalSemaphores[0] (VkSemaphore 0x1a000000001a) is being signaled by VkQueue 0x24437b423c0, but it may still be in use by VkSwapchainKHR 0x50000000005.
Here are the most recently acquired image indices: 2, 2, 2, 1, [0], 2, 1, 1.
(brackets mark the last use of VkSemaphore 0x1a000000001a in a presentation operation)
Swapchain image 0 was presented but was not re-acquired, so VkSemaphore 0x1a000000001a 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. This also handles the case where vkAcquireNextImageKHR returns the same index twice in a row. 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)
INFO:GRAPHICS: Validation Layer: vkQueueSubmit(): pSubmits[0].pSignalSemaphores[0] (VkSemaphore 0x140000000014) is being signaled by VkQueue 0x24437b423c0, but it may still be in use by VkSwapchainKHR 0x50000000005.
Here are the most recently acquired image indices: 2, 2, 1, 0, [2], 1, 1, 0.
(brackets mark the last use of VkSemaphore 0x140000000014 in a presentation operation)
Swapchain image 2 was presented but was not re-acquired, so VkSemaphore 0x140000000014 may still be in use and cannot be safely reused with image index 0.
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)
INFO:GRAPHICS: Validation Layer: vkCreateGraphicsPipelines(): pCreateInfos[0].pInputAssemblyState topology is VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST and primitiveRestartEnable is VK_TRUE and the primitiveTopologyListRestart feature was not enabled.
The Vulkan spec states: If the primitiveTopologyListRestart feature is not enabled, and topology is VK_PRIMITIVE_TOPOLOGY_POINT_LIST, VK_PRIMITIVE_TOPOLOGY_LINE_LIST, VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST, VK_PRIMITIVE_TOPOLOGY_LINE_LIST_WITH_ADJACENCY, or VK_PRIMITIVE_TOPOLOGY_TRIANGLE_LIST_WITH_ADJACENCY, primitiveRestartEnable must be VK_FALSE (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/drawing.html#VUID-VkPipelineInputAssemblyStateCreateInfo-topology-06252)
INFO:GRAPHICS: Validation Layer: vkResetDescriptorPool(): descriptorPool can't be called on VkDescriptorPool 0x1f000000001f that is currently in use by VkCommandBuffer 0x2443a694aa0.
The Vulkan spec states: All uses of descriptorPool (via any allocated descriptor sets) must have completed execution (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/descriptorsets.html#VUID-vkResetDescriptorPool-descriptorPool-00313)
INFO:GRAPHICS: Validation Layer: vkBeginCommandBuffer(): on active VkCommandBuffer 0x2443a694aa0 before it has completed. You must check command buffer fence before this call.
The Vulkan spec states: commandBuffer must not be in the recording or pending state (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkBeginCommandBuffer-commandBuffer-00049)
INFO:GRAPHICS: Validation Layer: vkQueueSubmit(): pSubmits[0].pSignalSemaphores[0] (VkSemaphore 0x170000000017) is being signaled by VkQueue 0x24437b423c0, but it may still be in use by VkSwapchainKHR 0x50000000005.
Here are the most recently acquired image indices: 0, 2, 1, 2, [0], 1, 1, 2.
(brackets mark the last use of VkSemaphore 0x170000000017 in a presentation operation)
Swapchain image 0 was presented but was not re-acquired, so VkSemaphore 0x170000000017 may still be in use and cannot be safely reused with image index 2.
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)
INFO:GRAPHICS: Validation Layer: vkResetDescriptorPool(): descriptorPool can't be called on VkDescriptorPool 0x1f000000001f that is currently in use by VkCommandBuffer 0x2443a694aa0.
The Vulkan spec states: All uses of descriptorPool (via any allocated descriptor sets) must have completed execution (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/descriptorsets.html#VUID-vkResetDescriptorPool-descriptorPool-00313)
INFO:GRAPHICS: Validation Layer: vkBeginCommandBuffer(): on active VkCommandBuffer 0x2443a694aa0 before it has completed. You must check command buffer fence before this call.
The Vulkan spec states: commandBuffer must not be in the recording or pending state (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkBeginCommandBuffer-commandBuffer-00049)
INFO:GRAPHICS: Validation Layer: vkQueueSubmit(): pSubmits[0].pSignalSemaphores[0] (VkSemaphore 0x1a000000001a) is being signaled by VkQueue 0x24437b423c0, but it may still be in use by VkSwapchainKHR 0x50000000005.
Here are the most recently acquired image indices: 0, 1, 1, 2, [0], 1, 1, 2.
(brackets mark the last use of VkSemaphore 0x1a000000001a in a presentation operation)
Swapchain image 0 was presented but was not re-acquired, so VkSemaphore 0x1a000000001a may still be in use and cannot be safely reused with image index 2.
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)
INFO:GRAPHICS: Validation Layer: vkResetDescriptorPool(): descriptorPool can't be called on VkDescriptorPool 0x1f000000001f that is currently in use by VkCommandBuffer 0x2443a694aa0.
The Vulkan spec states: All uses of descriptorPool (via any allocated descriptor sets) must have completed execution (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/descriptorsets.html#VUID-vkResetDescriptorPool-descriptorPool-00313)
INFO:GRAPHICS: Validation Layer: vkBeginCommandBuffer(): on active VkCommandBuffer 0x2443a694aa0 before it has completed. You must check command buffer fence before this call.
The Vulkan spec states: commandBuffer must not be in the recording or pending state (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkBeginCommandBuffer-commandBuffer-00049)
INFO:GRAPHICS: Validation Layer: vkQueueSubmit(): pSubmits[0].pSignalSemaphores[0] (VkSemaphore 0x140000000014) is being signaled by VkQueue 0x24437b423c0, but it may still be in use by VkSwapchainKHR 0x50000000005.
Here are the most recently acquired image indices: 0, 1, 1, 2, [0], 1, 1, 2.
(brackets mark the last use of VkSemaphore 0x140000000014 in a presentation operation)
Swapchain image 0 was presented but was not re-acquired, so VkSemaphore 0x140000000014 may still be in use and cannot be safely reused with image index 2.
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)
INFO:GRAPHICS: Validation Layer: vkResetDescriptorPool(): descriptorPool can't be called on VkDescriptorPool 0x1f000000001f that is currently in use by VkCommandBuffer 0x2443a694aa0.
The Vulkan spec states: All uses of descriptorPool (via any allocated descriptor sets) must have completed execution (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/descriptorsets.html#VUID-vkResetDescriptorPool-descriptorPool-00313)
INFO:GRAPHICS: Validation Layer: vkBeginCommandBuffer(): on active VkCommandBuffer 0x2443a694aa0 before it has completed. You must check command buffer fence before this call.
The Vulkan spec states: commandBuffer must not be in the recording or pending state (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkBeginCommandBuffer-commandBuffer-00049)
INFO:GRAPHICS: Validation Layer: vkQueueSubmit(): pSubmits[0].pSignalSemaphores[0] (VkSemaphore 0x170000000017) is being signaled by VkQueue 0x24437b423c0, but it may still be in use by VkSwapchainKHR 0x50000000005.
Here are the most recently acquired image indices: 0, 1, 1, 2, [0], 1, 1, 2.
(brackets mark the last use of VkSemaphore 0x170000000017 in a presentation operation)
Swapchain image 0 was presented but was not re-acquired, so VkSemaphore 0x170000000017 may still be in use and cannot be safely reused with image index 2.
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)
INFO:GRAPHICS: Validation Layer: vkResetDescriptorPool(): descriptorPool can't be called on VkDescriptorPool 0x1f000000001f that is currently in use by VkCommandBuffer 0x2443a694aa0.
The Vulkan spec states: All uses of descriptorPool (via any allocated descriptor sets) must have completed execution (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/descriptorsets.html#VUID-vkResetDescriptorPool-descriptorPool-00313)
INFO:GRAPHICS: Validation Layer: vkBeginCommandBuffer(): on active VkCommandBuffer 0x2443a694aa0 before it has completed. You must check command buffer fence before this call.
The Vulkan spec states: commandBuffer must not be in the recording or pending state (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkBeginCommandBuffer-commandBuffer-00049)
INFO:GRAPHICS: Validation Layer: vkQueueSubmit(): pSubmits[0].pSignalSemaphores[0] (VkSemaphore 0x1a000000001a) is being signaled by VkQueue 0x24437b423c0, but it may still be in use by VkSwapchainKHR 0x50000000005.
Here are the most recently acquired image indices: 0, 1, 1, 2, [0], 1, 1, 2.
(brackets mark the last use of VkSemaphore 0x1a000000001a in a presentation operation)
Swapchain image 0 was presented but was not re-acquired, so VkSemaphore 0x1a000000001a may still be in use and cannot be safely reused with image index 2.
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)
INFO:GRAPHICS: Validation Layer: (Warning - This VUID has now been reported 10 times, which is the duplicated_message_limit value, this will be the last time reporting it).
vkResetDescriptorPool(): descriptorPool can't be called on VkDescriptorPool 0x1f000000001f that is currently in use by VkCommandBuffer 0x2443a694aa0.
The Vulkan spec states: All uses of descriptorPool (via any allocated descriptor sets) must have completed execution (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/descriptorsets.html#VUID-vkResetDescriptorPool-descriptorPool-00313)
INFO:GRAPHICS: Validation Layer: (Warning - This VUID has now been reported 10 times, which is the duplicated_message_limit value, this will be the last time reporting it).
vkBeginCommandBuffer(): on active VkCommandBuffer 0x2443a694aa0 before it has completed. You must check command buffer fence before this call.
The Vulkan spec states: commandBuffer must not be in the recording or pending state (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkBeginCommandBuffer-commandBuffer-00049)
INFO:GRAPHICS: Validation Layer: vkQueueSubmit(): pSubmits[0].pSignalSemaphores[0] (VkSemaphore 0x140000000014) is being signaled by VkQueue 0x24437b423c0, but it may still be in use by VkSwapchainKHR 0x50000000005.
Here are the most recently acquired image indices: 0, 1, 1, 2, [0], 1, 1, 2.
(brackets mark the last use of VkSemaphore 0x140000000014 in a presentation operation)
Swapchain image 0 was presented but was not re-acquired, so VkSemaphore 0x140000000014 may still be in use and cannot be safely reused with image index 2.
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)
INFO:GRAPHICS: Validation Layer: vkQueueSubmit(): pSubmits[0].pSignalSemaphores[0] (VkSemaphore 0x170000000017) is being signaled by VkQueue 0x24437b423c0, but it may still be in use by VkSwapchainKHR 0x50000000005.
Here are the most recently acquired image indices: 0, 1, 1, 2, [0], 1, 1, 2.
(brackets mark the last use of VkSemaphore 0x170000000017 in a presentation operation)
Swapchain image 0 was presented but was not re-acquired, so VkSemaphore 0x170000000017 may still be in use and cannot be safely reused with image index 2.
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)
INFO:GRAPHICS: Validation Layer: (Warning - This VUID has now been reported 10 times, which is the duplicated_message_limit value, this will be the last time reporting it).
vkQueueSubmit(): pSubmits[0].pSignalSemaphores[0] (VkSemaphore 0x1a000000001a) is being signaled by VkQueue 0x24437b423c0, but it may still be in use by VkSwapchainKHR 0x50000000005.
Here are the most recently acquired image indices: 0, 1, 1, 2, [0], 1, 1, 2.
(brackets mark the last use of VkSemaphore 0x1a000000001a in a presentation operation)
Swapchain image 0 was presented but was not re-acquired, so VkSemaphore 0x1a000000001a may still be in use and cannot be safely reused with image index 2.
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)
INFO:GRAPHICS: Validation Layer: vkDestroyBuffer(): can't be called on VkBuffer 0x10d000000010d that is currently in use by VkCommandBuffer 0x2443a65a580.
The Vulkan spec states: All submitted commands that refer to buffer, either directly or via a VkBufferView, must have completed execution (https://vulkan.lunarg.com/doc/view/1.4.313.2/windows/antora/spec/latest/chapters/resources.html#VUID-vkDestroyBuffer-buffer-00922)
ERROR:GRAPHICS: Vulkan Error (..\src\vulkan\graphics_vulkan.cpp:1387) VK_ERROR_DEVICE_LOST
Assertion failed: 0, file ..\src\vulkan\graphics_vulkan.cpp, line 1387
INFO:CRASH: Successfully wrote Crashdump to file: C:/Users/olizz/AppData/Roaming/Defold/_crash
ERROR:CRASH: CALL STACK:

ERROR:CRASH:  0 0x7FF7D8FA0480 dmCrash::GenerateCallstack D:\a\defold\defold\engine\crash\src\backtrace_win32.cpp:144
ERROR:CRASH:  1 0x7FF7D936E76C raise /tmp/job8319380077026281469/minkernel/crts/ucrt/src/appcrt/misc/signal.cpp:547
ERROR:CRASH:  2 0x7FF7D935ED54 abort /tmp/job8319380077026281469/minkernel/crts/ucrt/src/appcrt/startup/abort.cpp:71
ERROR:CRASH:  3 0x7FF7D935DD00 common_assert_to_stderr<wchar_t> /tmp/job8319380077026281469/minkernel/crts/ucrt/src/appcrt/startup/assert.cpp:186
ERROR:CRASH:  4 0x7FF7D935D818 _wassert /tmp/job8319380077026281469/minkernel/crts/ucrt/src/appcrt/startup/assert.cpp:443
ERROR:CRASH:  5 0x7FF7D8F802E0 dmGraphics::VulkanFlip D:\a\ci-test-bullet-physics\ci-test-bullet-physics\engine\graphics\src\vulkan\graphics_vulkan.cpp:1395
ERROR:CRASH:  6 0x7FF7D90951D0 dmEngine::StepFrame D:\a\defold\defold\engine\engine\src\engine.cpp:2001
ERROR:CRASH:  7 0x7FF7D908F370 dmEngineUpdate D:\a\defold\defold\engine\engine\src\engine.cpp:2449
ERROR:CRASH:  8 0x7FF7D9095F40 dmEngine::RunLoop D:\a\defold\defold\engine\engine\src\engine_loop.cpp:83
ERROR:CRASH:  9 0x7FF7D8F899D0 engine_main D:\a\defold\defold\engine\engine\src\engine_main.cpp:152
ERROR:CRASH: 10 0x7FF7D9317B74 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
ERROR:CRASH: 11 0x7FFEC9FEE8C0 BaseThreadInitThunk <unknown>:0
ERROR:CRASH: 12 0x7FFECB71C320 RtlUserThreadStart <unknown>:0
ERROR:CRASH:

aglitchman avatar Jun 25 '25 13:06 aglitchman

Alright, something seems to be off with regards to synchronization here. It’s a bit difficult to figure it out just by looking at the logs I think, but the jitter should definitely be related to the message about the swap chain

Jhonnyg avatar Jun 25 '25 19:06 Jhonnyg