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

Allow wgpu backend to be configured from the environment #1042

Merged
merged 1 commit into from
Dec 22, 2020

Conversation

agorgl
Copy link
Contributor

@agorgl agorgl commented Dec 10, 2020

Multiple backends for wgpu can be available in a system.
Allow force changing the default pick through an environment variable.

This should be useful for setting the backend BackendBit::GL that will allow us to access gfx-backend-gl backend of gfx.

@mockersf
Copy link
Member

hello 👋

Currently configuration is mostly done through Resource. There is one for WgpuRenderer, WgpuOptions, why not use it?

then in your app you could do

App::build().add_resource(WgpuOptions {
  backend: "gl", // this is not yet implemented, and could be an enum rather than a string
  ..Default::default()
})

@agorgl
Copy link
Contributor Author

agorgl commented Dec 10, 2020

Because its up to the user to choose in which backend to run, we do not want it a compile time option.
For example a setup that supports both vulkan and opengl and has a bad vulkan driver could use this to override bevy wgpu backend on ALL bevy based games.

@cart
Copy link
Member

cart commented Dec 10, 2020

Some random assorted thoughts:

  1. Being able to easily override the backend in a built app is definitely useful (mainly for developers)
  2. I do think backend configuration should live in WgpuOptions (and that it should be an enum). We can override WgpuOptions values from env variables, but the data should be passed into the renderer via WgpuOptions. It should be a way for devs (or knowledgeable users) to request a single, specific backend they know they want to run.
  3. Users shouldn't ever need to specify backends manually to make an app work. This should be handled by wgpu's backend selection logic, and if its not, we should work with them to make that happen. If users need to set environment variables to make a game work (or even select a "compatible" backend from a settings menu), we have already failed. Thats not something we can expect the average user to know / care about.
  4. I think we can get the desired "gl/dx11 fallback behavior" by setting the "backend bit" to BackendBit::PRIMARY | BackendBit::SECONDARY instead of just PRIMARY. We should probably set that as the default asap.

For the enum, I'm thinking it should be something like:

struct WgpuOptions {
  backend: WgpuBackend,
}

enum WgpuBackend {
  Default, // BackendBit::Primary | BackendBit::Secondary
  Vulkan, // BackendBit::Vulkan
  Gl, // BackendBit::Gl
  ...
}

@Moxinilian Moxinilian added C-Feature A new feature, making something new possible A-Rendering Drawing game state to the screen labels Dec 10, 2020
@agorgl
Copy link
Contributor Author

agorgl commented Dec 13, 2020

Yep totally agreed. I'm making some PRs on gfx-rs/gfx-backend-gl and I think we are gonna be able to run the basic examples from bevy with OpenGL backend pretty soon

@agorgl agorgl force-pushed the wgpu_environment_backend branch from 8de1f56 to 18a454a Compare December 17, 2020 18:13
@agorgl
Copy link
Contributor Author

agorgl commented Dec 17, 2020

Made the changes. Did not set the secondary flag to the backend bit, as these indicate in-progress backends from the wgpu-rs/gfx team.

@agorgl agorgl force-pushed the wgpu_environment_backend branch from 18a454a to d16240e Compare December 17, 2020 18:26
@cart
Copy link
Member

cart commented Dec 22, 2020

Looks good to me!

@cart cart merged commit dd668c1 into bevyengine:master Dec 22, 2020
@fopsdev fopsdev mentioned this pull request Jan 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Feature A new feature, making something new possible
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants