bevy
bevy copied to clipboard
bevyengine
Panic in bevy_render when acquiring next swapchain texture
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.
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
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.
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?
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 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
@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_cubesandpbrexamples) work perfectly with both drivers - 2D scenes seem to be hit-or-miss.
spritedoesn't work on AMDVLK whilemany_spritesdoes. - Everything seems to work on RADV
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?
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.
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
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)
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.
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)
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.
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").
It would help if people who can reproduce the issue could run wgpu's examples and see if it happens there as well.
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.
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.
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).
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
I'm running kernel 5.15.12 and still get the problem reliably with AMDVLK still. I'm fully updated.
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.
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
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
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
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.
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!
Same issue here, also solved by setting AMD_VULKAN_ICD=RADV. I'm using a Radeon RX 570.
