Window thread blocks on instance.request_adapter

[CaesarXInsanium]

I was attempting to follow the LearnWGPU tutorial when I came across a bug in which the window is not responding to any input. The only way to response is to kill it from terminal using Ctrl-c

I have managed to track down the issue to when I request the adapter, from the instance.

In this minimal code sample I tried using the same dependency versions as the tutorial

use pollster;
use wgpu;
use winit::{
    event_loop::EventLoop,
    window::WindowBuilder,
};

fn main() {
    let event_loop = EventLoop::new();
    let window = WindowBuilder::new().build(&event_loop).unwrap();
    let _size = window.inner_size();

    let instance = wgpu::Instance::new(wgpu::Backends::all());
    let surface = unsafe { instance.create_surface(&window) };
    println!("Created Surface");
    // code thread is locked right here,
    let _adapter = pollster::block_on(instance.request_adapter(&wgpu::RequestAdapterOptions {
        power_preference: wgpu::PowerPreference::default(),
        compatible_surface: Some(&surface),
        force_fallback_adapter: false,
    }));
    // this message is not printed
    println!("Created adapter");
}

Expected vs observed behavior Supposed to reach the "Created Adapter" message in this code sample, but in my main wgpu tutorial project the window is supposed to function normally and respond to all events.

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

Platform Arch Linux Linux Yor 5.18.12-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Fri, 15 Jul 2022 15:33:04 +0000 x86_64 GNU/Linux Running an RX 6600

[cwfitzgerald]

Could you run this in a debugger to figure out what function it's stuck inside?

[CaesarXInsanium]

I had to run Ctrl-c in order to get this. Is this what you where asking for?

>>> where
#0  0x00007ffff7d82c3f in poll () from /usr/lib/libc.so.6
#1  0x00007ffff7f9f20b in ?? () from /usr/lib/libxcb.so.1
#2  0x00007ffff7f9f8e1 in ?? () from /usr/lib/libxcb.so.1
#3  0x00007ffff7fa08d6 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
#4  0x00007ffff7fa5da4 in xcb_get_extension_data () from /usr/lib/libxcb.so.1
#5  0x00007ffff7fa5f86 in xcb_send_request_with_fds64 () from /usr/lib/libxcb.so.1
#6  0x00007ffff7fa671e in xcb_send_request () from /usr/lib/libxcb.so.1
#7  0x00007ffff773325c in xcb_dri3_open () from /usr/lib/libxcb-dri3.so.0
#8  0x00007fffe883101f in ?? () from /usr/lib/libVkLayer_MESA_device_select.so
#9  0x00007ffff7110dcf in ?? () from /usr/lib/amdvlk64.so
#10 0x00007ffff777715e in vkEnumeratePhysicalDevices () from /usr/lib/libvulkan.so.1
#11 0x0000555555af9ed3 in ash::instance::{impl#4}::enumerate_physical_devices::{closure#0} (count=0x7fffffffbfc4, data=0x0) at /home/cxi/.cargo/registry/src/github.com-1ecc6299db9ec823/ash-0.37.0+1.3.209/src/instance.rs:444
#12 0x0000555555ae8fab in ash::prelude::read_into_uninitialized_vector<u32, ash::vk::definitions::PhysicalDevice, ash::instance::{impl#4}::enumerate_physical_devices::{closure_env#0}> (f=...) at /home/cxi/.cargo/registry/src/github.com-1ecc6299db9ec823/ash-0.37.0+1.3.209/src/prelude.rs:38
#13 0x0000555555af9e74 in ash::instance::Instance::enumerate_physical_devices (self=0x555555e05680) at /home/cxi/.cargo/registry/src/github.com-1ecc6299db9ec823/ash-0.37.0+1.3.209/src/instance.rs:443
#14 0x0000555555a5bc24 in wgpu_hal::vulkan::instance::{impl#4}::enumerate_adapters (self=0x555556a3ce78) at /home/cxi/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-hal-0.13.2/src/vulkan/instance.rs:688
#15 0x00005555559c2fd1 in wgpu_core::instance::{impl#6}::request_adapter::gather<wgpu_hal::vulkan::Api, core::marker::PhantomData<wgpu_core::id::Id<wgpu_core::instance::Adapter<wgpu_hal::empty::Api>>>> (instance=..., inputs=0x7fffffffda98, compatible_surface=..., force_software=false, device_types=0x7fffffffd668) at /home/cxi/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-core-0.13.2/src/instance.rs:685
#16 0x0000555555a133ff in wgpu_core::hub::Global<wgpu_core::hub::IdentityManagerFactory>::request_adapter<wgpu_core::hub::IdentityManagerFactory> (self=0x555556a3ce60, desc=0x7fffffffda88, inputs=...) at /home/cxi/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-core-0.13.2/src/instance.rs:715
#17 0x00005555559f933c in wgpu::backend::direct::{impl#3}::instance_request_adapter (self=0x555556a3ce60, options=0x7fffffffe1b0) at /home/cxi/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.13.1/src/backend/direct.rs:865
#18 0x00005555559a9ab3 in wgpu::Instance::request_adapter (self=0x7fffffffe118, options=0x7fffffffe1b0) at /home/cxi/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.13.1/src/lib.rs:1731
#19 0x00005555556215ca in wgputest::main () at src/main.rs:16

[cwfitzgerald]

Absolutely! Do other vulkan applications (vkcube) work? Maybe the ash examples? If it's hanging inside libxcb, I'm not sure if we can do anything about it.

[CaesarXInsanium]

VKcube runs fine.

In the ash repo, winit example gives this when I run Ctrl-c.

[0] from 0x00007ffff7d125ac in recvmsg
[1] from 0x00007ffff7f9e8e9
[2] from 0x00007ffff7fa0bf7 in xcb_poll_for_reply64
[3] from 0x00007ffff7acf1a9
[4] from 0x00007ffff7ad2412 in _XEventsQueued
[5] from 0x00007ffff7aade51 in XCheckIfEvent
[6] from 0x00005555556269dd in winit::platform_impl::platform::x11::event_processor::EventProcessor<()>::poll_one_event<()>+189 at /home/cxi/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.26.1/src/platform_impl/linux/x11/event_processor.rs:105
[7] from 0x00005555555eca0c in winit::platform_impl::platform::x11::EventLoop<()>::drain_events<(), winit::main::{closure_env#0}>+156 at /home/cxi/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.26.1/src/platform_impl/linux/x11/mod.rs:404
[8] from 0x00005555555eba71 in winit::platform_impl::platform::x11::EventLoop<()>::run_return<(), winit::main::{closure_env#0}>+481 at /home/cxi/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.26.1/src/platform_impl/linux/x11/mod.rs:278
[9] from 0x00005555555ecf06 in winit::platform_impl::platform::x11::EventLoop<()>::run<(), winit::main::{closure_env#0}>+54 at /home/cxi/.cargo/registry/src/github.com-1ecc6299db9ec823/winit-0.26.1/src/platform_impl/linux/x11/mod.rs:392

The triangle example is super weird. It is stuck in a loop printing this message

INFO:
GENERAL [Loader Message (0)] :      Original order:

INFO:
GENERAL [Loader Message (0)] :            [0] AMD RADV DIMGREY_CAVEFISH

INFO:
GENERAL [Loader Message (0)] :            [1] AMD Radeon RX 6600

INFO:
GENERAL [Loader Message (0)] :      Sorted order:

INFO:
GENERAL [Loader Message (0)] :            [0] AMD RADV DIMGREY_CAVEFISH

INFO:
GENERAL [Loader Message (0)] :            [1] AMD Radeon RX 6600

INFO:
GENERAL [Loader Message (0)] : linux_read_sorted_physical_devices:

INFO:
GENERAL [Loader Message (0)] :      Original order:

Over and over again. I run it with timeout 5 cargo run --bin triangle and I already have almost 1000 lines of scrollback.

Texture example same thing.

The generator example panics.

I tried both the main branch and 0.37 for ash. Same thing.

[nicopap]

I think https://github.com/bevyengine/bevy/issues/5524 might be a symptom of this