Bug 103538

Running Wayland on Gnome 3 if that helps.

That backtrace looks a lot like the issue for which I originally wrote https://patchwork.freedesktop.org/patch/183215/. Unfortunately it looks like it's harder than that.

Also seen this issue now on Xorg. Also observed with the new AMD open driver, could be an Xorg bug?

Care to do a simple crucible test [1]? Devs might be more tempted if there's a simple reproducer ;-)

[1] https://cgit.freedesktop.org/mesa/crucible/

(In reply to Emil Velikov from comment #4)
> Care to do a simple crucible test [1]? Devs might be more tempted if there's
> a simple reproducer ;-)
> 
I'd be tempted, but isn't crucible headless? This is a WSI issue.

Hmm it seems to be - thanks for the correction. Might be worth poking the devs if they're OK with the idea of having WSI tests.

This might not be a bug after all. The app destroyed the X window before tearing down the swapchain, which is bogus, and probably where the deadlock comes from. It stopped once it was done properly.

(In reply to maister from comment #7)
> This might not be a bug after all. The app destroyed the X window before
> tearing down the swapchain, which is bogus, and probably where the deadlock
> comes from.
It's what triggers the deadlock, yes, but I also think that's a scenario that's supposed to work.

No, that's not guaranteed to work. If the app destroys the X11 window before calling vkDestroySwapchainKHR, then the X connection may recycle the window's XID between the two calls, causing havoc. The manpage for XDestroyWindow says this: "The window should never be referenced again" after destruction.

Even though that XDestroyWindow-before-vkDestroySwapchainKHR is not guaranteed to work, deadlock is still an undesirable outcome. Maybe there is a way for Mesa to avoid the deadlock.

(In reply to Chad Versace from comment #9)
> No, that's not guaranteed to work. If the app destroys the X11 window before
> calling vkDestroySwapchainKHR, then the X connection may recycle the
> window's XID between the two calls, causing havoc.
Yeah, there's that. Ultimately it's not up to the application whether the X11 window goes away or not though. If the window manager is nice it'll send a WM_DELETE_WINDOW before the fact, but that's up to the window manager; the application may only get a DestroyNotify after the window is already gone. I think it would be unfortunate if the Vulkan WSI was unable to handle that scenario.

As far as the Vulkan spec is concerned, in the version of the spec I have here (1.0.68) there doesn't seem to be any language specifically about the lifetime of the xcb/X11 window. The closest reference I found was "Several WSI functions return VK_ERROR_SURFACE_LOST_KHR if the surface becomes no longer available." in 30.2.10, "Platform-Independent Information", which seems to suggest that's how the Vulkan WSI should handle the native window going away, but it hardly sounds like any kind of guarantee. The spec doesn't explicitly require the native window to stay available either though.

> Even though that XDestroyWindow-before-vkDestroySwapchainKHR is not
> guaranteed to work, deadlock is still an undesirable outcome. Maybe there is
> a way for Mesa to avoid the deadlock.
https://patchwork.freedesktop.org/patch/183215/ has some discussion about the issue. In short though, the xcb_poll_for_special_event() in x11_manage_fifo_queues() may never return if the window was destroyed before the present request completed. Avoiding that by instead using xcb_poll_for_special_event() risks introducing random stuttering. I think the suggested xcb_wait_for_special_event_with_timeout() would work, but that would require introducing new XCB API, which is a bit more effort than I personally care for at the moment.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/176.