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

wgpu::PowerPreference::HighPerformance works in wgpu-rs but not in bevy #402

Closed
fopsdev opened this issue Aug 31, 2020 · 14 comments
Closed
Labels
A-Rendering Drawing game state to the screen C-Dependencies A change to the crates that Bevy depends on

Comments

@fopsdev
Copy link

fopsdev commented Aug 31, 2020

On my machine the samples doesn't run when adapter is created using wgpu::PowerPreference::HighPerformance
You will find that setting inside crates\bevy_wgpu\src\wgpu_renderer.rs
it works when using this setting in the wgpu-rs samples (https://github.com/gfx-rs/wgpu-rs)
So since bevy is using wgpu there must be something fishy with the device initialisation.
I did some prior work on:
#366 (comment)
to track down this issue. but its a bit beyond me.

btw. i have a amd radeon 500 series and a onboard intel uhd620

@karroffel karroffel added A-Rendering Drawing game state to the screen C-Dependencies A change to the crates that Bevy depends on labels Aug 31, 2020
@CleanCut
Copy link
Member

CleanCut commented Sep 3, 2020

I believe a forked version of wgpu is being used for bevy at the moment. Perhaps there is an upstream fix that we don't have. This is speculation on my part.

Tangentially related, there is an open PR to allow choosing which PowerPreference to use in #397

@fopsdev
Copy link
Author

fopsdev commented Sep 3, 2020

@CleanCut
thanks for linking the pr. it's a workaround for now (i've set already PowerPreference::Default in my version to move on)
i digged a bit in cargo.lock ( i suppose thats the place to check for the packages and versions used in the project)
found:

[[package]]
name = "wgpu"
version = "0.6.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
...
...

looks to me like a regular package of wgpu is used.
i followed the instructions to create a wgpu_trace but the folder is empty after the error. not sure this works on windows though

@CleanCut
Copy link
Member

CleanCut commented Sep 3, 2020

@fopsdev Thanks, that's good to know. I should have just looked at the deps myself instead of lazily relying on fuzzy memories. 😄

@fopsdev
Copy link
Author

fopsdev commented Sep 4, 2020

@cart
imo we should change default back to wgpu::PowerPreference::Default (using #397) as long as this issue isn't fixed.
otherwise new people could have a bad experience at the very start of the bevy journey :)

@Dispersia
Copy link
Contributor

3-4 people a day were reporting an issue with Default being used, without being offensive I have only seen you two report this way being an issue. I think it's good to have that merged in, as people could more easily select default again, but I definitely don't think it should be the regular default again. Just something that needs fixed in wgpu.

@CleanCut
Copy link
Member

@Dispersia I don't have an issue. I'm just helping out where I can.

@Dispersia
Copy link
Contributor

@Dispersia I don't have an issue. I'm just helping out where I can.

I was referring to lee-or (from the previous issue) and fopsdev, sorry I should have been more clear there :)

@CleanCut
Copy link
Member

No worries. Just wanted to make sure I wasn't unintentionally amplifying reports of problems.

@fopsdev
Copy link
Author

fopsdev commented Sep 11, 2020

Just had another case where somebody needed to switch to Default.
Maybe it's just best to wait for a bigger wgpu-s release and then check back on this issue.
(hoping somehow that the bevy initialisation code needs to be changed as well and this issue will be fixed as well)

@cart
Copy link
Member

cart commented Sep 11, 2020

Yeah ideally this just works the "right way" transparently to users. People playing Bevy games shouldn't need to think about "what gpu to use". In general I just want it to use the "best" gpu first (with the most gpu/platform-compatible backend) and then fall back from there to lower power options (also picking the most gpu/platform-compatible backend).

Sorry to ping you @kvark, but I'm assuming that behavior is already your goal and eventually we won't need to care? Should we try to get fancier with our initialization logic or just let wgpu do its thing?

@kvark
Copy link

kvark commented Sep 11, 2020

Please note that if there is no issue on wgpu-rs/wgpu than you can't expect us to work on it.

People playing Bevy games shouldn't need to think about "what gpu to use"

I believe that should be up to Bevy to figure out, not wgpu-rs. There is not really an obviously best default here, it depends on what the intended usage is. wgpu used to depend on battery crate to find out if it makes sense to use the discrete GPU by default, but we removed it. The reason being - users can do it themselves if they need, so perhaps Bevy needs to depend on battery?

On my machine the samples doesn't run

What's happening? what's the call stack? what's the OS?

Also, check if the versions of gfx-backend-xxx used by your Cargo.lock match between the test in Bevy and the test in wgpu-rs. Also please note that published 0.6 version corresponds to https://github.com/gfx-rs/wgpu-rs/tree/v0.6 branch.

@cart
Copy link
Member

cart commented Sep 11, 2020

Please note that if there is no issue on wgpu-rs/wgpu than you can't expect us to work on it.

Noted. At this point its unclear to me that there even is a wgpu-rs issue.

I believe that should be up to Bevy to figure out, not wgpu-rs. There is not really an obviously best default here, it depends on what the intended usage is. wgpu used to depend on battery crate to find out if it makes sense to use the discrete GPU by default, but we removed it. The reason being - users can do it themselves if they need, so perhaps Bevy needs to depend on battery?

We currently use the wgpu::PowerPreference::HighPerformance configuration because I would prefer to use the "fastest" gpu available. In my head, wgpu::PowerPreference determines the sorting algorithm used when picking gpus from the set of available gpus. It seems like if for some reason the "fastest" isn't compatible, then the "second fastest" gpu should be selected, as we have just expressed a "preference".

For cases where PowerPreference::HighPerformance fails, we could certainly write our own own fallback logic to PowerPreference::Default if you think thats the job of wgpu consumers and not wgpu itself.

At least for now, I don't want to get too fancy with using battery state to pick gpus. I'd prefer to just always use the fastest compatible gpu available.

What's happening? what's the call stack? what's the OS?

Yeah we probably should have dug into that a bit further before pulling you in. Sorry about that!

@kvark
Copy link

kvark commented Sep 11, 2020

To clarify, the PowerPreference is a real preference in wgpu-rs. You shouldn't need to fall-back. We are going to be falling back if we can't find this.

My guess about what happened is - one of the gfx backends (maybe Vulkan?) saw the adapter for "radeon 500" but failed to initialize this properly. That's why I recommended to check the actual versions of the backends used. We fixed a few issues in this area as patch releases, which can be gotten as easy as cargo update -p gfx-backend-xxx. And if it's a new issue, we'll definitely make it a priority to fix!

@fopsdev
Copy link
Author

fopsdev commented Sep 17, 2020

Ok i've freshly cloned bevy today (from master)
And now it seems to work :)
Thanks for the help guys

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-Dependencies A change to the crates that Bevy depends on
Projects
None yet
Development

No branches or pull requests

6 participants