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

Should have a way of telling whether backend is supported #2783

nicbn opened this issue May 28, 2019 · 2 comments


None yet
3 participants
Copy link

commented May 28, 2019

Using latest cargo release of gfx (0.2)

I'm testing vulkan backend in an old laptop with onboard Intel graphics - therefore no Vulkan support. When calling instance.enumerate_adapters, it will panic with Unable to enumerate adapters: ERROR_INITIALIZATION_FAILED.
The problems are:

  1. There is no way to tell whether the backend is supported (without using any external tools) before calling the function.
  2. The function panics instead of returning a result, therefore one can't recover from the error as easily.

By addressing either one of these issues, an application could switch between backends if it detects that the default backend is unsupported without having to unwind panics (which is slow and not ergonomic), but the best would be having both these issues addressed.

I'm new to gfx so please tell me if there's anything that I'm missing.


This comment has been minimized.

Copy link

commented May 29, 2019

I think we can get away with simply returning an empty Vec, plus logging the error code in this case. There isn't much value in switching that API entry point to return a Result<>, I think.

@kvark kvark removed the api: hal label Jun 26, 2019


This comment has been minimized.

Copy link

commented Jun 26, 2019

Outline for completion:

  1. Check for successful completion of Vulkan's raw enumerate_adapters call here
    let devices = unsafe { self.raw.0.enumerate_physical_devices() }
  2. If not successful, return an empty Vec
  3. Make sure that this function doesn't have other opportunities for panic that are unrecoverable in this context and instead just returns an empty vec
  4. Look through the other backends' enumerate_adapters implementations and ensure the same thing as in 3

Feel free to ping me on GitHub, Discord, or in our Gitter channel ( if you need help :)

bors bot added a commit that referenced this issue Jul 12, 2019

Merge #2902
2902: Fix recovery of failed enumeration of physical devices r=kvark a=dpmkl

Fixes #2783
PR checklist:
- [x] `make` succeeds (on *nix)
- [x] `make reftests` succeeds
- [x] tested examples with the following backends: vulkan
- [ ] `rustfmt` run on changed code
I looked through all other backends and could not find any other obvious unrecoverable aborts. 

Co-authored-by: Michael Craggs <>

@bors bors bot closed this in #2902 Jul 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.