Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

supports_queue_family assertion fails, possibly because of two different gpus #543

Closed
Nejat opened this issue Mar 30, 2020 · 5 comments · Fixed by #545
Closed

supports_queue_family assertion fails, possibly because of two different gpus #543

Nejat opened this issue Mar 30, 2020 · 5 comments · Fixed by #545
Labels
type: bug Something isn't working

Comments

@Nejat
Copy link

Nejat commented Mar 30, 2020

I first ran across this while running the provided examples in the coffee project using the vulkan feature ...

thread 'main' panicked at 'assertion failed: suf.supports_queue_family(&adapter.raw.queue_families[0])', /home/nejat/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/device.rs:2059:9

the examples work while using the opengl feature

Seeing that the assertion failure was in the wgpu-native crate, I went back to test a program I wrote using the Pixels project, which also depends on the same crate, and the project that was working before now has the same exact assertion failure as above.

There is one change in the system I'm using that might help point to what is causing this issue, but I have not been able to debug it.

Originally I had a single RTX 2080 ti when my Pixels based application worked. I recently added a second GPU, a Radeon Pro WX 5100.

Is it possible the existence of two GPUs might be the cause of the assertion failure?

This is all on Pop!_OS 19.10

@kvark
Copy link
Member

kvark commented Mar 30, 2020

Thank you for filing! That's a tough issue here, and we need a good plan for that together with @Kangz. When you are requesting an adapter, we don't know what surface you'd want to use it with, so it may end up incompatible with the surface.
We could provide a way to find out if a surface can be used with this adapter, but we also need a way to let you pick the right one. So we may need something like a list of surfaces passed in (or at least a single surface), to which an adapter has to be able to present to, at the time an adapter is requested...
Filed webgpu-native/webgpu-headers#39 to discuss an upstream solution.

@kvark kvark added the type: bug Something isn't working label Mar 30, 2020
@Nejat
Copy link
Author

Nejat commented Mar 30, 2020

Excuse me if I'm over simplifying it, I do not mean to trivialize the complexity of the issue, especially knowning that Vulkan provides a much lower level interface, however could the answer be found in how OpenGL or DX12 handle the issue?

Not only does the OpenGL version initialize on this machine with two different GPUs, I can drag the window from one GPU display to the other.

Just a thought.

@kvark
Copy link
Member

kvark commented Mar 30, 2020

@Nejat I can tell you how :)

  • OpenGL doesn't allow you to create a device without a surface to begin with
  • DX12 and Vulkan have an explicit check for a surface being compatible with an adapter, and they expose all adapters at once

Since WebGPU API is shaped as "request an adapter", we'll be checking for compatibility with a surface at that moment, and we need to know which surface you want to use it with.

@Nejat
Copy link
Author

Nejat commented Mar 30, 2020

@kvark Thank you for the clarification

@kvark
Copy link
Member

kvark commented Apr 1, 2020

Fixed by #545

@kvark kvark closed this as completed Apr 1, 2020
kvark added a commit to kvark/wgpu that referenced this issue Jun 3, 2021
543: Don't use `log` crate in include_spirv r=kvark a=kvark

Fixes  gfx-rs#541

Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants