When running the examples on Vulkan on an AMD 6900 XT, `surface.get_current_texture()` times out the first time each frame

[expenses]

Description

I'm running a setup where I have a laptop with an integrated GPU a (Intel(R) Xe Graphics (TGL GT2), connected to a AMD Radeon RX 6900 XT in turn connected to an external display.

I'm running this on (Arch) Linux with Wayland, but this happens with X11 too.

I don't have any problems running the examples normally, as this defaults to the integrated GPU. When I run the examples with WGPU_ADAPTER_NAME=AMD though, I get a timeout every frame:

[2022-08-04T20:44:51Z INFO  wgpu_core::device] configuring surface with SurfaceConfiguration { usage: RENDER_ATTACHMENT, format: Bgra8UnormSrgb, width: 956, height: 500, present_mode: Fifo }
[2022-08-04T20:44:52Z ERROR cube::framework] A timeout was encountered while trying to acquire the next frame
[2022-08-04T20:44:52Z INFO  wgpu_core::device] configuring surface with SurfaceConfiguration { usage: RENDER_ATTACHMENT, format: Bgra8UnormSrgb, width: 956, height: 500, present_mode: Fifo }
[2022-08-04T20:44:52Z ERROR cube::framework] A timeout was encountered while trying to acquire the next frame
[2022-08-04T20:44:52Z INFO  wgpu_core::device] configuring surface with SurfaceConfiguration { usage: RENDER_ATTACHMENT, format: Bgra8UnormSrgb, width: 956, height: 500, present_mode: Fifo }
[2022-08-04T20:44:52Z ERROR cube::framework] A timeout was encountered while trying to acquire the next frame
[2022-08-04T20:44:52Z INFO  wgpu_core::device] configuring surface with SurfaceConfiguration { usage: RENDER_ATTACHMENT, format: Bgra8UnormSrgb, width: 956, height: 500, present_mode: Fifo }
[2022-08-04T20:44:52Z ERROR cube::framework] A timeout was encountered while trying to acquire the next frame
[2022-08-04T20:44:52Z INFO  wgpu_core::device] configuring surface with SurfaceConfiguration { usage: RENDER_ATTACHMENT, format: Bgra8UnormSrgb, width: 956, height: 500, present_mode: Fifo }
[2022-08-04T20:44:52Z ERROR cube::framework] A timeout was encountered while trying to acquire the next frame
[2022-08-04T20:44:52Z INFO  wgpu_core::device] configuring surface with SurfaceConfiguration { usage: RENDER_ATTACHMENT, format: Bgra8UnormSrgb, width: 956, height: 500, present_mode: Fifo }
[2022-08-04T20:44:52Z ERROR cube::framework] A timeout was encountered while trying to acquire the next frame
[2022-08-04T20:44:52Z INFO  wgpu_core::device] configuring surface with SurfaceConfiguration { usage: RENDER_ATTACHMENT, format: Bgra8UnormSrgb, width: 956, height: 500, present_mode: Fifo }
[2022-08-04T20:44:52Z ERROR cube::framework] A timeout was encountered while trying to acquire the next frame
[2022-08-04T20:44:52Z INFO  wgpu_core::device] configuring surface with SurfaceConfiguration { usage: RENDER_ATTACHMENT, format: Bgra8UnormSrgb, width: 956, height: 500, present_mode: Fifo }
[2022-08-04T20:44:52Z ERROR cube::framework] A timeout was encountered while trying to acquire the next frame

The only change I've made to the source code is logging the error:

diff --git a/wgpu/examples/framework.rs b/wgpu/examples/framework.rs
index 0d8ed6df..7df445d5 100644
--- a/wgpu/examples/framework.rs
+++ b/wgpu/examples/framework.rs
@@ -361,7 +361,8 @@ fn start<E: Example>(
 
                 let frame = match surface.get_current_texture() {
                     Ok(frame) => frame,
-                    Err(_) => {
+                    Err(error) => {
+                        log::error!("{}", error);
                         surface.configure(&device, &config);
                         surface
                             .get_current_texture()

This happens on both the amdvlk and amdvlk-pro drivers.

It seems like this isn't meant to happen, but it doesn't seem to make the performance worse than expected.

Extra materials Zip-compressed API traces and GPU captures can also land here.

Here's a log with RUST_LOG=trace:

log.zip

Platform

OS: Arch Linux x86_64 5.18.15-arch1-2 Window Manager: sway version 1.7 CPU: 11th Gen Intel i7-1165G7 (8) @ 4.700GHz See the links above for vulkan.gpuinfo.org device reports.

[Friz64]

1. How does Mesa/RADV behave? This is the Vulkan driver most commonly used with AMD GPUs. Make sure vulkan-radeon is installed and run with WGPU_ADAPTER_NAME=RADV.

2. Is this a duplicate of #1218?

[expenses]

1. How does Mesa/RADV behave? This is the Vulkan driver most commonly used with AMD GPUs. Make sure vulkan-radeon is installed and run with WGPU_ADAPTER_NAME=RADV.

It didnt happen when that driver was used.

2. Is this a duplicate of [Fifo present mode occasionally returns VK_TIMEOUT without blocking in wgpu-rs examples on certain systems #1218](https://github.com/gfx-rs/wgpu/issues/1218)?

This is most likely a duplicate of that issue, yeah. I'll test it out with MAILBOX to confirm soon.

[koderja]

Ran into this as well. Few extra tidbits:

1. Triggered on 5700G integrated graphics with amdvlk driver, so might be connected to the AMD driver (or their driver just easily triggers the bug).
2. Only occurs for me with opt-level = 3, not with any lower.
3. Does not manifest when certain vulkan layers are loaded, e.g. RenderDoc.

[nicopap]

We've been hitting this on bevy for a while:

• https://github.com/bevyengine/bevy/issues/3606
• https://github.com/bevyengine/bevy/issues/4579
• https://github.com/bevyengine/bevy/issues/3380
• https://github.com/bevyengine/bevy/pull/5957

User report similar issue as well on an Intel Broadwell integrated GPU (couldn't reproduce with a Whiskey Lake).

I think there is a few other related issues, but I can't find them now.

[meisme-dev]

I have this issue with an NVIDIA card on Linux, ash and vkcube work fine so I'm pretty sure this is a wgpu problem. Edit: This happens with both Fifo and Immediate

[TheFoon]

Any updates on this?

I am learning wgpu and noticed this issue when trying out this example. It seems to go away for me when I switch from PresentMode::Fifo to Immediate or Mailbox.

Running Arch Linux 6.2.10-arch1-1 on an AMD Ryzen 7 3700X CPU and Radeon RX 5700XT GPU

[Friz64]

@TheFoon The easiest way out for now is to install Mesa's RADV Vulkan driver (available on Arch Linux as vulkan-radeon), which is by far the most widely used and supported driver and apparently does not exhibit this issue. It's also best to make sure to uninstall other Vulkan drivers so they don't get accidentally selected, for which an overview can be found on the Arch Wiki.