Uploading this for discussion to replace #190.

Myles's usage table:

Same comment as in the other PR: I don't think we should do this for two reasons:

• Sample and Load can go through two different hardware paths (Load can be a direct memory load while Sample has to go through a texture unit). I'm not sure but using Load on a texture that's also samplable could be slower than on a storage texture.
• Buffer bindings state the type of buffers which is super important because we'll eventually want three different binding types: uniform-buffer, storage-buffer and read-only-storage-buffer. The latter would help have a buffer for both uniform (with 64kb view limitation) and read-only storage during a single pass. We should have consistency there.

So like for buffers I'd suggest we keep the current names for textures, and plan to add a read-only-storage-texture or ro-storage-texture binding type in the future.

@Kangz
Wait, is the only motivation for ro-storage-texture that "using Load on a texture that's also samplable could be slower than on a storage texture" ? Do you have any references to back that up?

The other motivation is consistency with buffer. No I don't have references at this point.

Discussed at the 1 April Teleconference

Consensus: Prefer sampled-texture name.

Oh, I didn't realize that's what the group preferred. What about the fact that some users may use this kind of texture without ever sampling from it (only loading instead)?

To clarify my position: I think it should be just "texture", given that 95% of use cases (roughly!) are just that, and it's easily recognizable and matching HLSL. I don't quite see how the argument about barriers apply here: we aren't inventing new concepts, the difference between regular textures and storage/rw ones is well known, and we don't anticipate any new kinds there.