Add RO and RW storage textures#4326
Conversation
|
Previews, as seen when this build job started (abbec21): |
5de46c4 to
446a7ae
Compare
|
CC @teoxoy |
toji
left a comment
There was a problem hiding this comment.
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. 😁
jrprice
left a comment
There was a problem hiding this comment.
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.
teoxoy
left a comment
There was a problem hiding this comment.
I think we should update this section.
One think I'd like to confirm, though: Does every texture format which supports
STORAGE_BINDINGusage 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:
r32floatr32uintr32sint
based on #3838 (comment) & #3838 (comment)
The other formats listed in the issue can be added later and be conditional on a new feature.
|
@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 |
Done, PTAL |
|
@teoxoy I've made the changes to resource usage and texture compatibility, PTAL. |
There was a problem hiding this comment.
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.
spec/index.bs
Outdated
| : `read` | ||
| :: Set |textureLayout|.{{GPUStorageTextureBindingLayout/access}} to {{GPUStorageTextureAccess/"read-only"}} | ||
| : `write` | ||
| :: Set |textureLayout|.{{GPUStorageTextureBindingLayout/access}} to {{GPUStorageTextureAccess/"write-only"}} |
There was a problem hiding this comment.
Could we have text to automatically upgrade write-only to read-write if needed (even if it is not usable in the API yet?)
There was a problem hiding this comment.
Do you mean have the API "read-write" be compatible with WGSL "write" and use that if the format works?
There was a problem hiding this comment.
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:
So here we'd have something like:
If resource is a storageTexture, previousEntry has access
write-onlyand entry has accessread-write, then set previousEntry's access toread-write.
There was a problem hiding this comment.
When rw-storage-texture-tier-1 is introduced, you could merge bindings on some devices, but not others. Is that desirable?
There was a problem hiding this comment.
Yes, that seems ok, because the optional features are opt-in.
There was a problem hiding this comment.
I'm ok with doing this. Do we need larger group agreement first?
There was a problem hiding this comment.
We can put it as tacit resolution.
There was a problem hiding this comment.
PTAL at those changes.
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]>
4361ecf to
abbec21
Compare
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.
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.

readandread_writeaccess modes for storage texturesPlan is to add API-side (not all the formats) to this PR too. Currently just the WGSL changes.