Emulator Issues #12121
openVulkan: Failed to submit command buffer
0%
Description
Hey guys, another Intel iGPU issue for you! So I've had this problem for a long time and this time the origin can be traced back to a driver update. The last good version was 26.20.100.6861
(released May 2019) and the first bad version 26.20.100.6890
. I reported the issue twice to Intel (forums.intel.com and software.intel.com) back in November but they couldn't or wouldn't help me.
The issue¶
This only happens on Vulkan. I saw this issue only once in some Mario Party GameCube game (in the middle of a round) and at the start of Mario Party 8. It is best reproducible in MP8 because it happens right at the start (before the Wii warning screen) so I was able to create a FIFO record pretty easily (see attachment). Again, running the record in any other backend works perfecty fine so this is a Vulkan-only issue.
I've turned on logging but nothing interesting pops up except this of course (like a hundred times):
VideoBackends\Vulkan\VulkanLoader.cpp:220 E[Video]: (SubmitCommandBuffer) vkQueueSubmit failed: (-4: VK_ERROR_DEVICE_LOST)
Common\MsgHandler.cpp:115 E[MASTER]: Question: Failed to submit command buffer.
I have turned on the Vulkan validation layer (Graphics -> Advanced -> Debugging -> Enable API Validation Layers) but there is not a single line in the log. Maybe it's not setup properly?
This is cleary a driver regression. Why are you reporting this here?¶
Well, I tried my best to get in contact with an Intel dev (to no avail) but I just have to assume that this is indeed not a regression. There have been 16 driver releases since the last "good" version so what are the chances that they made a mistake which still hasn't been detected/fixed after all these revisions. Could it may be that Dolphin does something weird / not according to spec? I've searched the bug tracker and couldn't find a single issue like mine, so it could theoretically be possible that other manufacturer's drivers simply ignore the issue, whilst Intel's refused?
I've recently came across this PR from the PPSSPP emulator which revealed such a "spec violation only Intel cares about". So I'm opening this bug report in the hopes to get some input from you. I am in fact on the 26.20.100.6861
driver, and while I don't care too much about new features from updated versions, I feel like I can't stay on this version forever.
Best regards
Files
Updated by JMC4789 over 4 years ago
Unfortunately Intel's Vulkan driver on Windows sucks and I don't think there's anything we can do about this. I'll see if Stenzek has a different opinion than me.
Updated by Anuskuss over 4 years ago
@JMC4789 I semi-agree with you. Although I had my fair share of problems with Intel graphics, I had my problems on my desktop with Nvidia as well. It's just Windows that sucks tbh, but that's another topic. If you guys don't care about this it's fine, I'll just stay at this version or update and use DX12 but my point still stands: What are the odds that Intel f*cked something up a full year ago that they couldn't have fixed or atleast encountered after 16 updates?
Updated by Anuskuss over 4 years ago
What are the odds that Intel f*cked something up a full year ago that they couldn't have fixed or atleast encountered after 16 updates?
Make that 17.
Updated by Anuskuss over 4 years ago
I'm almost certain that this is a shader issue because when jumping between drivers, it sometimes crashes while compiling them on the newer drivers. What would be a good way to disable the drawing of shaders to rule that out? I don't really code but I can follow directions if you guys want to work with me.
Updated by Techjar over 4 years ago
If you disable shaders you just won't be able to see anything. Shaders are the core of how Dolphin emulates the behavior of GX.
Updated by Anuskuss over 4 years ago
@Techjar Yeah, I understand that I just wanna see if it would still crash without shaders. Which I guess based on your comment it shouldn't.
Updated by Anonymous over 4 years ago
This issue was resolved for me in the latest driver releases by Intel. Try build 8280 or 8336 and see if they work for you also.
Updated by Anuskuss over 4 years ago
@ShadowMyst Still not working for me. Could you test the attached fifo file?
Updated by Anonymous over 4 years ago
Sorry, not experienced enough to work with those directly. What intel gpu do you have?
Updated by Anuskuss over 4 years ago
It's actually pretty simple. Just download the file and open it in Dolphin. If it's working you should see a loop of the first second of the Wii warning screen. If it doesn't, just a black screen follow by a "Failed to submit command buffer" (if you've "Use Panic Handlers" active).
OS: Windows 10 1809
GPU: Intel Iris Plus 640
Updated by Anonymous over 4 years ago
Give me a moment. Not certain what will happen on my end since I'm running 10th Gen Ice Lake with Iris Plus G7.
Updated by Anonymous over 4 years ago
Works fine for me. Keeps looping. The issue appears to be how your specific GPU functions with the Intel drivers; not the drivers in general.
Updated by Anuskuss over 4 years ago
Interesting. It could very well be that the newer GPUs get more testing and thus this issue slipped through. Do you have any unusual settings set in Dolphin? Also are you running Windows 10 2004?
Updated by Anonymous over 4 years ago
All my settings are kept at default, with the exception of having set 2 games to specifically turn off Arbitrary MipMapping for a decent performance boost (Rogue Squadron II and III). I tested your off under Windows 10 2004 and macOS 10.5.5.
I remember when I filed a similar report earlier this year that Stenzek said "Intel's driver up until recently would crash when booting because despite advertising support for dual-source blend, clearly hadn't tested any pipelines which used them because they'd kill it with a null pointer access."
Updated by Anonymous over 4 years ago
Which method of shader compilation are you using? Synchronous, Asynchronous (Ubershaders) or Synchronous (Ubershaders)? Before it was fixed by Intel for the Ice Lake Iris Plus gpu, it would only occur for me on Synchronous and Asynchronous (Ubershaders); never on Synchronous (Ubershaders). Have you tried all 3?
Updated by Anuskuss over 4 years ago
Yep, I already went through all settings and the only setting which affects this is switching from Vulkan to another backend (or staying on 26.20.100.6861
).
Updated by Anonymous over 4 years ago
Definitely seems specific to the 640. Stenzek would be the final say though.
Updated by Anuskuss over 4 years ago
Also happening to friend of mine on 655 and latest Win10.
Updated by Anonymous over 4 years ago
It might be better to say it is specific to the Gen 9/9.5 GPUs. Unless we hear from someone with an even older system.
Updated by Anonymous over 4 years ago
I have an update for you Anuskuss. I just did a clean re-install of Win 10 on my MacBook Pro 2020 and was able to reproduce the issue there. So it affects Gen 10 as well. No clue why it didn't happen before, but I honestly can't remember what version of the intel drivers were installed on my prior BootCamp configuration.
Updated by Anuskuss almost 4 years ago
I have turned on the Vulkan validation layer (Graphics -> Advanced -> Debugging -> Enable API Validation Layers) but there is not a single line in the log. Maybe it's not setup properly?
Turns out I had to install the Vulkan SDK to use the validation layer. After setting everything up and logging Host GPU only, I see these repeating lines in the log:
14:07:784 VideoBackends\Vulkan\VulkanContext.cpp:674 E[Host GPU]: Vulkan debug report: (Validation) Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01286 ] Object 0: handle = 0xa,540,ac0,000,000,009, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0xe9,e4b,2a9 | vkAcquireNextImageKHR: Semaphore must not be currently signaled or in a wait state. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must be unsignaled (https://vulkan.lunarg.com/doc/view/1.2.162.1/windows/1.2-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01286)
14:07:784 VideoBackends\Vulkan\VulkanContext.cpp:674 E[Host GPU]: Vulkan debug report: (Validation) Validation Error: [ VUID-vkQueuePresentKHR-pWaitSemaphores-03268 ] Object 0: handle = 0x23,24a,6f1,b18, type = VK_OBJECT_TYPE_QUEUE; Object 1: handle = 0x8,3d4,ee0,000,000,00b, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x25,1f8,f7a | vkQueuePresentKHR: Queue VkQueue 0x23,24a,6f1,b18[] is waiting on pWaitSemaphores[0] (VkSemaphore 0x8,3d4,ee0,000,000,00b[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of pPresentInfo must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends (if any) must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.2.162.1/windows/1.2-extensions/vkspec.html#VUID-vkQueuePresentKHR-pWaitSemaphores-03268)
By the way, Intel has released (atleast) 30 driver revisions since 26.20.100.6861
so it's getting more and more unlikely that it's a driver regression. My theory about this being a case where Intel is doing something more strictly than AMD/Nvidia to provoke this error honestly sounds pretty likely to me.
Updated by Rena over 2 years ago
This is not specific to Windows. I'm getting it on Artix Linux for the past couple weeks. It seems to be completely random. Anywhere between a few seconds to several minutes after starting a game it'll freeze with this message spammed endlessly until I close the emulator. It's practically guaranteed to happen within 15 minutes.
Updated by JMC4789 about 2 years ago
Can you test this on the latest dev builds? A lot of changes have been made to Vulkan recently that may help this.
Updated by Anuskuss about 2 years ago
Nope, stil bad. Thankfully, my new system has a real GPU and I don't have to deal with shitty Intel GPUs ever again.
However, my new system does have an Tiger Lake iGPU, and it still doesn't work, even though I'm on Linux now. So I was right, it's very likely not a driver issue (well Rena already sort of confirmed it, but they could've just tested the attached FIFO file instead of giving some vague scenario).