Vulkan/X11: rendering device Unable to acquire framebuffer after Linux virtual console switch

[eswartz]

Tested versions

• Reproducible in master [bb6b06c]
• Reproducible in 4.3dev3

System information

Godot v4.3.dev (67d08f8f1) - Debian GNU/Linux trixie/sid trixie - X11 - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 3080 Ti (nvidia) - AMD Ryzen 7 5800X 8-Core Processor (16 Threads)

Issue description

When I am using the Godot editor and switch virtual consoles (i.e., to the text console, not anything in X11), the Vulkan rendering driver falls over immediately (I tested by piping output to a text file). The editor does not recover when I switch back to X11.

• The errors reported arising from this look different before and after Acyclic Command Graph for Rendering Device #84976, so I assume it's the same bug in a different form.

• Not sure if this belongs in [Tracker] Vulkan error unable to create swapchain (device lost) happening randomly #71929 because it's not random -- happens 100% for me.

Currently, I get:

ERROR: Condition "err != VK_SUCCESS" is true. Returning: FAILED
   at: command_queue_execute_and_present (drivers/vulkan/rendering_device_driver_vulkan.cpp:2214)
... repeats N times ...
ERROR: Unable to acquire framebuffer.
   at: screen_prepare_for_drawing (servers/rendering/rendering_device.cpp:3199)

(repeats)

In 4.3dev3, I got:

ERROR: Vulkan: Cannot submit graphics queue. Error code: VK_ERROR_DEVICE_LOST
   at: swap_buffers (drivers/vulkan/vulkan_context.cpp:2571)
ERROR: Vulkan: Did not create swapchain successfully. Error code: VK_NOT_READY
   at: prepare_buffers (drivers/vulkan/vulkan_context.cpp:2491)

(repeats)

Steps to reproduce

For context, I run into this in "real life" while using the editor and running a project containing an infinite loop -- due to using MOUSE_MODE_CONFINED, I can't use the mouse or keyboard to stop or kill the processes. Using virtual console lets me kill the project binary. Unfortunately, with this bug, I also have to kill the editor too.

But these steps can reproduce the issue much more simply:

• Occurs in Forward+ or Mobile modes, but not Compatibility (obviously)
• Run Godot editor. (Need to open some project; the project manager itself will not exhibit the bug. It seems that empty 3D view on startup is enough.)
• Switch to a virtual terminal (i.e. Ctrl-Alt-F1)
• Switch back to X11 (Ctrl-Alt-F7 usually, or a larger Fkey if some setups)
• Godot UI hangs and console is repeating the kinds of errors reported here.

Minimal reproduction project (MRP)

Does not depend on project other than its Rendering mode, so this is VERY minimal :)

Empty3D.zip

[Calinou]

Can you reproduce this in 4.2.1?

[eswartz]

Can you reproduce this in 4.2.1?

Yes:

ERROR: Vulkan: Did not create swapchain successfully. Error code: VK_NOT_READY
   at: prepare_buffers (drivers/vulkan/vulkan_context.cpp:2459)
ERROR: Vulkan: Cannot submit graphics queue. Error code: VK_ERROR_DEVICE_LOST
   at: swap_buffers (drivers/vulkan/vulkan_context.cpp:2536)

etc.

[Calinou]

This might be a variation of #52738, which we can't fix on our end without large sweeping changes.

[clayjohn]

Reading a bit about switching to the virtual terminal, it sounds like it actually closes your x-session, which would explain why Godot loses the Vulkan context.

Can you check another Vulkan application and see if it exhibits the same behaviour?

[eswartz]

Oh, indeed it does. When I run vkcube, it runs fine, until I switch terminals:

$ vkcube
Selected GPU 0: NVIDIA GeForce RTX 3080 Ti, type: DiscreteGpu
... upon switching ...
vkcube: ./cube/cube.c:1133: demo_draw: Assertion `!err' failed.
Aborted

I think Godot is the only Vulkan app I use! ;)

[eswartz]

Thanks for checking this out. I thought I was finding a variation on the other mentioned bugs and didn't even think it might be a general nvidia driver issue. I can just apply a local patch to abort() here. I never see those errors in normal usage, AFAIK.

[eswartz]

Should I close this issue? The local patch works fine for me, but of course that's not likely to be a good solution in general.

[Calinou]

Exiting the engine on DEVICE_LOST errors (or even automatically restarting) is something we should probably do in the long run, since there's no real point in keeping the engine running in this situation.

If we do this, the user needs to be informed somehow, most likely using an OS.alert() dialog or a desktop notification.

[MarioBossReal]

Posting this here since it seems related:

ERROR: Condition "err != VK_SUCCESS" is true. Returning: FAILED
at: command_queue_execute_and_present (drivers/vulkan/rendering_device_driver_vulkan.cpp:2214)
ERROR: Unable to acquire framebuffer.
at: (servers/rendering/rendering_device.cpp:3199)

I'm getting this issue after moving a project from 4.2.1 stable mono to 4.3 dev 4 mono. It seems to occur when a certain amount of lights appear on screen in the editor viewport (a normal amount of lights). The editor will just freeze and the external console will be spammed with this error, requiring the editor to be closed. I've never experienced this issue in the latest stable editor so it seems to be some sort of regression? I'm running Windows 10 Pro 64 bit, Nvidia Gtx 1080.

Edit: I'm not sure if its to do with the number of lights, but it's definitely to do with lights since when I disable all lights this problem does not occur.

[Zireael07]

IIRC there is a separate issue for the general 'unable to acquire framebuffer' problem.

This one is very specific