Skip to content

Add RO and RW storage textures#4326

Merged
alan-baker merged 17 commits intogpuweb:mainfrom
alan-baker:read-storage-texture
Oct 20, 2023
Merged

Add RO and RW storage textures#4326
alan-baker merged 17 commits intogpuweb:mainfrom
alan-baker:read-storage-texture

Conversation

@alan-baker
Copy link
Contributor

  • WGSL
    • allow read and read_write access modes for storage textures
    • allow ro and rw storage textures with textureLoad
    • allow rw storage textures with textureStore
    • add textureBarrier
  • WebGPU
    • add new enums for read-only and read-write storage textures

Plan is to add API-side (not all the formats) to this PR too. Currently just the WGSL changes.

@alan-baker alan-baker added this to the Milestone 1 milestone Oct 12, 2023
@github-actions
Copy link
Contributor

github-actions bot commented Oct 12, 2023

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

@alan-baker alan-baker force-pushed the read-storage-texture branch from 5de46c4 to 446a7ae Compare October 12, 2023 20:02
@alan-baker alan-baker marked this pull request as ready for review October 12, 2023 20:48
@alan-baker alan-baker requested a review from toji October 12, 2023 20:49
@alan-baker
Copy link
Contributor Author

CC @teoxoy

Copy link
Member

@toji toji left a comment

Choose a reason for hiding this comment

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

API-side LGTM now, thanks!

One think I'd like to confirm, though: Does every texture format which supports STORAGE_BINDING usage support all three access modes? I feel like the answer should obviously be "yes" but I think we all know that GPUs do not always do the obvious thing. 😁

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.

API spec LGTM, though good question from @toji

Copy link
Contributor

@jrprice jrprice left a comment

Choose a reason for hiding this comment

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

As discussed during prototyping, this needs an entry for textureLoad() in the "Uniformity Rules for Function Calls" section to state that loads from a read-write storage texture may be non-uniform.

Copy link
Member

@teoxoy teoxoy 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 we should update this section.

image

One think I'd like to confirm, though: Does every texture format which supports STORAGE_BINDING usage support all three access modes? I feel like the answer should obviously be "yes" but I think we all know that GPUs do not always do the obvious thing. 😁

No, we need to add another column for read-only & read-write access. With the only formats supporting those accesses (in the core spec) being:

  • r32float
  • r32uint
  • r32sint

based on #3838 (comment) & #3838 (comment)

The other formats listed in the issue can be added later and be conditional on a new feature.

@teoxoy
Copy link
Member

teoxoy commented Oct 13, 2023

@alan-baker thanks for starting the PR!

I agreed on the last API call to add 2 proposals (one for adding the functionality to core and one for the rw-storage-texture-tier-1 feature). @Kangz since this PR adds the functionality to core already, would you prefer the rw-storage-texture-tier-1 feature be a PR or still proposal?

@alan-baker alan-baker requested a review from jrprice October 13, 2023 15:22
@alan-baker
Copy link
Contributor Author

As discussed during prototyping, this needs an entry for textureLoad() in the "Uniformity Rules for Function Calls" section to state that loads from a read-write storage texture may be non-uniform.

Done, PTAL

@alan-baker
Copy link
Contributor Author

@teoxoy I've made the changes to resource usage and texture compatibility, PTAL.

@alan-baker alan-baker requested review from kainino0x and toji October 13, 2023 15:35
Copy link
Member

@teoxoy teoxoy left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Member

@toji toji left a comment

Choose a reason for hiding this comment

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

Thanks for the table update!

The big thing that's missing now is an update to the createBindGroupLayout() validation. I can't comment on the line directly in this PR, but at line 5991 where we say:

|entry|.{{GPUBindGroupLayoutEntry/storageTexture}}.{{GPUStorageTextureBindingLayout/format}} must be a format which can support storage usage.

It should be updated to something like:

|entry|.{{GPUBindGroupLayoutEntry/storageTexture}}.{{GPUStorageTextureBindingLayout/format}} is a format which supports the given |entry|.{{GPUBindGroupLayoutEntry/storageTexture}}.{{GPUStorageTextureBindingLayout/access}} according to the [Plain Color Formats](#plain-color-formats) table.

@alan-baker alan-baker requested a review from toji October 13, 2023 19:42
Copy link
Member

@toji toji left a comment

Choose a reason for hiding this comment

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

Thanks! LGTM now!

spec/index.bs Outdated
: `read`
:: Set |textureLayout|.{{GPUStorageTextureBindingLayout/access}} to {{GPUStorageTextureAccess/"read-only"}}
: `write`
:: Set |textureLayout|.{{GPUStorageTextureBindingLayout/access}} to {{GPUStorageTextureAccess/"write-only"}}
Copy link
Contributor

Choose a reason for hiding this comment

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

Could we have text to automatically upgrade write-only to read-write if needed (even if it is not usable in the API yet?)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you mean have the API "read-write" be compatible with WGSL "write" and use that if the format works?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes for WGSL writeonly being compatible with read-write in the layout. But also in the algorithm to default the GPUPipelineLayout of a pipeline we have a step to merge bindings between shader stages:

image

So here we'd have something like:

If resource is a storageTexture, previousEntry has access write-only and entry has access read-write, then set previousEntry's access to read-write.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

When rw-storage-texture-tier-1 is introduced, you could merge bindings on some devices, but not others. Is that desirable?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, that seems ok, because the optional features are opt-in.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm ok with doing this. Do we need larger group agreement first?

Copy link
Contributor

Choose a reason for hiding this comment

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

We can put it as tacit resolution.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

PTAL at those changes.

@alan-baker alan-baker added the tacit resolution queue Editors have agreed and intend to land if no feedback is given label Oct 16, 2023
kainino0x and others added 15 commits October 20, 2023 11:03
Co-authored-by: Kai Ninomiya <[email protected]>
* Make the result of textureLoad from a read-write storage texture
  non-uniform
* Update texture format compatibility to only allow r32uint, r32sint,
  and r32float for readable storage textures
Co-authored-by: Brandon Jones <[email protected]>
Co-authored-by: Brandon Jones <[email protected]>
Co-authored-by: Brandon Jones <[email protected]>
* Allow WO storage textures to be compatible of with RW bindings if the
  formats are compatible
* Allow entries to be merged according to that compatibility
Co-authored-by: Corentin Wallez <[email protected]>
Co-authored-by: Corentin Wallez <[email protected]>
Co-authored-by: Kai Ninomiya <[email protected]>
@alan-baker alan-baker force-pushed the read-storage-texture branch from 4361ecf to abbec21 Compare October 20, 2023 15:05
@alan-baker alan-baker merged commit 7d903a0 into gpuweb:main Oct 20, 2023
@alan-baker alan-baker deleted the read-storage-texture branch October 20, 2023 15:13
@kainino0x kainino0x added needs-cts-issue This change requires tests (or would need tests if accepted), but may not have a CTS issue filed yet and removed tacit resolution queue Editors have agreed and intend to land if no feedback is given labels Oct 20, 2023
alan-baker added a commit to alan-baker/gpuweb that referenced this pull request Oct 30, 2023
Pull gpuweb#4326 introduced temporary anchors for "read-only" and "read-write"
storage texture access.
This commit removes them since the real anchors are landed in the API
spec.
kainino0x pushed a commit that referenced this pull request Oct 31, 2023
Pull #4326 introduced temporary anchors for "read-only" and "read-write"
storage texture access.
This commit removes them since the real anchors are landed in the API
spec.
juj added a commit to juj/wasm_webgpu that referenced this pull request Mar 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

needs-cts-issue This change requires tests (or would need tests if accepted), but may not have a CTS issue filed yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants