Emulator

What's the problem? Describe what went wrong.

Resizing the RenderWidget while a game is running (not paused) will deadlock.

What steps will reproduce the problem?

A vkWaitForFences call in CommandBufferManager::WaitForCommandBufferCompletion often deadlocks when scaling the RenderWidget. Sometimes it won't if only adjusted a little.

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

Yes, it is present in 5.0-21395. It has been present since as early as 5.0-9638 (tested with the Windows exe under WINE). Before that, the RenderWidget had other concurrency issues that were resolved by this commit. Anecdotally, I don't remember this issue happening as far back as five years ago.

What are your PC specifications? (CPU, GPU, Operating System, more)

Manjaro Linux x86_64, NVidia GTX 980Ti w/ proprietary drivers

Is there anything else that can help developers narrow down the issue? (e.g. logs, screenshots,
configuration files, savefiles, savestates)

With API Validation Layers, I got this log message on 5.0-21200 when deadlocking:

53:34:325 VideoBackends/Vulkan/VulkanContext.cpp:824 I[Host GPU]: Vulkan debug message: Requested image extent (1324x919) does not match surface (1318x919), marking swapchain out of date
53:34:326 VideoBackends/Vulkan/VulkanContext.cpp:820 E[Host GPU]: Vulkan debug message: Validation Error: [ VUID-vkQueueSubmit-pWaitSemaphores-03238 ] Object 0: handle = 0x9,fde,6b0,000,000,014, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x7fd,eaf,2d4,cf0, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0xb5,045,2b0 | vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] queue (VkQueue 0x7fd,eaf,2d4,cf0[]) is waiting on semaphore (VkSemaphore 0x9,fde,6b0,000,000,014[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of all elements of pSubmits created with a VkSemaphoreType of VK_SEMAPHORE_TYPE_BINARY must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends must have also been submitted for execution (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkQueueSubmit-pWaitSemaphores-03238)

... and this log from a time it did not deadlock:

VideoBackends/Vulkan/VulkanContext.cpp:820 E[Host GPU]: Vulkan debug message: Validation Error: [ UNASSIGNED-Threading-MultipleThreads-Write ] Object 0: handle = 0x9,6f0,880,000,001,08d, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0xa0,5b2,36e | vkAcquireNextImageKHR():  THREADING ERROR : object of type VkSwapchainKHR is simultaneously used in current thread 140,736,035,030,720 and thread 140,650,043,410,112

Here is a quote from CasualPokePlayer from the official Discord:

hmm, i think i kind of get the issue
vkQueueSubmit is called with submit info that has a waiting semaphore, which needs to be signaled for the work submitted to complete. it is also called with a fence which would be signaled once the submitted work completes
vkAcquireNextImageKHR would be called eventually, which if it succeeds, then the waiting semaphore should be signaled
Except, vkAcquireNextImageKHR failed, note the "Failed to grab image from swap chain" message, indicating it failed. therefore, the semaphore is not signaled
vkWaitForFences is called, and wont return until the fence is signaled. fence is never signaled as work is never completed, as waiting semaphore is never signaled

there's handling to recreate/resize the swapchain in case vkAcquireNextImageKHR initially fails, however, that is not done again if vkAcquireNextImageKHR proceeds to fail again (i.e. if resize occurred agained before the second vkAcquireNextImageKHR call causing that to fail)

And here is a video by dreamsyntax showing the deadlock:
https://youtu.be/RAr_Z1N_kiU