Also need a function to fetch a single texel from a sampled image.

In the spirit of not overloading names, I suggest this:

vec4<type> texture_fetch(texture_sampled_*, f32 | vec(2|3)<f32> coords)

(Level of detail is not used, so no explicit LOD param, no LOD-bias, no explicit gradient).

Maps to OpImageFetch in SPIR-V. Can't be a cube image of any form.

Also want a function to get a single sample from a multi-sampled image.

(See "Sample" image operand in SPIR-V)

Suggest:

vec4<type> texture_fetch_sample(texture_sampled_2d_ms, vec2<f32> coords, u32 sample_index)

vec4<type> texture_load_sample(texture_ro_2d_ms, vec2<i32> coords, u32 sample_index)

@dneto0 do we really need different methods here? Since the semantics of them is the same, we could have the same texture_load() function working (overloaded) with both texture_sampled* and texture_ro. Would this be a concern?

Added todos.

Overloading on the texture type works for me.

TODO: allow a small constant offset to the (non-arrayed) coordinate for image-sample operations. Not allowed for cube images.
See SPIR-V "ConstOffset" image operand.

From MSL:

The texture sample, sample_compare, gather, and gather_compare functions take an
offset argument for a 2D texture, 2D texture array, and 3D texture. The offset is an integer
value applied to the texture coordinate before looking up each pixel. This integer value can be
in the range -8 to +7. The default value is 0.

Vulkan has similar limits. See minTexelOffset and maxTexelOffset limits (-8 and +7 respectively).

Must be a compile-time constant for SPIR-V.

(There is an "Offset" and "ConstOffsets" variant which are only used with image gather operations)

Maybe a texture_load_offset(texture_ro, f32 | vec(2|3)<f32> coords, i32 level_of_detail, i32 offset) ?

needs some investigation on how portable this is. I guess it's good, but we need to double-check

Added todo

TODO: Provide the level-of-detail via an explicit gradient. See "Grad" image operand in SPIR-V, and gradient2d constructor in MSL.

Investigation: SPIR-V has a MinLod image operand to clamp the minimum computed level-of-detail.
But that's an optional Vulkan feature "shaderResourceMinLod", and that has almost no support in the Android ecosystem.

https://vulkan.gpuinfo.org/listdevicescoverage.php?feature=shaderResourceMinLod&platform=android

Added TODO

The level-of-detail bias is only usable in fragment shaders.

Can you provide some references? I only see this:

A following operand is the bias added to the implicit level of detail. Only valid with implicit-lod instructions. It must be a floating-point type scalar. This can only be used with an OpTypeImage that has a Dim operand of 1D, 2D, 3D, or Cube, and the MS operand must be 0.

If you are talking about the limitation that an implicit lod is only available in fragment shaders, than yes, but it also applies to the regular texture_sample

needs some investigation on how portable this is. I guess it's good, but we need to double-check

Can you provide some references? I only see this:

A following operand is the bias added to the implicit level of detail. Only valid with implicit-lod instructions. It must be a floating-point type scalar. This can only be used with an OpTypeImage that has a Dim operand of 1D, 2D, 3D, or Cube, and the MS operand must be 0.

If you are talking about the limitation that an implicit lod is only available in fragment shaders, than yes, but it also applies to the regular texture_sample

in HLSL, cube textures can't do either loads or stores.
I think we just need them for sampled variants, therefore, not for storages

So, no depth variant either (looks like it from that cube texture page)

HLSL doesn't need depth variants, but cubes in HLSL do support SampleCmp, so we should allow that too

So, no depth variant either (looks like it from that cube texture page)

Set the types here to be void as they can't be sampled or read.