Project

General

Profile

Emulator Issues #9879

Vulkan "Failed to submit command buffer." when playing

Added by iwubcode over 3 years ago. Updated over 3 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:
5.0-2558

Description

Game Name?

Super Mario Galaxy

Game ID? (right click the game in the game list, properties, info tab)

RMGE01

MD5 Hash? (right click the game in the game list, properties, info tab, MD5 Hash: Compute)

f99a97f9ae4dccd1db45e9aaab9cebd8

What's the problem? Describe what went wrong.

Dolphin Emu crashes when running Vulkan with the error "Failed to submit command buffer.". Usually, the screen freezes for a moment and then black slowly fills the screen, then the error box pops up. One time, the system restarted.

What steps will reproduce the problem?

I can repeatedly cause this to occur when running Super Mario Galaxy. I have a save point before the first galaxy. Going there where they say to click on t he blue star luma and hit "A" will cause this issue every time.

Note: I also see the "Failed to submit command buffer" in other games while just playing for a period of time. (ex: this occurred in Soul Calibur II after a number of fights)

Which versions of Dolphin did you test on? Does using an older version of Dolphin solve your issue? If yes, which versions of Dolphin used to work?

Dolphin 5.0-1245

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

i7 6700k
rx480 reference (AMD drivers - 16.11.2)
Windows 10
16gb Ram

Is there any other relevant information? (e.g. logs, screenshots,
configuration files)

The log (just video backend) shows:

01:03:793 SwapChain.cpp:216 W[Video]: Vulkan: FIFO_RELAXED not available, falling back to FIFO.
01:04:596 BPStructs.cpp:633 W[Video]: Unknown BP opcode: address = 0x00000069 value = 0x000004ed
01:04:596 BPStructs.cpp:633 W[Video]: Unknown BP opcode: address = 0x00000046 value = 0x00000273
02:07:001 VulkanLoader.cpp:314 E[Video]: (Vulkan::CommandBufferManager::SubmitCommandBuffer) vkQueueSubmit failed: (-4: VK_ERROR_DEVICE_LOST)

History

#1 Updated by iwubcode over 3 years ago

I'm starting to suspect a driver issue. D3D12 crashes in the same place, i switched to OGL and after say 15mins of playing, it black screened. I'll try 5.0 stable once I set-up my wiimote (was using controller + relative wiimote pointer)

#2 Updated by iwubcode over 3 years ago

iwubcode wrote:

I'm starting to suspect a driver issue. D3D12 crashes in the same place, i switched to OGL and after say 15mins of playing, it black screened. I'll try 5.0 stable once I set-up my wiimote (was using controller + relative wiimote pointer)

I just want to comment on my previous statement. While I know Ishiiruka is not supported, it does not have this issue in either D3D12 or Vulkan. While it might still be driver related (since no one else seems to indicate they have the issue), it does seem to be code dependent.

I just tried it with dev build Dolphin 5.0-1333 with the same result (crash on D3D12/Vulkan selecting galaxy, crash on OGL after ~15mins of playing). D3D11 doesn't seem to have these issues. Also, worth noting that I updated my graphics drivers to 16.11.4 a few days ago.

#3 Updated by Stenzek over 3 years ago

Bugs like this can be tricky to debug, since as far as I'm aware none of the dev team has a Polaris card to reproduce the issue with. I'd guess it'd be an issue with the shaders if it's affecting multiple backends. Ishiiruka has a fair few differences in their shadergen code (mostly less accuracy over master), which could explain the difference.

Can you please test if the issue occurs on 5.0-1230 (last build before XFB was merged for Vulkan), as well as with PR 4462 (https://github.com/dolphin-emu/dolphin/pull/4462 / https://dl.dolphin-emu.org/prs/pr-4462-dolphin-latest-x64.7z), which might help in narrowing down what the problem is.

#4 Updated by iwubcode over 3 years ago

Stenzek wrote:

Bugs like this can be tricky to debug, since as far as I'm aware none of the dev team has a Polaris card to reproduce the issue with. I'd guess it'd be an issue with the shaders if it's affecting multiple backends. Ishiiruka has a fair few differences in their shadergen code (mostly less accuracy over master), which could explain the difference.

Can you please test if the issue occurs on 5.0-1230 (last build before XFB was merged for Vulkan), as well as with PR 4462 (https://github.com/dolphin-emu/dolphin/pull/4462 / https://dl.dolphin-emu.org/prs/pr-4462-dolphin-latest-x64.7z), which might help in narrowing down what the problem is.

Well unfortunately, I tried various dev builds as far back as 970~ and even stable 5.0 and they all exhibit the same issue (in DX12 and Vulkan where available).

What kinds of things would you look at if you were debugging this? With the holidays coming it might be tough for me to find time but I can potentially look at the code and debug it.

#5 Updated by Stenzek over 3 years ago

If you feel like doing some debugging work, it's sometimes possible to narrow down issues like these without looking at the code.

If the problem occurs consistently, you can try recording a long fifolog (on a machine/backend that doesn't crash), say 600 frames (10 seconds at 60hz), get it as close as possible to the crash point, it might be worth using frame stepping or slowing the emulation speed down, keep in mind a long fifolog can easily be hundreds of megabytes.

If playing back this fifolog causes the emulator to crash, you can start reducing the range of frames, then objects until it doesn't crash, then increase it to find the object that causes it to crash. From that we can likely figure out which shader in particular is causing the issue, and make a guess as to what the issue is.

No guarantees this would work though, as not all issues are reproducible with fifologs.

#6 Updated by iwubcode over 3 years ago

Stenzek wrote:

If you feel like doing some debugging work, it's sometimes possible to narrow down issues like these without looking at the code.

If the problem occurs consistently, you can try recording a long fifolog (on a machine/backend that doesn't crash), say 600 frames (10 seconds at 60hz), get it as close as possible to the crash point, it might be worth using frame stepping or slowing the emulation speed down, keep in mind a long fifolog can easily be hundreds of megabytes.

If playing back this fifolog causes the emulator to crash, you can start reducing the range of frames, then objects until it doesn't crash, then increase it to find the object that causes it to crash. From that we can likely figure out which shader in particular is causing the issue, and make a guess as to what the issue is.

No guarantees this would work though, as not all issues are reproducible with fifologs.

Huh didn't even know this was possible. How do you record a fifolog?

Unfortunately, the only machine that I have is a very very old windows xp machine. Could anyone on the dev team provide a fifolog for me to replay?

I also haven't tried a non-ishiiruka build in a while, I'll try the latest this weekend.

#7 Updated by iwubcode over 3 years ago

iwubcode wrote:

Unfortunately, the only machine that I have is a very very old windows xp machine

Probably goes without saying but I meant "only other machine"

(odd there's no way to correct an old comment)

#8 Updated by iwubcode over 3 years ago

This single frame from Mario Galaxy is what causes the crash! Going to try and work on wittling it down to a range of objects for Stenzek.

#9 Updated by iwubcode over 3 years ago

iwubcode wrote:

This single frame from Mario Galaxy is what causes the crash! Going to try and work on wittling it down to a range of objects for Stenzek.

I slowly incremented the object counter and it crashed when I hit object 10.

#10 Updated by JosJuice over 3 years ago

  • Status changed from New to Fixed
  • Fixed in set to 5.0-2558

Also available in: Atom PDF