VK_ERROR_DEVICE_LOST when switching workspaces on Linux (i3)

[Guest]

When I switch workspaces in i3 window manager, most of the time the game crashes with the following error. This also happens with toggling full-screen mode (through window manager shortcut) as well.

INTEL-MESA: error: ../mesa-20.0.0/src/intel/vulkan/anv_batch_chain.c execbuf2 failed: Invalid argument (VK_ERROR_DEVICE_LOST)

INTEL-MESA: warning: Haswell Vulkan support is incomplete
Vulkan device: Intel(R) HD Graphics 4400 (HSW GT2)
Vulkan device type: integrated gpu
Vulkan version: 1.2.131 (api) 20.0.0 (driver)

[Rachael]

I've never heard of the i3 window manager but this seems like an i3-specific bug, or a driver bug.

Does your X server support window composition? (Nearly all do) - and is it enabled?

If it's not, try running xcompmgr and enable it that way - and see if the bug still occurs when swapping workspaces.

[Guest]

I don't normally use any compositor.

I've just tried Xcompmgr, and indeed, it makes the problem go away.

[Guest]

FWIW, vkcube handles switching fine without compositor.

[Rachael]

Ok so what's happening here then is, when you are switching away from GZDoom to another window set without the compositor, the surface that Vulkan was using is effectively lost, and that is what causes the error.

The reason why the problem goes away when you run the compositor is because the compositor will force that surface to be retained, even if you don't actually see it. The compositor works by forcing all applications to draw their full windows, and it will handle the hiding/showing of windows and window overlaps by itself, rather than letting the applications deal with that instead.

The basic take-away from this is, then - that you can't minimize GZDoom without the compositor or else it will render to a null surface that doesn't exist, and hence the error.

Considering compositing is a modern feature of all OS's nowadays and pretty much a staple feature (hell, even versions of Windows past 8 refuse to run if you don't have it turned on), I don't know if it's worth going to the extra effort to fix this issue.

Nevertheless though, the fix doesn't seem to be too complex - GZDoom can check for the validity of the surface before rendering to it. Theoretically. I don't know how feasible that actually is, though.

[dpJudas]

The pasted output is not coming from GZDoom but rather the display driver / X11.

The presentation code in GZDoom already handles the cases where its window surface is lost, see VulkanSwapChain::AcquireImage and VulkanSwapChain::QueuePresent in vk_swapchain.cpp. Given that the driver itself gives a warning that it is incomplete and that the error comes from deep inside the driver, not GZDoom aborting due to valid errors reported by vulkan, I really need much more solid evidence that the fault is in my code.

You could try run it in a debug build with vk_debug 1 and check if the validation layer reports something illegal going on. If that thing doesn't say anything I'm afraid this is most likely an error elsewhere.

[Rachael]

Another possible point of failure is SDL, as well. So this is a pretty big failure chain to get to the root of the problem.

[Guest]

Oh, sorry, I forgot to mention a detail that's likely important. GZDoom shows an alert window saying "Could not submit command buffer: device lost". Which means the crash is in there: https://github.com/coelckers/gzdoom/blo ... 1294-L1298

[dpJudas]

A vulkan implementation reporting a lost device can do so for a number of implementation-specific reasons. This is going to need an actual Linux developer to fix. I do not have the operating system or the hardware to do anything here.