Panic in bevy_render when acquiring next swapchain texture

[Herbstein]

Bevy version

0.6

Operating system & version

Manjaro Gnome (Wayland)

What you did

Tried to run the button UI example, then tried to run the most basic piece of rendering Bevy code:

use bevy::prelude::*;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .run();
}

What you expected to happen

A blank window with the default clear color.

What actually happened

A panic when acquiring "next swapchain texture". The specific panic message:

thread 'main' panicked at 'Failed to acquire next swap chain texture!: Timeout', /home/<user>/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.6.0/src/view/window.rs:161:24

Additional information

When running with the default windowing config (X11 through winit) the application hangs after closing the window, while it "destroys 2 command encoders" and exists properly when enabling Wayland in bevy_winit. The log below is with Wayland enabled. Only the last log line is different on X11.

The full log at the INFO level:

2022-01-09T12:59:35.490450Z  INFO wgpu_hal::vulkan::instance: Instance version: 0x4020ca    
2022-01-09T12:59:35.490504Z  INFO wgpu_hal::vulkan::instance: Enabling debug utils    
2022-01-09T12:59:35.490562Z  INFO wgpu_hal::vulkan::instance: Enabling device properties2    
2022-01-09T12:59:35.499823Z  INFO wgpu_core::instance: Adapter Vulkan AdapterInfo { name: "AMD Radeon RX 5700 XT", vendor: 4098, device: 29471, device_type: DiscreteGpu, backend: Vulkan }    
2022-01-09T12:59:35.499880Z  INFO bevy_render::renderer: AdapterInfo { name: "AMD Radeon RX 5700 XT", vendor: 4098, device: 29471, device_type: DiscreteGpu, backend: Vulkan }
2022-01-09T12:59:35.499913Z  WARN wgpu_core::instance: Feature MAPPABLE_PRIMARY_BUFFERS enabled on a discrete gpu. This is a massive performance footgun and likely not what you wanted    
2022-01-09T12:59:35.501677Z  INFO wgpu_hal::vulkan::instance: GENERAL [Loader Message (0x0)]
	Loading layer library libVkLayer_khronos_validation.so    
2022-01-09T12:59:35.501697Z  INFO wgpu_hal::vulkan::instance: 	objects: (type: INSTANCE, hndl: 0x5575ec046ee0, name: ?)    
2022-01-09T12:59:35.501710Z  INFO wgpu_hal::vulkan::instance: GENERAL [Loader Message (0x0)]
	Inserted device layer VK_LAYER_KHRONOS_validation (libVkLayer_khronos_validation.so)    
2022-01-09T12:59:35.501724Z  INFO wgpu_hal::vulkan::instance: 	objects: (type: INSTANCE, hndl: 0x5575ec046ee0, name: ?)    
2022-01-09T12:59:35.501746Z  INFO wgpu_hal::vulkan::instance: GENERAL [Loader Message (0x0)]
	/usr/lib32/amdvlk32.so: wrong ELF class: ELFCLASS32    
2022-01-09T12:59:35.501762Z  INFO wgpu_hal::vulkan::instance: 	objects: (type: INSTANCE, hndl: 0x5575ec046ee0, name: ?)    
2022-01-09T12:59:35.501775Z  INFO wgpu_hal::vulkan::instance: GENERAL [Loader Message (0x0)]
	Loading layer library /usr/lib/amdvlk64.so    
2022-01-09T12:59:35.501788Z  INFO wgpu_hal::vulkan::instance: 	objects: (type: INSTANCE, hndl: 0x5575ec046ee0, name: ?)    
2022-01-09T12:59:35.501802Z  INFO wgpu_hal::vulkan::instance: GENERAL [Loader Message (0x0)]
	Failed to find vkGetDeviceProcAddr in layer /usr/lib/amdvlk64.so    
2022-01-09T12:59:35.501815Z  INFO wgpu_hal::vulkan::instance: 	objects: (type: INSTANCE, hndl: 0x5575ec046ee0, name: ?)    
2022-01-09T12:59:35.501828Z  INFO wgpu_hal::vulkan::instance: GENERAL [Loader Message (0x0)]
	Loading layer library libVkLayer_MESA_device_select.so    
2022-01-09T12:59:35.501841Z  INFO wgpu_hal::vulkan::instance: 	objects: (type: INSTANCE, hndl: 0x5575ec046ee0, name: ?)    
2022-01-09T12:59:35.501854Z  INFO wgpu_hal::vulkan::instance: GENERAL [Loader Message (0x0)]
	Failed to find vkGetDeviceProcAddr in layer libVkLayer_MESA_device_select.so    
2022-01-09T12:59:35.501867Z  INFO wgpu_hal::vulkan::instance: 	objects: (type: INSTANCE, hndl: 0x5575ec046ee0, name: ?)    
2022-01-09T12:59:35.503802Z  INFO wgpu_hal::vulkan::adapter: Private capabilities: PrivateCapabilities { flip_y_requires_shift: true, imageless_framebuffers: true, image_view_usage: true, timeline_semaphores: true, texture_d24: false, texture_d24_s8: false, can_present: true, non_coherent_map_mask: 127, robust_buffer_access: true, robust_image_access: true }    
2022-01-09T12:59:35.517292Z  INFO wgpu_core::device: Created texture Valid((0, 1, Vulkan)) with TextureDescriptor { label: None, size: Extent3d { width: 1, height: 1, depth_or_array_layers: 1 }, mip_level_count: 1, sample_count: 1, dimension: D2, format: Bgra8UnormSrgb, usage: COPY_DST | TEXTURE_BINDING }    
2022-01-09T12:59:35.528681Z  INFO wgpu_core::device: Created texture Valid((1, 1, Vulkan)) with TextureDescriptor { label: None, size: Extent3d { width: 1, height: 1, depth_or_array_layers: 1 }, mip_level_count: 1, sample_count: 1, dimension: D2, format: Bgra8UnormSrgb, usage: COPY_DST | TEXTURE_BINDING }    
2022-01-09T12:59:35.599069Z  WARN gilrs_core::platform::platform::gamepad: "/dev/input/event3" doesn't have at least 1 button and 2 axes, ignoring.    
2022-01-09T12:59:35.630673Z  INFO wgpu_core::device: Created buffer Valid((0, 1, Vulkan)) with BufferDescriptor { label: None, size: 16384, usage: COPY_DST | UNIFORM, mapped_at_creation: false }    
2022-01-09T12:59:35.631975Z  INFO wgpu_core::device: configuring surface with SurfaceConfiguration { usage: RENDER_ATTACHMENT, format: Bgra8UnormSrgb, width: 1280, height: 720, present_mode: Fifo }    
2022-01-09T12:59:35.632080Z  INFO wgpu_core::device: Created texture Valid((2, 1, Vulkan)) with TextureDescriptor { label: None, size: Extent3d { width: 1, height: 1, depth_or_array_layers: 1 }, mip_level_count: 1, sample_count: 1, dimension: D2, format: Bgra8UnormSrgb, usage: COPY_DST | TEXTURE_BINDING }    
2022-01-09T12:59:35.633172Z  INFO wgpu_core::device: Created buffer Valid((1, 1, Vulkan)) with BufferDescriptor { label: Some("color_material_uniform_buffer"), size: 32, usage: COPY_DST | UNIFORM, mapped_at_creation: true }    
2022-01-09T12:59:35.633193Z  INFO wgpu_core::device: Created buffer Valid((2, 1, Vulkan)) with BufferDescriptor { label: Some("pbr_standard_material_uniform_buffer"), size: 64, usage: COPY_DST | UNIFORM, mapped_at_creation: true }    
thread 'main' panicked at 'Failed to acquire next swap chain texture!: Timeout', /home/<user>/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.6.0/src/view/window.rs:161:24
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
2022-01-09T12:59:35.698147Z  INFO wgpu_core::hub: Dropping Global    
2022-01-09T12:59:35.709770Z  INFO wgpu_core::device: Destroying 2 command encoders

If it's any help, I can confirm that vkcube works perfectly on the system.

[nyvs]

I have this problem as well with new bevy 0.6

thread 'main' panicked at 'Failed to acquire next swap chain texture!: Timeout', /home/nyvs/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.6.0/src/view/window.rs:161:24 stack backtrace: 0: rust_begin_unwind at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/std/src/panicking.rs:517:5 1: core::panicking::panic_fmt at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/panicking.rs:100:14 2: core::result::unwrap_failed at /rustc/f1edd0429582dd29cccacaf50fd134b05593bd9c/library/core/src/result.rs:1616:5 3: bevy_render::view::window::prepare_windows 4: <bevy_ecs::system::function_system::FunctionSystem<In,Out,Param,Marker,F> as bevy_ecs::system::system::System>::run_unsafe 5: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll 6: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll 7: async_task::raw::RawTask<F,T,S>::run 8: async_executor::LocalExecutor::try_tick 9: std::thread::local::LocalKey<T>::with 10: <bevy_ecs::schedule::executor_parallel::ParallelExecutor as bevy_ecs::schedule::executor::ParallelSystemExecutor>::run_systems 11: <bevy_ecs::schedule::stage::SystemStage as bevy_ecs::schedule::stage::Stage>::run 12: <bevy_render::RenderPlugin as bevy_app::plugin::Plugin>::build::{{closure}} 13: bevy_app::app::App::update 14: bevy_winit::winit_runner_with::{{closure}} 15: winit::platform_impl::platform::x11::EventLoop<T>::run_return 16: winit::platform_impl::platform::x11::EventLoop<T>::run 17: winit::platform_impl::platform::EventLoop<T>::run 18: winit::event_loop::EventLoop<T>::run 19: bevy_winit::run 20: bevy_winit::winit_runner_with 21: core::ops::function::Fn::call 22: bevy_app::app::App::run 23: yasukuni::main

Using arch linux, wayland

[Herbstein]

I tested this on my laptop running Arch Linux on Wayland, where it works perfectly on the integrated Intel GPU. @nyvs which GPU are you trying to run this on? My desktop where this is occurring is running an AMD 5700XT.

[nyvs]

Hello @Herbstein
INFO bevy_render::renderer: AdapterInfo { name: "AMD Radeon RX 6800 XT", vendor: 4098, device: 29631, device_type: DiscreteGpu, backend: Vulkan }
:)
so maybe an amd-specific problem?

[k-brk]

Got similar specs - Arch Linux 5.15.13-arch1-1, RX 5700XT, X11, Bevy 0.6 and it works for me just fine, tried both Vulcan drivers vulkan-radeon and amdvlk.

[nyvs]

how do you switch between vulcan drivers @k-brk ?

[k-brk]

@nyvs I have removed one and installed another via pacman, something like this(or other way around, depending which you have installed)

pacman -R vulkan-radeon
pacman -S amdvlk

[Herbstein]

@nyvs this should find you well: https://wiki.archlinux.org/title/Vulkan#Selecting_Vulkan_driver.

Otherwise, make sure you have the vulkan-radeon and amdvlk packages installed. Use AMD_VULKAN_ICD=RADV cargo run when running a program to force RADV driver to be used. Use AMD_VULKAN_ICD=AMDVLK cargo run to use AMDVLK. Beware that when both drivers are installed amdvlk becomes the default unless you specify otherwise in your environment. The Arch Wiki link has the details. Feel free to reach out if the wiki isn't clear enough. Otherwise do like k-brk and only install the one you prefer.

Some more points on my own troubles:

• Regular 3D scenes (tested the many_cubes and pbr examples) work perfectly with both drivers
• 2D scenes seem to be hit-or-miss. sprite doesn't work on AMDVLK while many_sprites does.
• Everything seems to work on RADV

[nyvs]

Thank you both very much, I played around with AMD_VULKAN_ICD and you are correct, when setting it to RADV, it works perfectly. I uninstalled amdvlk now...

@Herbstein Has changing to RADV solved your problem as well?

[Herbstein]

Yup, solved it completely. Looking at a few benchmarks it seems that RADV is faster than AMDVLK in some tasks and matches it in others. That is gaming-wide tasks, not bevy specific.

The crash is still a problem, however, since AMDVLK is the default installation for a lot of people, and it takes precedence over RADV.

[joshuataylor]

The breakout example works fine for me out of the box:

2022-01-10T11:16:27.598539Z  INFO winit::platform_impl::platform::x11::window: Guessed window scale factor: 1.1666666666666667    
2022-01-10T11:16:27.679990Z  INFO bevy_render::renderer: AdapterInfo { name: "AMD Radeon RX 5600 XT", vendor: 4098, device: 29471, device_type: DiscreteGpu, backend: Vulkan }

But running the above example results in:

2022-01-10T11:14:04.284922Z  INFO winit::platform_impl::platform::x11::window: Guessed window scale factor: 1.1666666666666667    
2022-01-10T11:14:04.354207Z  INFO bevy_render::renderer: AdapterInfo { name: "AMD Radeon RX 5600 XT", vendor: 4098, device: 29471, device_type: DiscreteGpu, backend: Vulkan }
hello world!
thread 'main' panicked at 'Failed to acquire next swap chain texture!: Timeout', /home/josh/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.6.0/src/view/window.rs:161:24

[nyvs]

@joshuataylor which driver do you use?

[joshuataylor]

Not sure regarding driver (I think it's radeon?), but forcing RADV seems to work.

2022-01-10T12:51:51.277637Z INFO winit::platform_impl::platform::x11::window: Guessed window scale factor: 1.1666666666666667
2022-01-10T12:51:51.349149Z INFO bevy_render::renderer: AdapterInfo { name: "AMD RADV NAVI10", vendor: 4098, device: 29471, device_type: DiscreteGpu, backend: Vulkan }

44:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 [Radeon RX 5600 OEM/5600 XT / 5700/5700 XT] (rev ca)

[Herbstein]

Your default driver is AMDVLK. When the AdapterInfo doesn't mention RADV you're using AMDVLK. Uninstall the amdvlk package to default to RADV (AMDVLK takes precedence). Their performance in DXVK is either equal or RADV miles ahead, depending on the game.

Still, bevy shouldn't crash with what is for many people the default installed AMD driver.

[cart]

Can someone running amdvlk try running an example that fails with the Timeout error with vsync disabled to see if that resolves the problem? Wgpu has an open issue that might be related.

App::new()
    .insert_resource(WindowDescriptor {
        vsync: false,
        ..Default::default()
    })
    .add_plugins(DefaultPlugins)

[Herbstein]

Running with vsync: false does indeed remove the problem under amdvlk. I tested the sprite example on the latest master. I also made sure the issue is still present with vsync enabled.

[cart]

Heads up to @kvark: this is probably worth checking out (I linked to a potentially relevant wgpu issue above). #3288 is probably also relevant (see the last comment about "doing more work to avoid a crash").

[ghost]

Thank you setting vsync: false got my project running right

[kvark]

It would help if people who can reproduce the issue could run wgpu's examples and see if it happens there as well.

[Herbstein]

I haven't been able to trigger it any of the examples from wgpu, while testing all PresentMode options. My methodology:

Change the PresentMode in the SurfaceConfiguration created in fn start in wgpu/wgpu/examples/framework.rs, then run every wgpu example in both release and debug mode. All of them ran perfectly.

[kvark]

Could it be just some shader taking abnormally long amount of time to execute? Or going into an infinite loop, confusing the driver, etc? Then we'd see the Timeout error on that shader, and you aren't going to see this on our examples. Reducing the test would help.

[turboMaCk]

Posted to the original issue already but just in case. Since 5.10.91 kernel patch I don't experience this issue. 5.10.88 was last know kernel I had this issue with. I'm using NixOS unstable (don't know what kernel Arch ships).

There is a lot of contradicting information so I'm no longer sure about it. But from my testing of multiple combinations of kernels, hw drivers and vulkan drivers I think the problem was with open source driver and that vsync made the issue worse. From my testing the fix was either to switch to proprietary driver or to update kernel (and thus amdgpu).

[turboMaCk]

Just did another round of testing (vsync enabled) with the same result. amdvlk / radv doesn't make a difference. amdgpu version or amdgpu-pro switch is what causes / fixes the issue for me. Perhaps folks switching vulkan drivers from amdvlk to radv also installed kernel with drm patches? Or maybe switched between drivers (amdgpu / amdgpu-pro) implicitly? Or maybe there this is some intricate issue which depends on multitude of things.

corrections: now trying more times I got to the error with AMDVLK. So I think it makes sense to switch to RADV. You can also have both and switch between them using AMD_VULKAN_ICD = "RADV" / AMD_VULKAN_ICD = "AMDVLK" env var

[Herbstein]

I'm running kernel 5.15.12 and still get the problem reliably with AMDVLK still. I'm fully updated.

[sparky8251]

Kernel 5.12.17, Mesa 21.3.5. Have the same issue with AMDVLK, down to it not being a problem with any of the WGPU examples I've attempted to run. Even verified by removing AMDVLK and ensuring I was only on RADV, and then it worked without disabling vsync.

[imxood]

2022-03-21T13:49:21.082118Z  INFO winit::platform_impl::platform::x11::window: Guessed window scale factor: 1.25    
2022-03-21T13:49:21.143371Z  INFO bevy_render::renderer: AdapterInfo { name: "AMD RADV POLARIS10 (ACO)", vendor: 4098, device: 28639, device_type: DiscreteGpu, backend: Vulkan }
thread 'main' panicked at 'Failed to acquire next swap chain texture!: Timeout', /home/maxu/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_render-0.6.1/src/view/window.rs:161:24
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

WGPU_BACKEND=gl cargo run
this will run successfully

[64kramsystem]

Reporting a failure also on my machine (Ubuntu 20.04, AMD RX 6000 series, latest AMD drivers (21.50)).

Attempts:

• WGPU_BACKEND=gl cargo run --release --example breakout: success
• AMD_VULKAN_ICD=RADV cargo run --release --example breakout: success
• AMD_VULKAN_ICD=AMDVLK cargo run --release --example breakout: crash

[alexpyattaev]

Same failure, AMD GPU, latest driver and software on Arch linux.

• WGPU_BACKEND=gl cargo run #woks fine,
• AMD_VULKAN_ICD=RADV cargo run #works fine,
• AMD_VULKAN_ICD=AMDVLK cargo run #crashes same as for everyone else

[ksf]

Same issue for me. For people wondering about the vsync option: It doesn't exist any more.

This is the default, spelled out explicitly:

fn main() {
    App::new()
        .insert_resource(WindowDescriptor {
            present_mode: bevy::window::PresentMode::Fifo,
            ..Default::default()
        })
        .add_plugins(DefaultPlugins)
        .run();
}

and crashes with a timeout whereas PresentMode::Immediate and PresentMode::Mailbox work. The irony being that Fifo is the fallback behavior as per Vulkan spec.

EDIT: FIFO present mode does work under wayland, but not x11 or xwayland.

[dejaime]

Had this problem as well as detailed in discord thread: https://discord.com/channels/691052431525675048/749690364792668301/983133065834532884

Using AMD_VULKAN_ICD=RADV did indeed solve my issue. I'm using just a 5700G CPU with its iGPU. Thanks bjorn3 and cart!

I'll remove amdvlk for now, but can definitely reinstall it if needed for tests!

[felix-u]

Same issue here, also solved by setting AMD_VULKAN_ICD=RADV. I'm using a Radeon RX 570.

[fatho]

I experience the same symptoms as in the original issue (i.e. `Failed to acquire next swap chain texture!: Timeout'), but only under certain circumstances running on Linux with X11 and an AMD card:

• whenever the screensaver/power saving gets activated (e.g. triggering it manually with xset dpms force off or just idling)
• whenever I try to take a screenshot of the application with ImageMagick's import command

Especially for the first case, I wonder whether a hard crash is the right course of action for such a Timeout, or whether it would be better to just skip those frames until acquiring a surface texture is successful again.

(Setting env-vars such as AMD_VULKAN_ICD=RADV did not have any effect)

[nicopap]

I was about to create a new issue, but adding to this one is better. Here is details on what happens to me

When running my game, using the amdgpu-pro drivers (literally just cargo run) my game crashes as soon as it opens, with the following error:

thread 'main' panicked at 'Failed to acquire next swap chain texture!: Timeout', <cache>/bevy_render-0.8.1/src/view/window.rs:190:24
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This doesn't occur with the default amdgpu drivers. However, amdgpu-pro is required to use the AMD GPU profiler.

Precise steps:

• Launch your game with cargo run (in the case of bevy cargo run --release --example many_cubes)
• See it open and panic immediately :D

Note that if --release flag is not present, it doesn't crash with the bevy examples, I imagine the debug builds for my game crash because I specify:

[profile.dev.package."*"]
opt-level = 2

Environment

bevy: 0.8.1 & 0.9.0-dev (tried lighting, many_cubes, ui, 3d_scene)
OS: Archlinux Kernel: 5.19.5-arch1-1
cpu: amd ryzen 9 3900X 12-Core
gpu: amd radeon rx 5700 xt
driver: vulkan-amdgpu-pro 22.10.3_1420322-1

Working driver is xf86-video-amdgpu 22.0.0-1

Workaround

Setting the present_mode to Immediate fixes it. And anyway I need it to get meaningful information out of the profiler.

        .insert_resource(WindowDescriptor {
            #[cfg(target_os = "linux")]
            present_mode: bevy::window::PresentMode::Immediate,
            ..default()
        })

Solution

The error seems to be in window.rs in the prepare_windows function. Indeed, using a if let Some(frame) instead of panicking does fix the issue. This was already discussed in previous related issues.

Related

A few known issues occur at the same place:

• Screen blanking causes panic on Linux/X11 #4579
• ImageMagick import utility causes examples to panic on Linux #3380