[Merged by Bors] - bevy_render: Support overriding wgpu features and limits #3912
Conversation
Supports explicitly enabling/disabling features, and constraining limits to 'less' than what they could be.
superdump
added
A-Rendering
| features -= disabled_features; | ||
| } | ||
| // NOTE: |= is used here to ensure that any explicitly-enabled features are respected. | ||
| options.features |= features; |
There was a problem hiding this comment.
I'm thinking that we should make WgpuOptions a "read only" configuration item. Users shouldn't be reading these settings to get "actual" values, they should be querying the device. And writing on top like this makes it hard to talk about what these values mean. Buuuut given that these changes are going into a patch release, we should probably hold off on that.
There was a problem hiding this comment.
I was thinking from the beginning that it’s a bit sketchy to reuse WgpuOptions to present the configured state after using it but it also isn’t used after init otherwise.
As regards this specific thing… we could have a private field with the final result or a separate resource so that WgpuOptions is used for configuration and WgpuCapabilities or some good name is what you can actually use. Both practically read only. But how do you even mark something as read-only? I didn’t know you could?
There was a problem hiding this comment.
In terms of "read only config", that ties into the conversation here: #2988
At the very least, I think it makes sense to "generally" treat plugin settings as "immutable after insertion", even though we don't have that functionality yet.
There was a problem hiding this comment.
plz also consider making plugin settings freeze when read https://discord.com/channels/691052431525675048/692572690833473578/941182628499947520
This means you can:
- reconfigure settings before it is read by plugin
- disallow changing settings after it is read, so avoiding user confusion
- plugin can change to "reactive" settings when it want to support it, without changing it's API
Also compare to the proposed changes, this is a very minimal change (requires add world.freeze_resource)
|
bors r+ |
# Objective - Support overriding wgpu features and limits that were calculated from default values or queried from the adapter/backend. - Fixes #3686 ## Solution - Add `disabled_features: Option<wgpu::Features>` to `WgpuOptions` - Add `constrained_limits: Option<wgpu::Limits>` to `WgpuOptions` - After maybe obtaining updated features and limits from the adapter/backend in the case of `WgpuOptionsPriority::Functionality`, enable the `WgpuOptions` `features`, disable the `disabled_features`, and constrain the `limits` by `constrained_limits`. - Note that constraining the limits means for `wgpu::Limits` members named `max_.*` we take the minimum of that which was configured/queried for the backend/adapter and the specified constrained limit value. This means the configured/queried value is used if the constrained limit is larger as that is as much as the device/API supports, or the constrained limit value is used if it is smaller as we are imposing an artificial constraint. For members named `min_.*` we take the maximum instead. For example, a minimum stride might be 256 but we set constrained limit value of 1024, then 1024 is the more conservative value. If the constrained limit value were 16, then 256 would be the more conservative.
bors
bot
changed the title
# Objective - Support overriding wgpu features and limits that were calculated from default values or queried from the adapter/backend. - Fixes #3686 ## Solution - Add `disabled_features: Option<wgpu::Features>` to `WgpuOptions` - Add `constrained_limits: Option<wgpu::Limits>` to `WgpuOptions` - After maybe obtaining updated features and limits from the adapter/backend in the case of `WgpuOptionsPriority::Functionality`, enable the `WgpuOptions` `features`, disable the `disabled_features`, and constrain the `limits` by `constrained_limits`. - Note that constraining the limits means for `wgpu::Limits` members named `max_.*` we take the minimum of that which was configured/queried for the backend/adapter and the specified constrained limit value. This means the configured/queried value is used if the constrained limit is larger as that is as much as the device/API supports, or the constrained limit value is used if it is smaller as we are imposing an artificial constraint. For members named `min_.*` we take the maximum instead. For example, a minimum stride might be 256 but we set constrained limit value of 1024, then 1024 is the more conservative value. If the constrained limit value were 16, then 256 would be the more conservative.
Objective
Solution
disabled_features: Option<wgpu::Features>toWgpuOptionsconstrained_limits: Option<wgpu::Limits>toWgpuOptionsWgpuOptionsPriority::Functionality, enable theWgpuOptionsfeatures, disable thedisabled_features, and constrain thelimitsbyconstrained_limits.wgpu::Limitsmembers namedmax_.*we take the minimum of that which was configured/queried for the backend/adapter and the specified constrained limit value. This means the configured/queried value is used if the constrained limit is larger as that is as much as the device/API supports, or the constrained limit value is used if it is smaller as we are imposing an artificial constraint. For members namedmin_.*we take the maximum instead. For example, a minimum stride might be 256 but we set constrained limit value of 1024, then 1024 is the more conservative value. If the constrained limit value were 16, then 256 would be the more conservative.