VK_ERROR_DEVICE_LOST when switching workspaces on Linux (i3)

Moderator: GZDoom Developers

VK_ERROR_DEVICE_LOST when switching workspaces on Linux (i3)

Postby Eliza Pubblebury » Sun Mar 15, 2020 6:22 pm

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:1697: 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)
Eliza Pubblebury
 

Re: VK_ERROR_DEVICE_LOST when switching workspaces on Linux

Postby Rachael » Sun Mar 15, 2020 6:35 pm

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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: VK_ERROR_DEVICE_LOST when switching workspaces on Linux

Postby Eliza Pubblebury » Sun Mar 15, 2020 7:01 pm

I don't normally use any compositor.

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

Re: VK_ERROR_DEVICE_LOST when switching workspaces on Linux

Postby Eliza Pubblebury » Sun Mar 15, 2020 7:22 pm

FWIW, vkcube handles switching fine without compositor.
Eliza Pubblebury
 

Re: VK_ERROR_DEVICE_LOST when switching workspaces on Linux

Postby Rachael » Sun Mar 15, 2020 8:04 pm

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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: VK_ERROR_DEVICE_LOST when switching workspaces on Linux

Postby dpJudas » Sun Mar 15, 2020 8:37 pm

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.
dpJudas
 
 
 
Joined: 28 May 2016

Re: VK_ERROR_DEVICE_LOST when switching workspaces on Linux

Postby Rachael » Sun Mar 15, 2020 10:36 pm

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.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: VK_ERROR_DEVICE_LOST when switching workspaces on Linux

Postby Eliza Pubblebury » Mon Mar 16, 2020 4:46 am

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
Eliza Pubblebury
 

Re: VK_ERROR_DEVICE_LOST when switching workspaces on Linux

Postby dpJudas » Mon Mar 16, 2020 5:50 am

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.
dpJudas
 
 
 
Joined: 28 May 2016


Return to Vulkan Renderer Bugs

Who is online

Users browsing this forum: No registered users and 1 guest