Repository navigation
Some limits don't need to be configurable #1865
Description
There are a number of limits which are useful for applications to be able to check, but which are not actually very useful to configure.
Take as an example maxVertexBufferArrayStride. In Vulkan, this limit can vary, but setting it to any value other than 2048 seems very niche:
- On Windows, it appears NVIDIA is always 2048, Intel is almost always 4095, and AMD is almost always 16383.
- On Android, only a few random devices (AMD, Intel, ImgTec) have values other than 2048.
The editors discussed this, and considered some possible approaches:
- Remove some limits from
GPUSupportedLimits+requiredLimits, and instead expose their base values asconstvalues (e.g.GPUSupportedLimits.minMaxThingorGPUBaseLimits.maxThing)- Limits can be added to
GPUSupportedLimits+requiredLimitslater.
- Limits can be added to
- Make some limits "unconfigurable": keep them on
GPUSupportedLimits, but disallow them from being specified as keys in therequiredLimitsrecord<>. (Notably this prevents passing a GPUSupportedLimits object intorequiredLimits.)- Limits can be changed from "unconfigurable" to "configurable" later.
- Specify a list of limits for which the browser "must" or "should" only expose the base values on all adapters. This would leave them "configurable" but would only allow one configuration value (we clamp limits which are worse than the base), while reducing fragmentation. Alternatively this list can be de facto across browsers.
- Limits can be removed from this list later.
For 2/3, also consider making GPUSupportedLimits constructible (without args) to provide the default limits, or exposing them in some other way.
Related: #1343
Reacted by Dzmitry Malyshau
Activity
kainino0x commentedon Jun 21, 2021
I am currently leaning toward option 2 + constructible GPUSupportedLimits, but 3 is ok too.
kainino0x commentedon Jun 28, 2021
from meeting: @toji and I leaning toward option 3 as it rolls into the API surface we already have, instead of making it more complicated. Option 2 effectively requires apps to feature-detect to avoid providing keys that the browser doesn't like (in a non-obvious way - can't just check that it's available in adapter.features).
TBD whether there's really a need for programmatically surfacing the default limits.
kainino0x commentedon Jun 28, 2021
I thought of a reason that the spec should normatively specify which limits are configurable and which are not: this way we only have to write tests for behavior of configuring some limits. Otherwise, theoretically, the CTS needs to attempt to configure every single limit, and test the behavior with the limit configured - when in fact many of these tests would never even be able to run.
(Regardless, the CTS still needs to test behaviors against the unconfigurable limits. And if we make this normative, it also needs to test that the unconfigurable limits are not configurable, but that's easy.)
Kangz commentedon Jun 29, 2021
+1 for option 3: it is useful to developers but clearly says that a limit is not configurable. It also easily allows transitioning a limit from unconfigurable to configurable if we want it later. (maxColorAttachments for example?)
kainino0x commentedon Jul 12, 2021
Editors resolution: Option 3, normative.
kainino0x commentedon Sep 27, 2021
Here's a first pass at which limits should be configurable with help from @toji.
https://docs.google.com/spreadsheets/d/1PfIUyDo5wB37_w1D1h3N2JB4IjXXzziAUNLmsL5O6Y4/edit?usp=sharing
Kangz commentedon Sep 28, 2021
I'm not sure what's the value on preventing a limit from being configurable: if a browser doesn't think it is useful to configure a limit, then it can always expose the base value. The only additional burden is that the CTS would need to try to configure each limit. That seems pretty small.
It is at least 8 on most desktop GPUs so I think we might want to keep it configurable.
We probably want this to be configurable, the limit seems kinda low.
We can probably raise, it is a very small fraction of Android in number of devices. However we should check D3D12 and Metal first.
Compat would probably keep 16k though.
Compat would probably have 4, so it will be a limit eventually.
kainino0x commentedon Oct 1, 2021
Probably when we spec this it won't be worded as "unconfigurable" but simply as "adapter must not expose a better limit than this", which is compatible with compat. (And it wouldn't add any new errors in requestDevice.)
kainino0x commentedon Oct 1, 2021
According to the gpuinfo.org data, bumping this to 64k loses support for zero devices!
Opened #2159.
Kangz commentedon Dec 14, 2021
Seems like we can encode these unconfigurable limits in the spec?
wewindy commentedon Jan 22, 2022
Kangz commentedon Jan 22, 2022
kainino0x commentedon May 23, 2022
I chatted with @litherum about this issue today and he asked a useful question: What is the value of this change to developers? And I had trouble answering that. There would be some value in saying a limit will never become configurable. But if we can change it at any time, all it's doing is enforcing a little consistency across browsers/devices - e.g. rather than having one browser report the an alignment of 256, and another surfacing an alignment of 64 from the backend.
Realistically I don't think it makes any useful dent in the consistency problem. That will be better solved by the bucketing we want to do for fingerprinting anyway (bucketing devices with similar limits so we don't expose the differences in limits between them).
So at this moment, I'm thinking an actual spec change isn't worth it here, and instead we should add non-normative notes about specific interesting things, like the fact that no current devices have maxColorAttachments>8.
kainino0x commentedon Jul 16, 2022
On second thought even this is probably not that worthwhile, as it would be hard to guess which of these will continue to be true for a long time (e.g. maxColorAttachments capping out at 8) and which will probably change (e.g. maxBindGroups being 4 on almost all Android devices).
So the agenda item for the editors meeting is whether we should just go ahead and close this.
kainino0x commentedon Jul 18, 2022
editor meeting decided to close.