GLSL auto optimization

4
votes

I have three question realted with GLSL auto optimaztion(?) process.

  1. Unused variables -> Is glsl removes all variables which not affect on final fragment shader pixel (out variable).

  2. Unused function -> Is glsl removes all unsed defined functions before void main...?

  3. And what about ins and outs variables. An example: I have 100 shaders which send a texture coordinates from vertex shader to fragment shader. In fragment shader these coordiantes no affect on a final color. Will glsl remove this variable?

1
openglglslshaderfragment-shadervertex-shader
Shader compilers are implementation specific, and the spec tends to leave details like this vague to allow implementations to pursue whatever strategy works best. I think the answers are: 1. Almost definitely 2. Almost definitely. 3. Probably. – Columbo

1 Answers

4
votes

That is not specified clearly. The OpenGL specification says:

See OpenGL 4.6 Core Profile Specification - 7.6 Uniform Variables - p. 130:

7.6 Uniform Variables

Shaders can declare named uniform variables, as described in the OpenGL Shading Language Specification. A uniform is considered an active uniform if the compiler and linker determine that the uniform will actually be accessed when the executable code is executed. In cases where the compiler and linker cannot make a conclusive determination, the uniform will be considered active.

See OpenGL 4.6 Core Profile Specification - 7.3.1 Program Interfaces - p. 101:

7.3.1 Program Interfaces

When a program object is made part of the current rendering state, its executable code may communicate with other GL pipeline stages or application code through a variety of interfaces. When a program is linked, the GL builds a list of active resources for each interface. Examples of active resources include variables, interface blocks, and subroutines used by shader code. Resources referenced in shader code are considered active unless the compiler and linker can conclusively determine that they have no observable effect on the results produced by the executable code of the program. For example, variables might be considered inactive if they are declared but not used in executable code, used only in a clause of an if statement that would never be executed, used only in functions that are never called, or used only in computations of temporary variables having no effect on any shader output. In cases where the compiler or linker cannot make a conclusive determination, any resource referenced by shader code will be considered active. The set of active resources for any interface is implementation-dependent because it depends on various analysis and optimizations performed by the compiler and linker.

If a program is linked successfully, the GL will generate lists of active resources based on the executable code produced by the link.