fix(mvk): resumeLostDevice

[AaronO]

Command buffer errors currently trigger an exception "DeviceLost" crashing the process.

Looking at MKV's code we observe that:

• It hard fails if error is:

  MTLCommandBufferErrorBlacklisted || MTLCommandBufferErrorNotPermitted || MTLCommandBufferErrorDeviceRemoved
  

• Otherwise fails conditionally if config.resumeLostDevice == false (current default)

For Ryujinx's use-case it's more graceful to resume on those errors rather than crashing the app, the error isn't totally silenced since mvk still logs it

Fixes #4704, #4575

Notes

• Users can currently workaround this by setting this env MVK_CONFIG_RESUME_LOST_DEVICE=1, but IMO this should be the default behaviour

[gdkchan]

The device lost error is usually returned when there's something wrong, like a Metal error. For example, it is returned when Metal reports a InvalidResource error. Ignoring it does not fix the underlying issue, and the scene will not render correctly since it will likely just drop the problematic command buffer. It is better to fix the root issue than to do this. It could be useful for the few cases where the game is still playable despite it triggering errors here and there.

[IsaacMarovitz]

The device lost error is usually returned when there's something wrong, like a Metal error. For example, it is returned when Metal reports a InvalidResource error. Ignoring it does not fix the underlying issue, and the scene will not render correctly since it will likely just drop the problematic command buffer. It is better to fix the root issue than to do this. It could be useful for the few cases where the game is still playable despite it triggering errors here and there.

It's worth testing the specific game listed. If it looks fine IMO this is something we should consider. It's pretty common to use this env var.

[gdkchan]

Those games do have InvalidResource error, so I doubt they will look fine. But it shouldn't be hard to test.

[AaronO]

I agree it would be best to fix the root issue, but in my experience apps/games with these issues are still useable/tolerable, so this could be a reasonable patch until the root issue is resolved, landing this patch wouldn't hinder investigating it (errors are still logged and devs can simply set this to false)

A visual glitch / misrender is preferable than a crash to the end-user, if an app is glitchy they can choose to stop using it, if the emulator crashes they have no choice, so it's a "lesser evil" IMO

[AaronO]

I haven't tested many applications but in my experience this error was relatively infrequent and "random" in appearance. In practice this isn't failing every draw call but once every 10mn (or more)

[riperiperi]

This option is enabled on the macos1 build, but there are lots of mitigations that avoid the moltenvk bug that causes the Invalid Resource errors. I've explained why I think the error appears over here:

KhronosGroup/MoltenVK#1870

[github-actions]

Download the artifacts for this pull request:

• ryujinx-Release-1.1.0+192dd00-linux_x64
• ryujinx-Release-1.1.0+192dd00-osx_x64
• ryujinx-Release-1.1.0+192dd00-win_x64

Experimental GUI (Avalonia)

• ava-ryujinx-Release-1.1.0+192dd00-linux_x64
• ava-ryujinx-Release-1.1.0+192dd00-osx_x64
• ava-ryujinx-Release-1.1.0+192dd00-win_x64

GUI-less (SDL2)

• sdl2-ryujinx-headless-Release-1.1.0+192dd00-linux_x64
• sdl2-ryujinx-headless-Release-1.1.0+192dd00-osx_x64
• sdl2-ryujinx-headless-Release-1.1.0+192dd00-win_x64

Only for Developers

• ava-ryujinx-Debug-1.1.0+192dd00-linux_x64
• ava-ryujinx-Debug-1.1.0+192dd00-osx_x64
• ava-ryujinx-Debug-1.1.0+192dd00-win_x64
• ryujinx-Debug-1.1.0+192dd00-linux_x64
• ryujinx-Debug-1.1.0+192dd00-osx_x64
• ryujinx-Debug-1.1.0+192dd00-win_x64
• sdl2-ryujinx-headless-Debug-1.1.0+192dd00-linux_x64
• sdl2-ryujinx-headless-Debug-1.1.0+192dd00-osx_x64
• sdl2-ryujinx-headless-Debug-1.1.0+192dd00-win_x64

[riperiperi]

I think this is reasonable to enable, but we should probably at least partially work around Invalid Resource errors.