Add GPUTexelBufferView - #297

What's the difference between a texel buffer view and a storage buffer? Why do we need both? (I don't really what texel views mean in hardware)

Good question. I can't think of a case where a storage texel buffer storage would be better than just a storage buffer. There are some minor things like sampling from it, or an ability to have the same shader handling both buffer and texture storages, but it feels fairly minor.

The read-only (or "sampled") texel buffer views seem useful though.

In Vulkan:

• the storage texel buffer is does not use sampling, so no filtering is applied. However, it does let you do a format conversion (including swizzle and width conversion) on the load or store. In SPIR-V the OpTypeImage is required to have Sampled=2, (i.e. not used with a sampler), Dim=Buffer. Use OpImageRead with this.
• the uniform texel buffer is used with images that do have samplers (Sampled=1, Dim=Buffer), but the sampling parameters are ignored so again there is no filtering applied. It again lets you do the format conversion for the accessed texel on load. Use OpImageFetch with this.

Thanks for digging into the details of texel buffers in Vulkan. The feature seems completely superseded by storage buffer, so we should postpone this (and I'd suggest we do this indefinitely)

Closing as agreed during F2F.

The format conversion parts are necessary for HLSL support, since the type of a StructuredBuffer doesn't necessarily have to match the underlying buffer's format.

Buffers are untyped, you can implement StructuredBuffers by loading data and reinterpret_cast in the shader.

reinterpret_cast is not what I mean. I mean that you can load StructuredBuffer<float> from HLSL, and it can be backed by a SN16-typed buffer. In Vulkan, the way to do this is with a texel buffer view, and that's what dxc/spiregg will emit. Removing this functionality from the web makes it difficult to support dxc's StructuredBuffer.

The content of buffers is untyped so you an implement that StructuredBuffer with a storage buffer containing an unsized array of floats.

I understand that I do not describe the buffer type directly to WebGPU, but texel views let me state that buffer contains data packed as SN16 (16-bit signed normal integers representing the range from -1.0 to 1.0) and load it in the shader as a float. This is known as a "typed surface load/store", it's implemented in GLSL through the extension GL_EXT_shader_image_load_formatted, StructuredBuffers in HLSL do it by default, and Vulkan storage buffers do not support it.

@dneto0 provides a pretty good summary of what they are in Vulkan.

The feature seems completely superseded by storage buffer, so we should postpone this (and I'd suggest we do this indefinitely)

@Kangz and others, the main reason why there's still a distinction between STB (SSBO in OpenGL) and UTB (TBO in OpenGL) and why Uniform Texel Buffer (no idea why they called it "Uniform" in Vulkan) remains relevant is the following:

1. UTB/TBO loads go through the same path and cache as texel fetches from normal read-only sampled (and possibly filtered) textures. Because of that, unaligned, swizzled, and/or random address reads from UTBs/TBOs could be expected to be faster than those from SSBOs.
2. The automatic type conversions as @magcius pointed out
3. Different Performance characteristics, SSBO might be slower because UTB/TBO is assumed to be read-only, non coherent, etc. Basically on some hardware you'd want to put skinning matrices in TBOs instead of SSBOs, especially the hardware that can produce "waterfalling".

@devshgraphicsprogramming that's some great info/insight here! I think what's missing is some benchmarking to quantify the benefits of texel buffers, perhaps in extreme cases where it's supposed to be faster.

@kvark we've been wanting to profile this for our engine for almost a year
buildaworldnet/IrrlichtBAW#119
I'll check back when/if I'm done, but those tests will be for NVidia/AMD/Intel only, no idea how it looks like on Mobile GPUs.