glsl: Clean up case statement in builtin_variables.cpp's add_variable.

The case statement purported to handle the addition of ir_var_const_in
and ir_var_inout builtin variables.  But no such variables exist.
This patch removes the unnecessary cases, and adds a comment
explaining why they're not needed.

Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
glsl: Eliminate ambiguity between function ins/outs and shader ins/outs

This patch replaces the three ir_variable_mode enums:

- ir_var_in
- ir_var_out
- ir_var_inout

with the following five:

- ir_var_shader_in
- ir_var_shader_out
- ir_var_function_in
- ir_var_function_out
- ir_var_function_inout

This eliminates a frustrating ambiguity: it used to be impossible to
tell whether an ir_var_{in,out} variable was a shader in/out or a
function in/out without seeing where the variable was declared in the
IR.  This complicated some optimization and lowering passes, and would
have become a problem for implementing varying structs.

In the lisp-style serialization of GLSL IR to strings performed by
ir_print_visitor.cpp and ir_reader.cpp, I've retained the names "in",
"out", and "inout" for function parameters, to avoid introducing code
churn to the src/glsl/builtins/ir/ directory.

Note: a couple of comments in the code seemed to indicate that we were
planning for a possible future in which geometry shaders could have
shader-scope inout variables.  Our GLSL grammar rejects shader-scope
inout variables, and I've been unable to find any evidence in the GLSL
standards documents (or extensions) that this will ever be allowed, so
I've eliminated these comments.

Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
glsl: Disable structure splitting for shader ins/outs.

Previously, it didn't matter whether structure splitting tried to
split shader ins/outs, because structs were prohibited from being used
for shader ins/outs.  However, GLSL 3.00 ES supports varying structs.
In order for varying structs to work, we need to make sure that
structure splitting doesn't get applied to them, because if it does,
then the linker won't be able to match up varyings properly.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
glsl: Generalize compute_packing_order for varying structs.

This patch paves the way for allowing varying structs by generalizing
varying_matches::compute_packing_order to handle any type of varying.
Previously, we packed in the order (vec4, vec2, float, vec3), with
matrices being packed according to the size of their columns.  Now, we
pack everything according to its number of components mod 4, in the
order (0, 2, 1, 3).

There is no behavioural change for vectors.  Matrices are now packed
slightly differently:

- mat2x2 gets assigned PACKING_ORDER_VEC4 instead of
  PACKING_ORDER_VEC2.  This is slightly better, because it guarantees
  that the matrix occupies a single varying slot.

- mat2x3 gets assigned PACKING_ORDER_VEC2 instead of
  PACKING_ORDER_VEC3.  This is kind of a wash.  Previously, mat2x3 had
  a 25% chance of having neither of its columns double parked, a 50%
  chance of having exactly one of its columns double parked, and a 25%
  chance of having both of its columns double parked.  Now it always
  has exactly one of its columns double parked.

- mat3x3 gets assigned PACKING_ORDER_SCALAR instead of
  PACKING_ORDER_VEC3.  This doesn't affect much, since in both cases
  there is no guarantee of how the matrix will be aligned.

- mat4x2 gets assigned PACKING_ORDER_VEC4 instead of
  PACKING_ORDER_VEC2.  This is slightly better for the same reason as
  in mat2x2.

- mat4x3 gets assigned PACKING_ORDER_VEC4 instead of
  PACKING_ORDER_VEC3.  This is slightly better for the same reason as
  in mat2x2.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
glsl: Update lower_packed_varyings to handle varying structs.

This patch adds code to lower_packed_varyings to handle varyings of
type struct.  Varying structs are currently packed in the most naive
possible way (in declaration order, with no gaps), so there is a
potential loss of runtime efficiency.  In a later patch it would be
nice to replace this with a "flattening" approach (wherein a varying
struct is flattened to individual varyings corresponding to each of
its structure elements), so that the linker can align each structure
element independently.  However, that would require a significantly
more complex implementation.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
glsl: Disable transform feedback of varying structs.

It is not clear from the GLSL ES 3.00 spec how transform feedback is
supposed to apply to varying structs:

- There is no specification for how the structure is to be packed when
  it is recorded into the transform feedback buffer.

- There is no reasonable value for GetTransformFeedbackVarying to
  return as the "type" of the variable.

We currently have a Khronos bug requesting clarification on how this
feature is supposed to work
(https://cvs.khronos.org/bugzilla/show_bug.cgi?id=9856).

This patch just disables transform feedback of varying structs for
now; we can implement the proper behaviour once we find out from
Khronos what it is.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
glsl: Allow varying structs in GLSL ES 3.00 and GLSL 1.50.

Previously I thought that varying structs had been added to GLSL ES
3.00 by mistake, because chapter 11 of the GLSL ES 3.00 spec
("Counting of Inputs and Outputs") failed to mention how structs
should be handled.  Khronos has clarified
(https://cvs.khronos.org/bugzilla/show_bug.cgi?id=9828) that varying
structs are indeed required, and that chapter 11 will be modified to
indicate that the minimal reference packing algorithm flattens varying
structs to their individual components.

Mesa doesn't flatten varying structs to their individual components,
but this is ok, since it packs varyings of all kinds with no wasted
space at all (except where this is impossible due to differing
interpolation modes), so it will outperform the minimal reference
packing algorithm in all but the most pathological cases.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>