Missing RelaxedPrecision decoration on sample operation

[alan-baker]

From KhronosGroup/SPIRV-Tools#3471, test shader:

#version 310 es
precision mediump float;
precision mediump int;
uniform mediump sampler2D tex;

layout(location = 0) in highp vec4 vertex;
layout(location = 0) uniform vec4 value;
layout(location = 0) out vec4 fragColor;

void main() {
        vec4 x = textureLod(tex, vertex.xy, 0.0); // specifying mediump here doesn't fix the problem
	if (max(x.r, x.g) < 2.0) {
		fragColor = vec4(0.0);
		return;
	}
	fragColor = vec4(1.0);
}

The result of the OpImageSampleExplicitLod is not decorated with RelaxedPrecision.

[johnkslang]

Glslang actually seems to be following the specification, in setting the operation precision at highp, but the result precision at mediump. The comment in the file seems to match the specification:

// "The operation of a built-in function can have a different precision
// qualification than the precision qualification of the resulting value.
// These two precision qualifications are established as follows.
//
// The precision qualification of the operation of a built-in function is
// based on the precision qualification of its input arguments and formal
// parameters:  When a formal parameter specifies a precision qualifier,
// that is used, otherwise, the precision qualification of the calling
// argument is used.  The highest precision of these will be the precision
// qualification of the operation of the built-in function. Generally,
// this is applied across all arguments to a built-in function, with the
// exceptions being:
//   - bitfieldExtract and bitfieldInsert ignore the 'offset' and 'bits'
//     arguments.
//   - interpolateAt* functions only look at the 'interpolant' argument.
//
// The precision qualification of the result of a built-in function is
// determined in one of the following ways:
//
//   - For the texture sampling, image load, and image store functions,
//     the precision of the return type matches the precision of the
//     sampler type
//
//   Otherwise:
//
//   - For prototypes that do not specify a resulting precision qualifier,
//     the precision will be the same as the precision of the operation.
//
//   - For prototypes that do specify a resulting precision qualifier,
//     the specified precision qualifier is the precision qualification of
//     the result."
//

Basically, that ignores whether something is a texture lookup for establishing operation, only considering it when establishing the precision of the result.

That's apparently not what's actually desired. Two possibilities I see are:

• have AST -> SPIR-V use RelaxedPrecision for the instruction if either the result or the operation precision is mediump
• fix the specification to say textures also operate at the same precision it is say they result in

[johnkslang]

FYI, the fix that actually went in was to use the AST result precision for texture lookup (about equivalent to the first bullet choice above).