Rename SHADER_READ back to SAMPLED - #1963

Was this discussed at the editor's meeting?

We didn't have time to discuss it this week.

The concern about SHADER_READ is valid. Let's see if we can find a better name for it.
First of all, I find SAMPLED to not be a good choice - #1785

Maybe we can follow D3D12 closer (which is where we get the restriction from about no sampling from integer textures) and calls it SHADER_RESOURCE?

SHADER_RESOURCE works although it is a bit misleading as well since storage textures are also resources. I don't think there's an ideal solution that's also short, so any of the 3 sgtm.

Would it be valid to say that a "sample" operation is comprised of 1-8 "fetch" operations + filtering? Then could we call it something like FETCH?

In that case it would probably also be beneficial to use matching terminology in WGSL and change textureLoad to textureFetch/texelFetch (like GLSL, despite HLSL's texture.Load() and MSL's texture.read()).

SHADER_FETCH is a good solution too imho

Ideas from a chat between me and @kvark:

• TEXTURE_BINDING and STORAGE_BINDING (kvark's idea to name it after the binding instead of the shader operations)
  • "Usage" wording is consistent:
    • "Use it as a COPY SOURCE"
    • "Use it as a RENDER ATTACHMENT"
    • "Use it as a TEXTURE BINDING" (GPUTextureBindingLayout)
    • "Use it as a STORAGE BINDING" (GPUStorageTextureBindingLayout)
• SHADER_READ and SHADER_STORAGE
  • Presents "READ" and "STORAGE" as contrasting options so it looks less like you need SHADER_READ | STORAGE.

I think we both like the first option quite a bit. (We had half a mind to try to make the buffer usages to fit the pattern as well, but there isn't really any ambiguity there right now, and the buffer usages are a lot more diverse so it's harder.)

That's pretty good. Let's talk about it in the meeting anyway since the agenda is already out, but I hope we can settle it quickly.

Resolution: "*_BINDING is winning by half-votes across the board :)"