thread panic when creating surface

[simonthalen]

Hi I have been enjoying wgpu and wgpu-py for a while. Recently getting back to it I'm unable to run it. Any time I try to run any example (except compute_noop.py which doesn't use surface) I get the following:

thread` '<unnamed>' panicked at src/lib.rs:582:5:
Error in wgpuSurfaceConfigure: Validation Error

Caused by:
  Surface does not support the adapter's queue family

stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: wgpu_native::handle_error_fatal
   3: _wgpuSurfaceConfigure
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: failed to initiate panic, error 5

I´m running a Mac M1 if that makes any difference. Anyone familiar with this issue?

[simonthalen]

Forcing WGPU_BACKEND_TYPE=Metal fixed the issue. Do not know why.

[almarklein]

Interesting. Thanks for reporting this.

What does wgpu.gpu.request_adapter_sync().info give when you don't set WGPU_BACKEND_TYPE?

[simonthalen]

I recently played around with Vulkan in Rust so I think the issue is that installing MoltenVK or Vulkan SDK made WGPU default to Vulkan which causes the error. Here is the .info without forcing Metal.

{'vendor':` 'MoltenVK', 'architecture': '', 'device': 'Apple M1', 'description': '1.2.11', 'vendor_id': 4203, 'device_id': 235340295, 'adapter_type': 'IntegratedGPU', 'backend_type': 'Vulkan'}

And here is with forcing Metal:

{'vendor': '', 'architecture': '', 'device': 'Apple M1', 'description': '', 'vendor_id': 0, 'device_id': 0, 'adapter_type': 'IntegratedGPU', 'backend_type': 'Metal'}

I can't understand why Vulkan wouldn't work, though.

[almarklein]

Interesting that Vulkan is preferred over Metal on MacOS. I wonder whether that's intentional.

I can't understand why Vulkan wouldn't work, though.

No, that looks like a bug to me too. We're a bit behind wgpu-core now though, so it may have been fixed upstream.