2006720 - WebGPU: `GPUSupportedLimits.maxStorage{Buffers,Textures}In{Vertex,Fragment}Stage` are unrecognized

Status: ASSIGNED

(Core :: Graphics: WebGPU, defect, P3)

Description

[Erich Gubler [:ErichDonGubler] (he/him)]

See upstream tracking: wgpu#8748

Comment 1

[Erich Gubler [:ErichDonGubler] (he/him)]

Attachment: WIP: Bug 2006720 - fix(webgpu): recognize `maxStorage{Buffers,Textures}In{Vertex,Fragment}Stage` r=#webgpu-reviewers

Comment 2

[Andy Leiserson [:aleiserson]]

Attachment: Bug 2006720 - Expose additional WebGPU limits r=#webgpu-reviewers!

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/af98916ed154
https://hg.mozilla.org/integration/autoland/rev/657c88fb7887
Expose additional WebGPU limits r=webgpu-reviewers,webidl,teoxoy,saschanaz

Comment 4

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/657c88fb7887

Comment 5

[Claas Augner [:claas]]

Are there any parts missing, or should this be marked as fixed in 151?

(Context: https://github.com/mdn/browser-compat-data/pull/29530)

Comment 6

[Andy Leiserson [:aleiserson]]

With the linked patch these limits are now present in the limits struct, but the reported values are cloned from the maxStorageBuffersPerShaderStage and maxStorageTexturesPerShaderStage limits, and attempts to set the In*Stage limits are ignored.

i.e. there's still more to do, this isn't fixed in 151. The change that landed just allows us to support some sites on a best-effort basis.

Comment 7

[Hamish Willee]

FF151 MDN docs work for this can be tracked in https://github.com/mdn/content/issues/43966

For the MDN release note I've indicated support:

The maxStorageBuffersInFragmentStage, maxStorageBuffersInVertexStage, maxStorageTexturesInFragmentStage, and maxStorageTexturesInVertexStage properties are now supported on {{domxref("GPUSupportedLimits")}}, defining the maximum number of storage buffers and textures allowed in the fragment and vertex shader stages.

It sounds like it isn't that clear cut. Are you OK with the above, or can you suggest a more nuanced wording?

Comment 8

[Andy Leiserson [:aleiserson]]

How about:

The maxStorageBuffersInFragmentStage, maxStorageBuffersInVertexStage, maxStorageTexturesInFragmentStage, and maxStorageTexturesInVertexStage properties on {{domxref("GPUSupportedLimits")}} are now partially supported. These properties report the value of the maxStorageBuffersPerShaderStage and maxStorageTexturesPerShaderStage limits. When creating a device, requested values for the *In*Stage limits are ignored.

https://github.com/mdn/browser-compat-data/pull/29531 had the follow-up change to BCD to indicate partial instead of full support.

Comment 9

[Andy Leiserson [:aleiserson]]

Removing my assignment, the partial support here was incidental to other work I was doing, I am not actively working on completing the support.

Comment 10

[Jim Blandy :jimb]

Erich, on Monday we discussed the way "create a new device" raises maxStorage{Buffers,Textures}In{Vertex,Fragment}Stage to maxStorage{Buffers,Textures}PerShaderStage, and we thought it was unusual that an implementation would not respect the limits requested by the user in the GPUDeviceDescriptor. I asked Kai Ninomiya about this, and he reminded me that "create new device" always raises every limit to at least its default value (for the requested feature level, which is always "core" for us). So raising limit values per se is not unusual.

What is unusual is that requesting an above-default value for ...In{Vertex,Fragment}Stage at the "core" feature level actually raises all three limits for the given type. But the intent is that, in "core", the only limit that actually matters, and the only limit users should be setting, is the unified ...PerShaderStage. Once the normalization steps in "create a new device" have been carried out, Firefox should be able to behave as if that's the only limit that matters.