Change RO texture usage to be restricted#1864
Conversation
|
Updated the table based on FL11_0 tables (thanks @kainino0x !). It leaves only 3 formats (R32Xxx) with RO capability... which is quite useless, I'd say. |
kainino0x
left a comment
kainino0x
left a comment
There was a problem hiding this comment.
Change LGTM if we decide to go this way
|
@kainino0x you mentioned previously that you didn't think we should go this route. If you are still feeling this way, could you try to express that point in a comment here? The next call is not soon. |
|
Thinking about this versus #1794, I'm seeing a new concern. If we keep RO storage textures, users may be confused because of the difference in validation versus RO storage buffers. I.e. the storage buffers can be combined with other usages, but storage textures can't. This is unexpected. |
I don't remember my exact feeling, but two things are on my mind:
I do think the old RO storage textures and the new RO storage textures are sufficiently different that it makes sense to think of this as two separate changes:
So I think from that point of view I support removing them first. |
|
We can close this since the group agreed to just remove RO storage textures for now. |
|
Found another small reason why RO texture storage would be marginally useful: we could allow it in VS stage, unlike read-write storage, even if for the same formats. Edit: although, the same old argument still applies: users can use a regular sampled texture there. |
1652: Switch read-only storage textures to be exclusive and behind a feature r=cwfitzgerald a=kvark **Connections** See gpuweb/gpuweb#1864 and gpuweb/gpuweb#1794 **Description** WebGPU API doesn't have RO storage textures right now. However, since `wgpu` already had a way to expose read-write storage textures, I figured we can just use it to gate read-only storage. **Testing** No examples currently exercise this path. Co-authored-by: Dzmitry Malyshau <[email protected]>
2 participants
Alternative to #1794
It completely changes the semantics of RO texture bindings, so that:
SAMPLEDThe idea here, which @Kangz has been trying to convey, is that RO usage is still going to be potentially useful, even with those extra restrictions. It takes a different code path from
SAMPLEDin the driver, changes the caching policy of obtained samples, and it can't be replaced by "read-write" because we don't have it today.Preview | Diff