Conversation
andyleiserson
force-pushed
the
jj-push-qtxq
branch
2 times, most recently
from
170bc92 to
f052d0f
Compare
wgpu-core/src/limits.rs
Outdated
| }; | ||
|
|
||
| // e.g. Apple M Series | ||
| const M1: Tier = Tier { |
There was a problem hiding this comment.
Could we make the const names more readable, even if we want to keep any user visible names short?
There was a problem hiding this comment.
Any naming suggestions? I had avoided using the brand names on a general principle of avoiding using brand names when possible, and also because confusion could result when a device lands in a tier for the "wrong" brand. (I'm not opposed to naming them with the full brands, just curious if you have any other suggestions.)
There was a problem hiding this comment.
If the tiers we come up with can apply to multiple GPUs/backends I think just TIER_X would be ideal.
teoxoy
left a comment
teoxoy
left a comment
There was a problem hiding this comment.
Overall feedback: I think it would be ideal if the building blocks (ex: current UPLEVEL) for tiers were always less capable than the tier they are building. I had to keep going back and forth to check if a limit is being lowered in a tier compared to UPLEVEL.
| is_fallback_adapter: bool, | ||
|
|
||
| subgroup_min_size: u32, | ||
| subgroup_max_size: u32, |
There was a problem hiding this comment.
Currently Firefox's vendor, architecture, device and description are empty. It might be nice if the tier contained strings for them (if they don't reveal additional information). Not blocking though.
There was a problem hiding this comment.
The values we report to content are empty, but we have the data. The logic that reports empty values to content is in dom::webgpu::AdapterInfo. In https://phabricator.services.mozilla.com/D286387 I capture the telemetry in wgpu_bindings, so it gets the real values. about::support also gets the real values.
I'm not sure I understand what you mean by "might be nice if the tier contained [the device info]" though. Do you mean recording the "e.g." devices listed in comments on the definitions in the structure itself?
There was a problem hiding this comment.
Do you mean recording the "e.g." devices listed in comments on the definitions in the structure itself?
Yes, I was imagining that we can report something to content rather than empty strings (if they don't reveal additional information) if we have buckets specifically for amd/nvidia/apple silicon also considering that content can most likely check how the GPU samples to figure out the vendor at the very least.
There was a problem hiding this comment.
I haven't done anything about this question. I don't think the limit bucket names will work very well as an architecture proxy, whether that manifests now (no-f16, which has both AMD and NVIDIA) or later (when we change the buckets). So my preference would be to leave this as-is, and address it in #8649.
|
On naming: The name "tier" implies an ordering, maybe we should use the term "bucket" instead. Some buckets can have an order but we will have diverging sets. |
andyleiserson
force-pushed
the
jj-push-qtxq
branch
2 times, most recently
from
a3e3699 to
7492652
Compare
Thoughts on this? I found myself tripping up saying "adapter tiering". The spec also uses the term "bucket" for this. |
andyleiserson
force-pushed
the
jj-push-qtxq
branch
from
62cb4fa to
48c12dc
Compare
|
The latest push renames it from tiers to buckets. |
andyleiserson
force-pushed
the
jj-push-qtxq
branch
from
48c12dc to
de48476
Compare
|
Ah sorry I shouldn't have resolved the changelog conflict via GH's UI since this is supposed to be rebased. |
|
If you want you can also add clip distances to the M1 bucket, see #9270. |
Co-authored-by: Teodor Tanasoaia <28601907+teoxoy@users.noreply.github.com>
andyleiserson
force-pushed
the
jj-push-qtxq
branch
from
54c5e4e to
4d0fbe9
Compare
3 participants
Related Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1979753
To make it harder to use WebGPU for fingerprinting, we want to report limit values that are quantized to a set of pre-defined buckets, rather than raw limit values that are likely to have more entropy that is useful for fingerprinting.
This change implements tiered limit support. Tiered limits are requested by a new
apply_limit_tiersflag inRequestAdapterOptions. By default that flag isfalseand limits are not modified by the tiering logic.There is a module comment in the new
wgpu_core::limitsmodule that explains limit tiering in more depth.I determined the tiers by crunching a bunch of data from gpuinfo and collected at https://webgpu-limits.netlify.app/. I am not sure how best to capture/preserve the analysis tooling for future use, I'm open to suggestions. For more detail of the tiers, see the
tiers.htmlattachment on the linked bug.Testing
Adds a directed test suite.
Squash or Rebase? Rebase
Checklist
log::info!todebug!.CHANGELOG.mdentry.