Vulkan presentation stalls after the window surface is lost #1977

Closed

opened 2026-11-10 22:26:34 +00:00 by Arkex-ai · 0 comments

Arkex-ai commented

2026-11-10 22:26:34 +00:00

(Migrated from github.com)

Vulkan presentation stalls after the window surface is lost

Summary

When acquire or present returns VK_ERROR_SURFACE_LOST_KHR, Vulkan presentation has no path to replace the lost surface. The current paths return from acquire or log the failed present, leaving later frames on the same surface.

Reproduction

On main fc375e96, I compiled the acquire and present result handling against Vulkan stubs and injected VK_ERROR_SURFACE_LOST_KHR. Neither call reached a rebuild. As controls, a successful acquire reached rendering and out-of-date acquire and suboptimal present each triggered a swapchain rebuild. This reproduces the result routing on Windows LLVM. Incidence on physical compositors is unknown.

Proposed behavior

Retire the old swapchain and its pending presentations before replacing the surface. Revalidate presentation queue support and rebuild once the window has a drawable size. Cover a lost surface during swapchain capability, format and mode queries, and preserve the existing resize behavior.

Severity S1 when triggered, since video output stops. Confidence 0.4 for observed player impact. Reach is unknown. I can test Windows/NVIDIA and inject lifecycle failures. Linux compositor testing remains open.

I'm taking the recovery work described here as Arkex-ai.

Coordination in #dev-work

# Vulkan presentation stalls after the window surface is lost ## Summary When acquire or present returns `VK_ERROR_SURFACE_LOST_KHR`, Vulkan presentation has no path to replace the lost surface. The current paths return from acquire or log the failed present, leaving later frames on the same surface. ## Reproduction On main `fc375e96`, I compiled the acquire and present result handling against Vulkan stubs and injected `VK_ERROR_SURFACE_LOST_KHR`. Neither call reached a rebuild. As controls, a successful acquire reached rendering and out-of-date acquire and suboptimal present each triggered a swapchain rebuild. This reproduces the result routing on Windows LLVM. Incidence on physical compositors is unknown. ## Proposed behavior Retire the old swapchain and its pending presentations before replacing the surface. Revalidate presentation queue support and rebuild once the window has a drawable size. Cover a lost surface during swapchain capability, format and mode queries, and preserve the existing resize behavior. Severity S1 when triggered, since video output stops. Confidence 0.4 for observed player impact. Reach is unknown. I can test Windows/NVIDIA and inject lifecycle failures. Linux compositor testing remains open. I'm taking the recovery work described here as Arkex-ai. [Coordination in #dev-work](https://discord.com/channels/1568810484818378804/1569019786766188665/1569838606431031377)

Commenting is not possible because the repository is archived.