nir_fold_16bit_sampler_conversions ignores type mismatches
for example nir_fold_16bit_sampler_conversions turns
vec4 32 ssa_17 = (uint32)txl ssa_14 (texture_deref), ssa_14 (sampler_deref), ssa_16 (coord), ssa_15 (lod)
vec1 16 ssa_18 = f2f16 ssa_17.x
vec1 16 ssa_19 = f2f16 ssa_17.y
vec1 16 ssa_20 = f2f16 ssa_17.z
vec1 16 ssa_21 = f2f16 ssa_17.w
into
vec4 16 ssa_17 = (uint16)txl ssa_14 (texture_deref), ssa_14 (sampler_deref), ssa_16 (coord), ssa_15 (lod)
vec1 16 ssa_23 = mov ssa_17.x
vec1 16 ssa_24 = mov ssa_17.y
vec1 16 ssa_25 = mov ssa_17.z
vec1 16 ssa_26 = mov ssa_17.w
which is obviously broken because now the data is u16 and not fp16.
Trivial example shader which reproduces the problem:
#version 460
#extension GL_EXT_shader_explicit_arithmetic_types : require
layout(local_size_x = 8, local_size_y = 8, local_size_z = 1) in;
layout(binding = 0) uniform usampler2D s_usampler;
layout(binding = 1, std430) buffer ssbo
{
f16vec4 s_fp16ssbo[];
};
void main()
{
vec2 coord = 2048.0f / gl_GlobalInvocationID.xy;
f16vec4 frog = f16vec4(uintBitsToFloat(textureLod(s_usampler, coord, 0.0)));
s_fp16ssbo[gl_GlobalInvocationID.x + 2048 * gl_GlobalInvocationID.y] = frog;
}
Edited by Georg Lehmann