Bevy: wgpu::PowerPreference::HighPerformance works in wgpu-rs but not in bevy

[fopsdev]

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:
https://github.com/bevyengine/bevy/issues/366#issuecomment-683587669
to track down this issue. but its a bit beyond me.

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

[CleanCut]

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 https://github.com/bevyengine/bevy/pull/397

[fopsdev]

@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]

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

[fopsdev]

@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]

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]

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

[Dispersia]

@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]

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

[fopsdev]

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]

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]

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]

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]

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]

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