Vk_error_device_lost in many game titles

I’ve noticed the more I alt-tab or switch away from the game window the more often the bug occurs.

I tried the Vulkan Beta Driver at the suggestion of one of the users in the GitHub bug report, Still crashes sadly.

Still broken. 455.50.04

ffxiv_dx11_d3d11.log (4.7 KB)
ffxiv_dx11_dxgi.log (6.4 KB)

Beta Driver. Still Broken. 455.50.07

ffxiv_dx11_d3d11.log (4.7 KB)
ffxiv_dx11_dxgi.log (6.7 KB)

According to this PR you should try 455.50.10

Fixed a bug with the host-visible device-local memory heap, where if an allocation failed due to space constraints, it could cause the application to crash on future Vulkan function calls

Yeah the DXVK dev already let me know in the GitHub Issue thread.

Hello buggy drivers my old friend… it’s time to crash again. Broken 455.50.10.

ffxiv_dx11_d3d11.log (5.1 KB)
ffxiv_dx11_dxgi.log (6.7 KB)

Broken. 465.19.01.

ffxiv_dx11_d3d11.log (4.7 KB)
ffxiv_dx11_dxgi.log (6.7 KB)

2021-04-01: I’ve downgraded all the way to 440.100 again and I’ll be tested that for a good month or so.

Prime offload involved?
https://forums.developer.nvidia.com/t/doom-2016-vulkan-renderer-is-broken-since-440-drivers-optimus/160332/8?u=generix

Sadly not if you check my logs this is a desktop pc where the only graphics card is a NVIDIA GeForce GTX 960.

So it’s been a month now and no crashes, I’m just going to stick with this kernel and driver version. I’ve pretty much given up on trying to update the Nvidia Driver and not have this issue occur.

Software information

Final Fantasy XIV

System information

  • GPU: GeForce GTX 960
  • Kernel: 5.4.115
  • Driver: 440.100
  • Wine version: lutris-6.4-x86_64
  • DXVK version: 1.8.1

Log files

Maybe you really should try this workaround with newer drivers.

As the person here mentioned, this did fix his Doom Eternal issue on his desktop system too.

Which my original report about Doom 2016 was also pointing out a regression happened after 440 drivers, which you are currently relying on and call it better than others.

What does it do? Indication is, this GLX vendor library name var causes app profiles to not apply. From Doom 2016 to Doom Eternal and most likely any other apps that has workarounds in NV driver.

On a single NV gpu system reported vendor is NV without needing to use mentioned var (only useful if you need finer selection of GPU’s comes to GL stuff, that is the aim of it)

As you can see from previous NV driver changelogs, driver has a profile for DXVK too in place.

So it might worthy to give a shot.

I’m honestly out of steam to keep trying workarounds, I don’t know if Nvidia cares about this issue (doesn’t really seem like they do). So I’m sticking to kernel 5.4.x and nvidia 440.100 as long as I can. I have been dealing with this issue for 7 MONTHS! I’m not putting more of my time into testing until I can no longer stay on the kernel and driver combo that works at which point I am considering going to the competition to solve this issue and wash my hands of it entirely.

Edit: One exception is if a Nvidia representative actually asks me to do some testing then I might consider it, otherwise I’ve had enough.

I’ll test it for you. I know how much of a nightmare it can be trying to get your kernel and driver to match perfectly.

Also, I was just running ffxiv with dxvk disabled and dealing with 14fps down from 90.

Shouldn’t be more than a couple hours before I see a crash.

Using dxvk 1.8.1 and Driver 465.27.0 on archlinux with a GTX 760 and i5-9600k.

Crashed with __GLX_VENDOR_LIBRARY_NAME=bla in launch options with vk device lost error.

I have no trouble “matching” kenrel + nvidia versions I’m just sick of doing it, thanks for testing though. I am still happily sitting here on the latest 5.4 kernel with 440.100 with not a single crash. 5.4 is going to be supported until 2025 at which time Nvidia might finally fix this issue or I will look at another graphics card vendor.

Sorry, that wasn’t meant as a “you’re a dumb dumb.” It was a I’m having a really hard time attempting to do this so others are probably as well. But I’m on arch, so if I downgrade the kernel it’s only a matter of time before everything breaks.

I didn’t really feel insulted, it’s just I never heard the term before, also keep in mind I could easily run any version of the Nvidia Driver after 440.100 on Kernel 5.4. It’s my understand that Nvidia Drivers tend to break on newer kernels but older kernels tend to work fine even with the latest drivers. If you actually go to the 460.80 readme you’ll find the Supported Kernel Version as: 2.6.32 and newer. So yeah you really don’t have to match up specific kernels to specific drivers it’s just newer kernels tend to need patches from Nvidia to work properly.

1 Like

Always learning, thank you for the insight.

I’m encountering this problem too with Skyrim. With drivers newer than 440.100 (I’ve tested many, up through 460.84), Skyrim crashes often with the “Failed to sync fence: VK_ERROR_DEVICE_LOST” error. With driver 440.100, Skyrim crashes much less often, and never with that error message.

OS: openSuse 15.2, kernel 5.3.18.
Wine: many versions, from 4.11 through 6.12, both Proton and regular wine
dxvk: from 0.96 through 1.9.
nvidia driver: 440.100 works; newer, up through at least 460.84, cause the crash with this error message.
gpu: gtx 660

I just had a crash in Skyrim with the 440.100 driver (kernel 5.3.18, dxvk 1.9, wine 6.13, gtx 660):

err:   DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST
err:   DxvkDevice: waitForIdle: Operation failed
err:   DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST
err:   DxvkDevice: waitForIdle: Operation failed
err:   DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST
err:   DxvkDevice: waitForIdle: Operation failed
err:   DxvkSubmissionQueue: Failed to sync fence: VK_ERROR_DEVICE_LOST
err:   DxvkSubmissionQueue: Command submission failed: VK_ERROR_DEVICE_LOST

I’ve probably played Skyrim more than 500 hours now with the 440.100 driver, and this is the first time I’ve gotten the error message. With newer drivers, on the other hand, I probably see this error about twice an hour. So it’s still far more stable with 440.100 than with newer drivers.

So the error is possible with the 440.100 driver; it’s just very rare.