!UPSTREAM: main: do nothing in the ff fragment shader when using the core profile.

TODO: idr wants to research specs more and see what nVidia, AMD, and Apple do.

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>
!UPSTREAM: glsl: Add const safety to _mesa_glsl_parse_state::is_version()

TODO: idr wants  to research specs more and see what nVidia, AMD, and Apple do.

Needed for the patch that follows.

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

TODO: idr wants  to research specs more and see what nVidia, AMD, and Apple do.

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>
!UPSTREAM: glsl/builtins: Stop exposing ftransform in the core profile.

TODO: idr wants to research specs more and see what nVidia, AMD, and Apple do.

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.
glsl/linker: Properly error check VS-GS linkage.

From the ARB_geometry_shader4 specification:

    A geometry shader may also read from an input varying variable declared
    with the "varying in" qualifiers. The value read will be the same value as
    written by the vertex shader for that varying variable. Since a geometry
    shader operates on primitives, each input varying variable needs to be
    declared as an array. Each element of such an array corresponds to a
    vertex of the primitive being processed. If the varying variable is
    declared as a scalar or matrix in the vertex shader, it will be a
    one-dimensional array in the geometry shader.

Therefore, a user-defined geometry shader input will always be an
array, and the *element type* of that array should match the type of
the corresponding vertex shader output.