No surface found for window. in all examples

[Moggers]

I'm getting a No surface found for window in all examples for master, however if I checkout 0.5.0, this issue does not occur.

Bevy version

72c888feea2d114d6719da515e9859f76e6b1f11 - freshly pulled master

Operating system & version

Arch Linux, 5700XT using amdgpu (mesa 21.2.4-1), testing on sway(wayland) and openbox(x11)

What you did

Briefly...

> git clone https://github.com/bevyengine/bevy.git
> cd bevy
> cargo run --example mesh
> cargo run --example 3d_scene

What you expected to happen

Rendering etc

What actually happened

Seems to render one frame, then crashes out with:

thread 'main' panicked at 'No surface found for window.', crates/bevy_wgpu/src/renderer/wgpu_render_resource_context.rs:372:14

Example of full logs for 3d_scene:

2021-11-27T08:27:27.203322Z  INFO winit::platform_impl::platform::x11::window: Guessed window scale factor: 1.0833333333333333
UNASSIGNED-BestPractices-vkCreateInstance-specialuse-extension-debugging(WARN / SPEC): msgNum: -2111305990 - Validation Warning: [ UNASSIGNED-BestPractices-vkCreateInstance-specialuse-extension-debugging ] Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x822806fa | CreateInstance(): Attempting to enable extension VK_EXT_debug_utils, but this extension is intended to support use by applications when debugging and it is strongly recommended that it be otherwise avoided.
    Objects: 1
        [0] 0, type: 1, name: NULL
UNASSIGNED-BestPractices-vkCreateInstance-deprecated-extension(WARN / SPEC): msgNum: -1861097675 - Validation Warning: [ UNASSIGNED-BestPractices-vkCreateInstance-deprecated-extension ] Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x9111e735 | CreateInstance(): Attempting to enable deprecated extension VK_KHR_get_physical_device_properties2, but this extension has been promoted to VK_VERSION_1_1.
    Objects: 1
        [0] 0, type: 1, name: NULL
2021-11-27T08:27:27.388847Z  INFO naga::front::spv: Generated by 524296 version 10000
2021-11-27T08:27:27.389734Z  INFO naga::front::spv: Patching...
2021-11-27T08:27:27.390096Z  INFO naga::front::spv: Generated by 524296 version 10000
2021-11-27T08:27:27.396150Z  INFO naga::front::spv: Patching...
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x55a690b90ea0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 0 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x55a690b90ea0, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x55a690b90ea0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 1 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x55a690b90ea0, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x55a690b90ea0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 0 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x55a690b90ea0, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x55a690b90ea0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 2 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x55a690b90ea0, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x55a690b90ea0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 0 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x55a690b90ea0, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x55a690b90ea0, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 2 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x55a690b90ea0, type: 3, name: NULL
UNASSIGNED-BestPractices-SuboptimalSwapchain(WARN / PERF): msgNum: 1142383795 - Validation Performance Warning: [ UNASSIGNED-BestPractices-SuboptimalSwapchain ] Object 0: handle = 0x210d07000000003a, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0x441764b3 | vkQueuePresentKHR: VkSwapchainKHR 0x210d07000000003a[] :VK_SUBOPTIMAL_KHR was returned. VK_SUBOPTIMAL_KHR - Presentation will still succeed, subject to the window resize behavior, but the swapchain is no longer configured optimally for the surface it targets. Applications should query updated surface information and recreate their swapchain at the next convenient opportunity.
    Objects: 1
        [0] 0x210d07000000003a, type: 1000001000, name: NULL
thread 'main' panicked at 'No surface found for window.', crates/bevy_wgpu/src/renderer/wgpu_render_resource_context.rs:372:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[alice-i-cecile]

Sounds like something in the wgpu update broke your setup. Could you test out the examples at https://github.com/gfx-rs/wgpu, and experiment with the various branches and/or commits?

The other suggestion I have is to try updating your GPU drivers.

[yilinwei]

Have you tried running with the wayland feature? I notice that you're using the X11 backend while on sway with XWayland. I also get a similar error message when running with the X11 backend.

[Moggers]

Sounds like something in the wgpu update broke your setup. Could you test out the examples at https://github.com/gfx-rs/wgpu, and experiment with the various branches and/or commits?

Haven't been able to repro an issue master or v0.11 of wgpu (which seems to be the version used by bevy), if you have any particular commits, tags, or branches you reckon I should try then shoot.

The other suggestion I have is to try updating your GPU drivers.

Updated mesa to 21.2.5-1, seems to make no difference.

Have you tried running with the wayland feature? I notice that you're using the X11 backend while on sway with XWayland. I also get a similar error message when running with the X11 backend.

Here's the results of running the 3d_scene example with the wayland feature enabled;

 cargo run --features wayland --example 3d_scene
[compile omited]
    Finished dev [unoptimized + debuginfo] target(s) in 32.90s
     Running `target/debug/examples/3d_scene`
UNASSIGNED-BestPractices-vkCreateInstance-specialuse-extension-debugging(WARN / SPEC): msgNum: -2111305990 - Validation Warning: [ UNASSIGNED-BestPractices-vkCreateInstance-specialuse-extension-debugging ] Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x822806fa | CreateInstance(): Attempting to enable extension VK_EXT_debug_utils, but this extension is intended to support use by applications when debugging and it is strongly recommended that it be otherwise avoided.
    Objects: 1
        [0] 0, type: 1, name: NULL
UNASSIGNED-BestPractices-vkCreateInstance-deprecated-extension(WARN / SPEC): msgNum: -1861097675 - Validation Warning: [ UNASSIGNED-BestPractices-vkCreateInstance-deprecated-extension ] Object 0: VK_NULL_HANDLE, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0x9111e735 | CreateInstance(): Attempting to enable deprecated extension VK_KHR_get_physical_device_properties2, but this extension has been promoted to VK_VERSION_1_1.
    Objects: 1
        [0] 0, type: 1, name: NULL
2021-11-27T22:53:44.765174Z  INFO naga::front::spv: Generated by 524296 version 10000
2021-11-27T22:53:44.766125Z  INFO naga::front::spv: Patching...
2021-11-27T22:53:44.766486Z  INFO naga::front::spv: Generated by 524296 version 10000
2021-11-27T22:53:44.772529Z  INFO naga::front::spv: Patching...
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x56481c74cb70, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 0 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x56481c74cb70, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x56481c74cb70, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 1 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x56481c74cb70, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x56481c74cb70, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 0 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x56481c74cb70, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x56481c74cb70, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 2 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x56481c74cb70, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x56481c74cb70, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 0 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x56481c74cb70, type: 3, name: NULL
UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory(WARN / PERF): msgNum: 67123586 - Validation Performance Warning: [ UNASSIGNED-BestPractices-vkCreateRenderPass-image-requires-memory ] Object 0: handle = 0x56481c74cb70, type = VK_OBJECT_TYPE_DEVICE; | MessageID = 0x4003982 | Attachment 2 in the VkRenderPass is a multisampled image with 4 samples, but it uses loadOp/storeOp which requires accessing data from memory. Multisampled images should always be loadOp = CLEAR or DONT_CARE, storeOp = DONT_CARE. This allows the implementation to use lazily allocated memory effectively.
    Objects: 1
        [0] 0x56481c74cb70, type: 3, name: NULL
thread 'main' panicked at 'No surface found for window.', crates/bevy_wgpu/src/renderer/wgpu_render_resource_context.rs:372:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Unfortunately, no dice. I was hopeful because I've had xwayland issues before, but it also wouldn't explain why the same behavior shows under openbox on x11 anyway.

[parasyte]

Is this caused by #3051? Seems suspiciously relevant.

[superdump]

Does this work on current main?