Some limits don't need to be configurable

[kainino0x]

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:

1. Remove some limits from GPUSupportedLimits+requiredLimits, and instead expose their base values as const values (e.g. GPUSupportedLimits.minMaxThing or GPUBaseLimits.maxThing)
   • Limits can be added to GPUSupportedLimits+requiredLimits later.
2. Make some limits "unconfigurable": keep them on GPUSupportedLimits, but disallow them from being specified as keys in the requiredLimits record<>. (Notably this prevents passing a GPUSupportedLimits object into requiredLimits.)
   • Limits can be changed from "unconfigurable" to "configurable" later.
3. 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

[kainino0x]

I am currently leaning toward option 2 + constructible GPUSupportedLimits, but 3 is ok too.

[kainino0x]

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]

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]

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

Editors resolution: Option 3, normative.

[kainino0x]

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

Limit name	Default	Configurable?	Notes
maxTextureDimension1D	8192	y
maxTextureDimension2D	8192	y
maxTextureDimension3D	2048	y
maxTextureArrayLayers	256	y
maxBindGroups	4	n?	limit 4 on all android
maxDynamicUniformBuffersPerPipelineLayout	8	y?
maxDynamicStorageBuffersPerPipelineLayout	4	y?
maxSampledTexturesPerShaderStage	16	y?
maxSamplersPerShaderStage	16	y?
maxStorageBuffersPerShaderStage	8	?
maxStorageTexturesPerShaderStage	4	y?
maxUniformBuffersPerShaderStage	12	y?
maxUniformBufferBindingSize	16384	y?	might be able to raise to 64k? #803
maxStorageBufferBindingSize	128 MiB	y
minUniformBufferOffsetAlignment	256	n
minStorageBufferOffsetAlignment	256	n
maxVertexBuffers	8	n?
maxVertexAttributes	16	n?
maxVertexBufferArrayStride	2048	n?
maxInterStageShaderComponents	60	n
maxComputeWorkgroupStorageSize	16352	y
maxComputeInvocationsPerWorkgroup	256	y
maxComputeWorkgroupSizeX	256	y
maxComputeWorkgroupSizeY	256	y
maxComputeWorkgroupSizeZ	64	y
maxComputeWorkgroupsPerDimension	65535	y
max color attachments	8	n?	in practice never goes over 8

[Kangz]

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.

maxBindGroups

It is at least 8 on most desktop GPUs so I think we might want to keep it configurable.

maxInterStageShaderComponents

We probably want this to be configurable, the limit seems kinda low.

maxUniformBufferBindingSize

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.

maxColorAttachments

Compat would probably have 4, so it will be a limit eventually.

[kainino0x]

Compat would probably have 4, so it will be a limit eventually.

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]

maxUniformBufferBindingSize

According to the gpuinfo.org data, bumping this to 64k loses support for zero devices!
Opened #2159.