GLSL spec 4.3.4 input variables told link error if input static use but no related out declare

[hustcslhb]

GLSL spec 4.3.4 input variables told such case need link error

external\openglcts\modules\gles31\es31cSeparateShaderObjsTests.cpp

			else
			{
				// Mismatched input and output variables
				// For OpenGL ES contexts, this should cause a validation failure
				// For OpenGL contexts, validation should succeed.
				if (glu::isContextTypeES(m_context.getRenderContext().getType()) != (value == 0))
				{
					log << TestLog::Message << "Mismatched input and output variables; validation should "
						<< (glu::isContextTypeES(m_context.getRenderContext().getType()) ? "fail.\n" : "succeed.\n")
						<< "Vertex Shader:\n"
						<< vtx << "Fragment Shader:\n"
						<< frag << TestLog::EndMessage;
					TCU_FAIL("StateInteraction failed");
				}
			}

[alegal-arm]

Can you paste an example of shaders that cause a problem for you?

[hustcslhb]

Test "KHR-GL45.sepshaderobjs.StateInteraction" --- This test shader --- VS： #version 440 out gl_PerVertex { vec4 gl_Position; }; in highp vec4 a_position; uniform highp vec4 u_color; out float val0; void main (void) { gl_Position = a_position; val0 = u_color.x; }

PS： #version 440 precision highp float; precision highp int; in vec4 val1; in float val0; layout(location = 0) out mediump vec4 o_color; void main (void) { o_color = vec4(val1); }

GLSL-spec need link error But this test need validation pass, comment shows: // Mismatched input and output variables // For OpenGL ES contexts, this should cause a validation failure // For OpenGL contexts, validation should succeed.

[evgenKh]

I compared OpenGL 4.6 spec to OpenGL ES 3.2 spec, and actually found where this validation difference is described. Cases that should fail the validation are listed in section "11.1.3.11 Validation". ES spec seems to be more strict having more cases listed. The current program pipeline object contains a shader interface that doesn’t have an exact match is present only in ES spec. I double-checked that ValidateProgramPipeline behaves according to specs, when ran on ES31 and GL45 contexts with shader inputs/outputs are mismatched. So I assume everything works as expected.

[dgkoch]

I compared OpenGL 4.6 spec to OpenGL ES 3.2 spec, and actually found where this validation difference is described. Cases that should fail the validation are listed in section "11.1.3.11 Validation". ES spec seems to be more strict having more cases listed. The current program pipeline object contains a shader interface that doesn’t have an exact match is present only in ES spec. I double-checked that ValidateProgramPipeline behaves according to specs, when ran on ES31 and GL45 contexts with shader inputs/outputs are mismatched. So I assume everything works as expected.

Yes - this matches my recollection of why they are different. I agree that this is as expected.

[hustcslhb]

I compared OpenGL 4.6 spec to OpenGL ES 3.2 spec, and actually found where this validation difference is described. Cases that should fail the validation are listed in section "11.1.3.11 Validation". ES spec seems to be more strict having more cases listed. The current program pipeline object contains a shader interface that doesn’t have an exact match is present only in ES spec. I double-checked that ValidateProgramPipeline behaves according to specs, when ran on ES31 and GL45 contexts with shader inputs/outputs are mismatched. So I assume everything works as expected.

Yes - this matches my recollection of why they are different. I agree that this is as expected.

I double check The OpenGL® Shading Language, Version 4.60.7, part 4.3.4. Input Variables Only the input variables that are statically read need to be written by the previous stage; it is allowed to have superfluous declarations of input variables. This is shown in the following table. (For the 1st row of the table, need link error)

[evgenKh]

Sorry I didn't explain why I ignored part of GLSL spec you provided. This test "KHR-GL45.sepshaderobjs.StateInteraction" (es31cSeparateShaderObjsTests.cpp) is using separable program objects (two program objects in one pipeline).

Here's what GL46 and ES32 specs say about shader interface matching in 7.4.1. for normal program objects: For program objects containing multiple shaders, LinkProgram will check for mismatches on interfaces between shader stages in the program being linked and generate a link error if a mismatch is detected. and for separable program objects: With separable program objects, interfaces between shader stages may involve the outputs from one program object and the inputs from a second program object. For such interfaces, it is not possible to detect mismatches at link time, because the programs are linked separately. When each such program is linked, all inputs or outputs interfacing with another program stage are treated as active. The linker will generate an executable that assumes the presence of a compatible program on the other side of the interface.

Since it's just impossible to detect some failures(including mismatches) at link time to get a Link-time Error, later on in part 11.1.3.11 both ES&GL specs suggest to use ValidateProgramPipeline for separable program objects. Which the test actually does, also considering slightly different validation rules listed in same parts 11.1.3.11.

[sigexp]

Considering the info @evgenKh provided, should this issue be closed?