[Mesa-dev] [PATCH] glsl: Only force varyings to be flat when varying packing.

[Timothy Arceri]

On Wed, 2016-08-31 at 16:40 -0700, Kenneth Graunke wrote:
> Varying packing would like to mark certain variables as flat.
> This works as long as both sides of the interfaces are changed
> accordingly.
> 
> For tessellation shaders, we disable varying packing, so this
> requirement doesn't exist.  Several CTS tests use separable TCS
> and TES programs, and this ends up marking the TES input as flat,
> while leaving the TCS output alone.

Seems reasonable but isn't the real reason this fixes things because we
disable packing for outward facing SSO rather than because we disable
packing for tessellation. In other words can't this happen for other
stages too? If so maybe reword the commit message slightly.

Otherwise:

Reviewed-by Timothy Arceri <timothy.arceri at collabora.com>

> 
> Fixes CTS tests:
> *.tessellation_shader.tessellation_control_to_tessellation_evaluation
> .gl_MaxPatchVertices_Position_PointSize
> 
> Also fixes Piglit's spec/oes_geometry_shader/sso_validation:
> - user-defined-gs-input-not-in-block.shader_test
> - user-defined-gs-input-in-block.shader_test
> 
> Signed-off-by: Kenneth Graunke <kenneth at whitecape.org>
> ---
>  src/compiler/glsl/link_varyings.cpp | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/src/compiler/glsl/link_varyings.cpp
> b/src/compiler/glsl/link_varyings.cpp
> index 1bce3e0..1fad310 100644
> --- a/src/compiler/glsl/link_varyings.cpp
> +++ b/src/compiler/glsl/link_varyings.cpp
> @@ -1390,8 +1390,9 @@ varying_matches::record(ir_variable
> *producer_var, ir_variable *consumer_var)
>        (producer_var->type->contains_integer() ||
>         producer_var->type->contains_double());
>  
> -   if (needs_flat_qualifier ||
> -       (consumer_stage != -1 && consumer_stage !=
> MESA_SHADER_FRAGMENT)) {
> +   if (!disable_varying_packing &&
> +       (needs_flat_qualifier ||
> +        (consumer_stage != -1 && consumer_stage !=
> MESA_SHADER_FRAGMENT))) {
>        /* Since this varying is not being consumed by the fragment
> shader, its
>         * interpolation type varying cannot possibly affect
> rendering.
>         * Also, this variable is non-flat and is (or contains) an
> integer