glsl: Rework builtin_variables.cpp to reduce code duplication.

Previously, we had a separate function for setting up the built-in
variables for each combination of shader stage and GLSL version
(e.g. generate_110_vs_variables to generate the built-in variables for
GLSL 1.10 vertex shaders).  The functions called each other in ad-hoc
ways, leading to unexpected inconsistencies (for example,
generate_120_fs_variables was called for GLSL versions 1.20 and above,
but generate_130_fs_variables was called only for GLSL version 1.30).
In addition, it led to a lot of code duplication, since many varyings
had to be duplicated in both the FS and VS code paths.  With the
advent of geometry shaders (and later, tessellation control and
tessellation evaluation shaders), this code duplication was going to
get a lot worse.

So this patch reworks things so that instead of having a separate
function for each shader type and GLSL version, we have a function for
constants, one for uniforms, one for varyings, and one for the special
variables that are specific to each shader type.

In addition, we use a class, builtin_variable_generator, to keep track
of the instruction exec_list, the GLSL parse state, commonly-used
types, and a few other variables, so that we don't have to pass them
around as function arguments.  This makes the code a lot more compact.

Where it was feasible to do so without introducing compilation errors,
I've also gone ahead and introduced the variables needed for
{ARB,EXT}_geometry_shader4 style geometry shaders.  This patch takes
care of everything except the GS variable gl_VerticesIn, the FS
variable gl_PrimitiveID, and GLSL 1.50 style geometry shader inputs
(using the gl_in interface block).  Those remaining features will be
added later.

I've also made a slight nomenclature change: previously we used the
word "deprecated" to refer to variables which are marked in GLSL 1.40
as requiring the ARB_compatibility extension, and are marked in GLSL
1.50 onward as requiring the compatibilty profile.  This was
misleading, since not all deprecated variables require the
compatibility profile (for example gl_FragData and gl_FragColor, which
have been deprecated since GLSL 1.30, but do not require the
compatibility profile until GLSL 4.20).  We now consistently use the
word "compatibility" to refer to these variables.

This patch doesn't introduce any functional changes (since geometry
shaders haven't been enabled yet).

Reviewed-by: Matt Turner <mattst88@gmail.com>

v2: Rename "typ" -> "type".  Add blank line between inline functions
and declarations in builtin_variable_generator class.  Use the
standard comment "/* FALLTHROUGH */" for compatibility with static
code analysis tools.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
main: do nothing in the ff fragment shader when using the core profile.

When the core profile is active, there is no fixed function fragment
shader functionality.  However, we still need to generate a dummy
fragment shader program in case the back-end expects it (e.g. to cover
the case where GL_RASTERIZER_DISCARD is active and the client hasn't
supplied a fragment shader).

This patch makes the dummy fragment shader program do nothing when the
core profile is active.  This will prevent breakages in later patches,
when we stop exposing compatibility-only builtin variables in the core
profile.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Add const safety to _mesa_glsl_parse_state::is_version()

Needed for the patch that follows.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Stop exposing compatibility-only builtin vars in the core profile.

GL 3.2 and GLSL 1.50 specify that several builtin variables
(e.g. gl_FrontColor) are available only in the compatibility profile.
GL 3.1 and GLSL 1.40 make a similar stipulation (except phrased in
terms of ARB_compatibility).

Previous versions of GLSL make no such stipulation.  However, since GL
versions 3.1 and above are allowed to be mixed with older versions of
GLSL, we need to avoid exposing those compatibility-only builtin
variables for older GLSL versions too.  Otherwise we open up a
loophole to allow compatibility-only features to be used in a core
context.

In the process I've moved the logic for determining whether
compatibility-only GLSL features are active into
_mesa_glsl_parse_state, so that we'll be able to use it to switch
other GLSL features on and off (this will be used in the next patch,
which fixes ftransform()).

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl/builtins: Stop exposing ftransform in the core profile.

GL 3.2 and GLSL 1.50 specify that the ftransform() function is
available only in the compatibility profile.  GL 3.1 and GLSL 1.40
make a similar stipulation (except phrased in terms of
ARB_compatibility).

Previous versions of GLSL make no such stipulation.  However, since GL
versions 3.1 and above are allowed to be mixed with older versions of
GLSL, we need to avoid exposing ftransform() in the core profile for
older GLSL versions too.  Otherwise we open up a loophole to allow
compatibility-only features to be used in a core context.

To avoid exposing ftransform() in core contexts in GLSL 1.30, I had to
remove it from the 110.vert, 120.vert, and 130.vert profile files, and
move it to a new profile file called "compatibility.vert", which takes
effect only when state->compatibility() returns true.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl/linker: Make update_array_sizes apply to just uniforms.

Commit 586b4b5 (glsl: Also update implicit sizes of varyings at link
time) extended update_array_sizes() to apply to both uniforms and
shader ins/outs.  However, doing creates problems for geometry
shaders, because update_array_sizes() assumes that variables with
matching names in different parts of the pipeline should have the same
sizes.  With the addition of geometry shaders, this is no longer true
(e.g. both vertex and geometry shaders have a gl_ClipDistance output
variable, but there's no reason these variables should have the same
sizes).

The original reason for commit 586b4b5 (avoid problems with
gl_TexCoord being 0 length) has since been addressed by commit 6f53921
(linker: Ensure that unsized arrays have a size after linking).  So go
ahead and switch update_array_sizes() back to only acting on uniforms.
!UPSTREAM: glsl: Enable various extensions for geometry shaders.

Note: In principle there's no reason geometry shaders couldn't support
OES_texture_3D and OES_EGL_image_external, but it seems silly to
enable them, since these are GLSL ES extensions, and geometry shaders
aren't allowed in GLSL ES.

TODO:
- Better commit message
- Better testing
main: Fix geometry shader error messages (missing right paren)
!UPSTREAM ===== BEGIN rebase of Plombo's GS patches =====
draw/gs: fix allocation of buffer for GS output vertices

Before, it accounted for the size of the vertices but not the other fields
in the vertex_header struct, which caused memory corruption.
mesa: add EXT_geometry_shader4 and ARB_geometry_shader4 to extension list
mesa: account for geometry shader texture fetches in update_texture_state
glcpp: define extension macros for EXT/ARB_geometry_shader4
glsl: add builtins for EXT/ARB_geometry_shader4

v2 (Paul Berry <stereotype441@gmail.com>): Account for rework of
builtin_variables.cpp.
glsl: add ir_emitvertex and ir_endprim instruction types

These correspond to the EmitVertex and EndPrimitive functions in GLSL.

v2 (Paul Berry <stereotype441@gmail.com>): Add stub implementations of
new pure visitor functions to i965's vec4_visitor and fs_visitor
classes.
glsl: lower gl_ClipDistanceIn to gl_ClipDistanceInMESA in lower_clip_distance

This corresponds to the lowering of gl_ClipDistance to gl_ClipDistanceMESA.
It converts the 2D array gl_ClipDistanceIn from EXT/ARB_geometry_shader4 to
a 1D array of vec4s, gl_ClipDistanceInMESA.

v2 (Paul Berry <stereotype441@gmail.com>): Fix indexing order for
gl_ClipDistanceIn lowering.  Properly lower bulk assignment of
gl_ClipDistanceIn[i].
glsl: support compilation of geometry shaders via EXT/ARB_geometry_shader4

This commit adds all of the parsing and semantics for EXT/ARB_geometry_shader4,
including support for 2D arrays as inputs.

v2 (Paul Berry <stereotype441@gmail.com>): Adjust i965's
brw_link_shader() to pass the new is_geometry_shader argument to
do_set_program_inouts.  Add a few missing calls to
get_pipeline_stage().  Fix some signed/unsigned comparison warnings.
Fix handling of NULL consumer in assign_varying_locations().

v3 (Bryan Cain <bryancain3@gmail.com>): fix indexing order of 2D
arrays.  Also, allow interpolation qualifiers in geometry shaders.

v4 (Paul Berry <stereotype441@gmail.com>): Eliminate
get_pipeline_stage()--it is no longer needed thanks to 030ca23 (mesa:
renumber shader indices according to their placement in pipeline).
mesa: Refactor copying of linked program data.

This patch creates a single function to copy the the UsesClipDistance
flag from gl_shader_program.Vert to gl_vertex_program.  Previously
this logic was duplicated in the i965-specific function
brw_link_shader() and the core mesa function _mesa_ir_link_shader().

This logic will have to be expanded to support geometry shaders, and I
don't want to have to update it in two separate places.
mesa: Copy linked program data for GS.

The documentation for gl_shader_program.Geom and gl_geometry_program
says that the former is copied to the latter at link time, but this
wasn't happening.  This patch causes _mesa_ir_link_shader() to perform
the copy, and updates comment accordingly.
glsl: Require geometry shader inputs to be arrays.