Skip to content

Conversation

@Jiawei-Shao
Copy link
Contributor

@Jiawei-Shao Jiawei-Shao commented Apr 16, 2025

  • Supports below new texture formats with the RENDER_ATTACHMENT,
    blendable, multisampling capabilities and the STORAGE_BINDING
    capability with read-only and write-only storage texture accesses:

    • r16unorm
    • r16snorm
    • rg16unorm
    • rg16snorm
    • rgba16unorm
    • rgba16snorm
  • Allows the RENDER_ATTACHMENT, blendable, multisampling and resolve
    capabilities on below texture formats:

    • r8snorm
    • rg8snorm
    • rgba8snorm
  • Enables the extension rg11b10ufloat-renderable.

  • Allows the read-only and write-only storage texture accesses on below texture formats:

    • r8unorm
    • r8snorm
    • r8uint
    • r8sint
    • rg8unorm
    • rg8snorm
    • rg8uint
    • rg8sint
    • r16uint
    • r16sint
    • r16float
    • rg16uint
    • rg16sint
    • rg16float
    • rgb10a2uint
    • rgb10a2unorm
    • rg11b10ufloat

Issue: #3838

This patch adds the optional feature `storage-texture-format-tier1`
that:
- Allows the `read-write` storage texture access on below formats:
  - `rgba32float`
  - `rgba32uint`
  - `rgba32sint`
  - `rgba16float`
  - `rgba16uint`
  - `rgba16sint`
  - `rgba8unorm`
  - `rgba8uint`
  - `rgba8sint`
- Allows the `STORAGE_BINDING` usage with all storage texture accesses
  on below formats:
  - `r16float`
  - `r16uint`
  - `r16sint`
  - `r8unorm`
  - `r8uint`
  - `r8sint`
@github-actions
Copy link
Contributor

github-actions bot commented Apr 16, 2025

Previews, as seen when this build job started (298ad79):
WebGPU webgpu.idl | Explainer | Correspondence Reference
WGSL grammar.js | wgsl.lalr.txt

Copy link

@mwyrzykowski mwyrzykowski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it’s covered by existing restrictions, but writable textures are only allowed in compute and fragment stages (not vertex stage), correct?

Copy link
Contributor

@kainino0x kainino0x left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Editorially seems fine, but can you clarify where these lists come from? They don't look the same as Teo's original proposal. (Point to a specific comment on that thread, if there is one?)

Also #3838 tracks other tiers too, so I'm unlinking this so it won't close that bug.

@Jiawei-Shao
Copy link
Contributor Author

Editorially seems fine, but can you clarify where these lists come from? They don't look the same as Teo's original proposal. (Point to a specific comment on that thread, if there is one?)

Also #3838 tracks other tiers too, so I'm unlinking this so it won't close that bug.

In #3838,

  • The rw-storage-texture-tier-1 extension is now actually supported as WebGPU core feature,
  • This PR supports both rw-storage-texture-tier-2 and rw-storage-texture-tier-3 because it is the same requirement for Metal and D3D12 (Metal: Needs MTLReadWriteTextureTier2,
    D3D FL11: Optional), and according to David's comment shaderStorageImageExtendedFormats is required for current WebGPU so all the formats mentioned in this PR can be supported on all Vulkan backends that can run WebPU.

@Jiawei-Shao
Copy link
Contributor Author

I think it’s covered by existing restrictions, but writable textures are only allowed in compute and fragment stages (not vertex stage), correct?

Yes.

@Kangz
Copy link
Contributor

Kangz commented Apr 17, 2025

and according to #3838 (comment) shaderStorageImageExtendedFormats is required for current WebGPU so all the formats mentioned in this PR can be supported on all Vulkan backends that can run WebPU.

I would like to have another investigation into this because that comment was challenged later by @teoxoy and doesn't match the checks that we have in Dawn at the moment.

Can we have a report from https://github.com/kainino0x/gpuinfo-vulkan-query that describes the diff between the original tier 2 and 3? What's the require

Does the list or formats supported with "tier 1" in this PR match the entirety of shaderStorageImageExtendedFormats or are there additional formats that could be supported.

@teoxoy
Copy link
Member

teoxoy commented Apr 17, 2025

I think we still need 2 tiers that would map to the old tier 2 & 3 in #3838. Tier 2 can even be supported by compat.

Can we have a report from https://github.com/kainino0x/gpuinfo-vulkan-query that describes the diff between the original tier 2 and 3? What's the require

shaderStorageImageExtendedFormats loses all Adreno 5XX devices (see folded section of #3837 (comment)).

Does the list or formats supported with "tier 1" in this PR match the entirety of shaderStorageImageExtendedFormats or are there additional formats that could be supported.

IIRC, #3837 covers all formats enabled by shaderStorageImageExtendedFormats.

@Jiawei-Shao
Copy link
Contributor Author

Jiawei-Shao commented Apr 18, 2025

Hi @Kangz,

I've updated Myles' comment in #3838:

Format Proposed tier in #3838 Metal support D3D12 support Vulkan support OpenGL ES 3.1 Support
rgba32float 2 MTLReadWriteTextureTier2 Supported as a set All All
rgba32uint 2 MTLReadWriteTextureTier2 Supported as a set All All
rgba32sint 2 MTLReadWriteTextureTier2 Supported as a set All All
rgba16float 2 MTLReadWriteTextureTier2 Supported as a set All All
rgba16uint 2 MTLReadWriteTextureTier2 Supported as a set All All
rgba16sint 2 MTLReadWriteTextureTier2 Supported as a set All All
rgba8unorm 2 MTLReadWriteTextureTier2 Supported as a set All All
rgba8uint 2 MTLReadWriteTextureTier2 Supported as a set All All
rgba8sint 2 MTLReadWriteTextureTier2 Supported as a set All All
r16float 3 MTLReadWriteTextureTier2 Supported as a set shaderStorageImageExtendedFormats None
r16uint 3 MTLReadWriteTextureTier2 Supported as a set shaderStorageImageExtendedFormats None
r16sint 3 MTLReadWriteTextureTier2 Supported as a set shaderStorageImageExtendedFormats None
r8unorm 3 MTLReadWriteTextureTier2 Supported as a set shaderStorageImageExtendedFormats None
r8uint 3 MTLReadWriteTextureTier2 Supported as a set shaderStorageImageExtendedFormats None
r8sint 3 MTLReadWriteTextureTier2 Supported as a set shaderStorageImageExtendedFormats None

Note that:

  1. The formats with MTLReadWriteTextureTier2 are listed in the Metal doc.
  2. Supported as a set means "if any one of the format listed is supported, all are supported" According to the D3D12 doc.
  3. According to David's comment shaderStorageImageExtendedFormats is now required to support WebGPU, so actually the supports of read-only or write-only STORAGE_BINDING of these formats should be in WebGPU core feature.
  4. Other formats in shaderStorageImageExtendedFormats cannot support MTLReadWrite in Metal so I don't add them in this PR.

Copy link
Contributor

@kainino0x kainino0x left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The table doesn't explain the difference between the formats that gain RW support (rgba*) and the ones that gain basic STORAGE support (r*). Could you clarify where that comes from?

  • According to David's comment shaderStorageImageExtendedFormats is now required to support WebGPU, so actually the supports of read-only or write-only STORAGE_BINDING of these formats should be in WebGPU core feature.

I don't think this comment was correct. From the following comments it sounds like that wasn't intended, and there was a spec bug we fixed in #4741.

@Jiawei-Shao Jiawei-Shao changed the title Add optional feature storage-texture-format-tier1 Add optional feature storage-texture-format-tier2 Apr 22, 2025
@Jiawei-Shao
Copy link
Contributor Author

The table doesn't explain the difference between the formats that gain RW support (rgba*) and the ones that gain basic STORAGE support (r*). Could you clarify where that comes from?

  • According to David's comment shaderStorageImageExtendedFormats is now required to support WebGPU, so actually the supports of read-only or write-only STORAGE_BINDING of these formats should be in WebGPU core feature.

I don't think this comment was correct. From the following comments it sounds like that wasn't intended, and there was a spec bug we fixed in #4741.

Now this PR only includes Tier 2 formats which are less controversial. PTAL.

We can talk about Tier 3 formats in another PR.

@Kangz
Copy link
Contributor

Kangz commented Apr 22, 2025

Thank you for updating this table, it is very useful! Looking at it, IMHO we could merge tier2/3 into a single optional feature (but that doesn't do the same thing on compat vs. not) (it would drop Adreno 500 support but IMHO that's ok). If we want to add support for more formats in the future we can add more tiers.

@mwyrzykowski
Copy link

Thank you for updating this table, it is very useful! Looking at it, IMHO we could merge tier2/3 into a single optional feature (but that doesn't do the same thing on compat vs. not) (it would drop Adreno 500 support but IMHO that's ok). If we want to add support for more formats in the future we can add more tiers.

Merging tier2+3 into a single tier2 would be nice, it would reduce fragmentation

@kainino0x kainino0x dismissed their stale review April 22, 2025 18:27

LGTM but holding until working group approval

Copy link
Contributor

@kainino0x kainino0x left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conclusions from the WG meeting:

  • We should include the tier3 formats after all; sorry I was confused about what they supported.
  • Compat won't allow them, though, so it will add restrictions to this feature (the same way it adds restrictions to core capabilities). We should add this to the Compat proposal doc in the same PR.
  • The WG decided it should be called something like "storage-texture-formats-1" or "rw-storage-texture-formats-1" - editors need to settle on something @jimblandy @toji. I think the criteria are: this one is numbered 1, and the feature is named in such a way that any future version n+1 is superset of version n.

@Jiawei-Shao
Copy link
Contributor Author

The table looks good to me, thanks for working on this!

One nit: For the 16bit normalized formats should the boxes be ticked instead of saying "If texture-formats-tier1 is enabled"? since those formats are already gated behind texture-formats-tier1 (in the Required Feature column).

Done @teoxoy

Copy link
Contributor

@alan-baker alan-baker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WGSL lgtm

Copy link
Contributor

@dneto0 dneto0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WGSL change LGTM

Copy link
Contributor

@kainino0x kainino0x left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies for the delay!

@kainino0x kainino0x added the api resolved Resolved - waiting for a change to the API specification label May 22, 2025
@kainino0x kainino0x merged commit 20b5f62 into gpuweb:main May 22, 2025
4 checks passed
@kainino0x kainino0x added the needs-cts-issue This change requires tests (or would need tests if accepted), but may not have a CTS issue filed yet label May 22, 2025
@Kangz
Copy link
Contributor

Kangz commented May 27, 2025

GPU Web WG 2025-05-14 Atlantic-time

kainino0x pushed a commit to gpuweb/types that referenced this pull request May 28, 2025
This PR reflects changes from the following spec PRs:
* gpuweb/gpuweb#5193
* gpuweb/gpuweb#5160

Please publish new version after it's merged so that we can add tests in
the CTS as in gpuweb/cts#4390
kainino0x pushed a commit that referenced this pull request Jun 20, 2025
This patch adds the optional feature `texture-formats-tier2` with below
new features
based on [the previous
investigation](#5160 (comment)):

- Allows the `read-write` storage texture access on below texture
formats:
  - `r8unorm`
  - `r8uint`
  - `r8sint`
  - `rgba8unorm`
  - `rgba8uint`
  - `rgba8sint`
  - `r16uint`
  - `r16sint`
  - `r16float`
  - `rgba16uint`
  - `rgba16sint`
  - `rgba16float`
  - `rgba32uint`
  - `rgba32sint`
  - `rgba32float`
- Enabling `texture-formats-tier2` will also enable
`texture-formats-tier1`.

Fixed: #3838
kainino0x added a commit to webgpu-native/webgpu-headers that referenced this pull request Jun 26, 2025
These were added in the upstream WebGPU API and should be reflected
here.
- gpuweb/gpuweb#5147
Ordered at the top for consistency even though it changes the numbering
of everything else.
Also fixed the ordering of TimestampQuery to match since the numbering
is changing anyway. (Even though the ordering doesn't really matter
because it's nonobservable upstream and there isn't really an ordering.)
- gpuweb/gpuweb#5160
- gpuweb/gpuweb#5226

The renumbering is technically a breaking change because it changes the
ABI (which shouldn't matter right now) and could affect code that
depends on comparing enum values or hard-coded integer versions of them.
ErichDonGubler added a commit to erichdongubler-mozilla/wgpu that referenced this pull request Aug 11, 2025
Tier 1 PRs for WebGPU spec.:
[`gpuweb`gfx-rs#5213](gpuweb/gpuweb#5213) and
[`gpuweb`gfx-rs#5160](gpuweb/gpuweb#5160).

Tier 2 PR for WebGPU spec.:
[`gpuweb`gfx-rs#5226](gpuweb/gpuweb#5226)
ErichDonGubler added a commit to erichdongubler-mozilla/wgpu that referenced this pull request Aug 12, 2025
Tier 1 PRs for WebGPU spec.:
[`gpuweb`gfx-rs#5213](gpuweb/gpuweb#5213) and
[`gpuweb`gfx-rs#5160](gpuweb/gpuweb#5160).

Tier 2 PR for WebGPU spec.:
[`gpuweb`gfx-rs#5226](gpuweb/gpuweb#5226)
ErichDonGubler added a commit to erichdongubler-mozilla/firefox that referenced this pull request Aug 12, 2025
juj added a commit to juj/wasm_webgpu that referenced this pull request Sep 12, 2025
ErichDonGubler added a commit to erichdongubler-mozilla/wgpu that referenced this pull request Oct 9, 2025
Tier 1 PRs for WebGPU spec.:
[`gpuweb`gfx-rs#5213](gpuweb/gpuweb#5213) and
[`gpuweb`gfx-rs#5160](gpuweb/gpuweb#5160).

Tier 2 PR for WebGPU spec.:
[`gpuweb`gfx-rs#5226](gpuweb/gpuweb#5226)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

api resolved Resolved - waiting for a change to the API specification api WebGPU API needs-cts-issue This change requires tests (or would need tests if accepted), but may not have a CTS issue filed yet proposal

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants