Bevy application doesn't terminate upon window close when using AMDVLK Vulkan driver #10260
Labels
C-Bug
An unexpected or incorrect behavior
O-Linux
Specific to the Linux desktop operating system
S-Needs-Design
This issue requires design work to think about how it would best be accomplished
Comments
robojeb
added
C-Bug
alice-i-cecile
added
O-Linux
|
Very interesting: I've seen this issue reported for Linux before, but this is by far the best investigation I've seen. Not entirely sure what should be done to fix this though 🤔 |
|
The issue does reproduce with I grabbed a single threaded stack trace from Its getting stuck deep in the AMDVLK code, so it might be their issue? Unless wgpu is doing something "non conforming" when destroying the swapchain, that other drivers handle better. For now I will probably just go back to using |
|
I created a minimal example that can control the issue by changing the window use bevy::{prelude::*, window::PresentMode};
fn main() {
App::new()
.add_plugins(DefaultPlugins.set(WindowPlugin {
primary_window: Some(Window {
present_mode: PresentMode::AutoNoVsync, /* Works */
..default()
}),
..default()
}))
.run();
}The issue only reproduces with Interestingly, the issue does not reproduce running I haven't been able to narrow down what Bevy is doing that causes FIFO mode to apparently deadlock when the swap-chain is destroyed. |
|
@alice-i-cecile I think I have narrowed the issue. In I think that Bevy might be violating the WGPU surface docs on this, from here
But Bevy will always destroy the It isn't clear why other drivers handle this more gracefully. |
|
Known issue. I've tried several times to solve it, but stopped, since for me, since the pipelined rendering change, it stopped happening altogether. See the already opened issues:
If it is really what you describe, I'm hyped. All I can say. |
|
Thanks for bringing together all the prior issues. It heartens me that #839 and #1908 have stack-traces which show the stall occurring during swap-chain destruction. |
|
I built and installed the The issue is most definitely caused by closing the Internally the Because the background thread never advances in its loop, it fails to process a So the root cause is: Bevy --[blocks on]--> amdvlk worker --[waiting for event from]--> XorgWhile it could be argued that the I put together a prototype which stores an Atomic token in the main app World to back-channel information from the Render World about the state of the This is the most minimal change that I could think of, but is somewhat of a hack. Edit: I think this issue should be tagged with |
alice-i-cecile
added
S-Needs-Design
Merged
|
#13236 fixes this. |
github-merge-queue bot
pushed a commit
that referenced
this issue
May 12, 2024
# Objective Fixes two issues related to #13208. First, we ensure render resources for a window are always dropped first to ensure that the `winit::Window` always drops on the main thread when it is removed from `WinitWindows`. Previously, changes in #12978 caused the window to drop in the render world, causing issues. We accomplish this by delaying despawning the window by a frame by inserting a marker component `ClosingWindow` that indicates the window has been requested to close and is in the process of closing. The render world now responds to the equivalent `WindowClosing` event rather than `WindowCloseed` which now fires after the render resources are guarunteed to be cleaned up. Secondly, fixing the above caused (revealed?) that additional events were being delivered to the the event loop handler after exit had already been requested: in my testing `RedrawRequested` and `LoopExiting`. This caused errors to be reported try to send an exit event on the close channel. There are two options here: - Guard the handler so no additional events are delivered once the app is exiting. I ~considered this but worried it might be confusing or bug prone if in the future someone wants to handle `LoopExiting` or some other event to clean-up while exiting.~ We are now taking this approach. - Only send an exit signal if we are not already exiting. ~It doesn't appear to cause any problems to handle the extra events so this seems safer.~ Fixing this also appears to have fixed #13231. Fixes #10260. ## Testing Tested on mac only. --- ## Changelog ### Added - A `WindowClosing` event has been added that indicates the window will be despawned on the next frame. ### Changed - Windows now close a frame after their exit has been requested. ## Migration Guide - Ensure custom exit logic does not rely on the app exiting the same frame as a window is closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bevy version
Mainline Bevy
git+https://github.com/bevyengine/bevy.git#66f72dd25bb9e3f3d035f2f14dcbcd25674f968c
[Optional] Relevant system information
EndeavourOS
Rust: 1.75-nightly
Broken adapter info:
What you did
Ran Bevy with the
AMDVLKVulkan driver, and closed the game window.What went wrong
The game window closes, but the application continues to run until
ctrl+cAdditional information
Forcing the
vulkan-radeondriver using environment variables makes the issue go away.So this issue appears to only be related to the
AMDVLKdriver option.The text was updated successfully, but these errors were encountered: