Support pipeline level optimization

[jherico]

My company relies on a small set of fairly generic shaders and has previously depended on OpenGL's somewhat lax validation of pipelines, specifically: allowing vertex shaders to write outputs that the fragment shader doesn't read.

This is impeding a port to Vulkan since the pipeline validation will fail in such cases. Currently I've been working around it by adding unused inputs to the fragment shader, but it occurred to me that there might be a better approach for this situation.

For our pipeline we use spirv-opt to optimize individual shaders, but another potential approach would be possible if spirv-opt had a mode where it was able to optimize an entire pipeline. If I could call spirv-opt and pass it all the shaders I was going to use for a given pipeline, it would have enough information to detect that certain vertex outputs weren't consumed by the fragment shader, or that the fragment shader ultimately didn't use them in it's output. It could then produce optimized output that ensured that the vertex / fragment interface was valid and minimal.

To be a general solution you'd need to be able to include each potential stage of the pipeline (including geometry and tessellation) and work backwards through the stages to eliminate unneeded code, but it seems like a worthwhile area for optimization.

[mbechard]

This is something I relied heavily on with GLSL/OpenGL, via the compilers that AMD and Nvidia shipped with their drivers.
In particular since interface variable resources are very limited, the ability to eliminate unused interface variables is critical. My user-facing GLSL API declares 8 sets of texture coordinates (in vec3 uv[8]) coming into the vertex shader that the end users may or may not use. These are usually not used, but must always be declared so the user's shaders always compile cleanly, even if the geometry doesn't have 8 sets of texture coordinates (in which case I provide a default value for the attribute).
With Vulkan now this always eats up 8 input attributes, so it's a step backwards.

[s-perron]

Passes have been added that can do this. See #4970.

[jherico]

That was like two jobs ago, but thanks!