Screen blanking causes panic on Linux/X11 #4579
Labels
A-Rendering
Drawing game state to the screen
C-Bug
An unexpected or incorrect behavior
O-Linux
Specific to the Linux desktop operating system
P-Crash
A sudden unexpected crash
Comments
mdickopp
added
C-Bug
|
Seems similar to #3380 . |
|
I observe sometimes, but not always, that the framerate drops before the panic occurs. Here is a log excerpt: |
|
Does this also occur on the wgpu examples? |
DJMcNab
added
A-Rendering
No, it does not. One of the wgpu examples does not run at all, indicating it needs a feature not supported by my hardware ( |
|
I'm not very familiar with wgpu (or low-level graphics APIs, for that matter), so please take the following with a grain of salt. I could track down the issue to this timeout in wgpu. If I modify it from 1 second to 10 seconds, the panic occurs only if I blank the screen for more than 10 seconds. Taking a wild guess that treating a timeout like a changed surface instead of panicking might help, I tried this modification: --- a/crates/bevy_render/src/view/window.rs
+++ b/crates/bevy_render/src/view/window.rs
@@ -152,7 +152,7 @@ pub fn prepare_windows(
let frame = match surface.get_current_texture() {
Ok(swap_chain_frame) => swap_chain_frame,
- Err(wgpu::SurfaceError::Outdated) => {
+ Err(wgpu::SurfaceError::Outdated | wgpu::SurfaceError::Timeout) => {
render_device.configure_surface(surface, &swap_chain_descriptor);
surface
.get_current_texture()With this change, the issue no longer occurs. (Even if this is not the correct fix, maybe it can provide hints to people with more expertise than me in this area.) |
|
Maybe the reason the issue does not occur with the wgpu examples is that they call |
sak96
added a commit
to sak96/rust_paint
that referenced
this issue
May 22, 2022
This was referenced Sep 12, 2022
|
I can reproduce this bug on an Intel GPU as well. |
ItsDoot
pushed a commit
to ItsDoot/bevy
that referenced
this issue
Feb 1, 2023
# Objective - Fix bevyengine#3606 - Fix bevyengine#4579 - Fix bevyengine#3380 ## Solution When running on a Linux machine with some AMD or Intel device, when calling `surface.get_current_texture()`, ignore `wgpu::SurfaceError::Timeout` errors. ## Alternative An alternative solution found in the `wgpu` examples is: ```rust let frame = surface .get_current_texture() .or_else(|_| { render_device.configure_surface(surface, &swap_chain_descriptor); surface.get_current_texture() }) .expect("Error reconfiguring surface"); window.swap_chain_texture = Some(TextureView::from(frame)); ``` See: <https://github.com/gfx-rs/wgpu/blob/94ce76391b560a66e36df1300bd684321e57511a/wgpu/examples/framework.rs#L362-L370> Veloren [handles the Timeout error the way this PR proposes to handle it](gfx-rs/wgpu#1218 (comment)). The reason I went with this PR's solution is that `configure_surface` seems to be quite an expensive operation, and it would run every frame with the wgpu framework solution, despite the fact it works perfectly fine without `configure_surface`. I know this looks super hacky with the linux-specific line and the AMD check, but my understanding is that the `Timeout` occurrence is specific to a quirk of some AMD drivers on linux, and if otherwise met should be considered a bug. Co-authored-by: Carter Anderson <mcanders1@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bevy version
main branch, commit 46acb77.
Operating system & version
Linux (Debian 12 “Bookworm”), X11
Xfce 4.16 with light-locker as the screensaver
AMD Radeon RX 590 Series (POLARIS10, DRM 3.44.0, 5.16.0-6-amd64, LLVM 13.0.1)
What you did
present_mode: bevy::window::PresentMode::Fifo.sleep 1; light-locker-command -a. (The purpose ofsleep 1is to prevent the release of the return key when issuing the command from deactivating the screen blanking immediately.)What you expected to happen
The program should still be running.
What actually happened
The program panics with message “Failed to acquire next swap chain texture!: Timeout” in
bevy_render/src/view/window.rs:161.Additional information
Log:
This issue does not occur when
present_mode: bevy::window::PresentMode::Mailboxorpresent_mode: bevy::window::PresentMode::Immediateis used.The text was updated successfully, but these errors were encountered: