main: Warn that geometry shader support is experimental.

Geometry shader support in the Mesa front end is still fairly
preliminary.  Many features are untested, and the following things are
known not to work:

- The gl_in interface block
- The gl_ClipDistance input
- Transform feedback of geometry shader outputs
- Constants that are new in GLSL 1.50 (e.g. gl_MaxGeometryInputComponents)

This isn't a problem, since no back-end drivers currently enable
geometry shaders.  However, to make sure no one gets the wrong
impression, emit a nasty warning to let the user know that geometry
shader support isn't complete.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
!UPSTREAM ===== END first series =====
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/st: Add VARYING_SLOT_TEX[1-7] to st_translate_geometry_program().

v2 (Paul Berry <stereotype441@gmail.com>: Split out to separate patch
(previously this was part of "glsl: add builtins for geometry
shaders.")
st/mesa, glsl_to_tgsi: add support for geometry shaders

v2 (Bryan Cain <bryancain3@gmail.com>): fix 2D array indexing order.
gallivm: Fix indirect input fetches for gs.
gallium/draw: Pass primitive ID as integer to the shader.

The shader interprets the value as an integer.
mesa/st: Allow geometry shaders without gl_Position export.

From the ARB_geometry_shader4 spec (section Geometry Shader outputs):
"The built-in special variable gl_Position is intended to hold the
homogeneous vertex position. Writing gl_Position is optional."
!UPSTREAM: 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].

TODO: May need to rework for GLSL 1.50.
!UPSTREAM: glsl/linker: Fail if linking geometry shader with 0 GEOMETRY_VERTICES_OUT.

ARB_geometry_shader4 spec 2.15.2:
"Linking will also fail [...] if the program object contains objects to form a
geometry shader, and the value of GEOMETRY_VERTICES_OUT_ARB is zero."

Reviewed-by: Paul Berry <stereotype441@gmail.com>

TODO: May not be necessary for GLSL 1.50 style geometry shaders.  Make a test to validate.
!UPSTREAM: mesa: fix transform feedback when a geometry shader is active

TODO: test
!UPSTREAM: Fix up GS handling of gl_ClipDistance/gl_ClipVertex linkage rules.

TODO:
- Test
- Squash
!UPSTREAM: make stuff safe to include from C++

TODO:
- Split
i965: Initialize all elements of ctx->ShaderCompilerOptions

Otherwise any GS that requires lowering (e.g. one that uses
gl_ClipDistance or gl_ClipDistanceIn) will fail to work.
i965: Stop including brw_vs.h from brw_vec4.h

This is backwards from what we are going to want in the long term, which is:

- brw_vec4.h declares general-purpose vec4 infrastructure needed by
  both VS and GS
- brw_vs.h includes brw_vec4.h and adds VS-specific parts.
- brw_gs.h includes brw_vec4.h and adds GS-specific parts.

Note that at the moment brw_vec.h contains a fair amount of
VS-specific declarations--I plan to address that in a later patch.
!UPSTREAM: i965/vec4: Allow for dispatch_grf_start_reg to vary.

Both 3DSTATE_VS and 3DSTATE_GS have a dispatch_grf_start_reg control,
which determines the register where the hardware delivers data sourced
from the URB (push constants followed by per-vertex input data).

For vertex shaders, we always set dispatch_grf_start_reg to 1, since
R1 is always the first register available for push constants in vertex
shaders.

For geometry shaders, we'll need the flexibility to set
dispatch_grf_start_reg to different values depending on the behvaiour
of the geometry shader; if it accesses gl_PrimitiveIDIn, we'll need to
set it to 2 to allow the primitive ID to be delivered to the thread in
R1.

This patch eliminates the assumption that dispatch_grf_start_reg is
always 1.  In vec4_visitor, we record the regnum that was passed to
vec4_visitor::setup_uniforms() in prog_data for later use.  In
vec4_generator, we consult this value when converting an abstract
UNIFORM register to a concrete hardware register.  And in the code
that emits 3DSTATE_VS, we set dispatch_grf_start_reg based on the
value recorded in prog_data.

This will allow us to set dispatch_grf_start_reg to the appropriate
value when compiling geometry shaders.  Vertex shaders will continue
to always use a dispatch_grf_start_reg of 1.

TODO:
- Move into the proper part of the series.
!UPSTREAM: i965/vec4: Virtualize setup_payload instead of setup_attributes
i965: Add brw->geometry_program
!UPSTREAM: i965: Add an opcode for doing a URB write with an offset from a register (needed for GS).
!UPSTREAM: i965: Add GS_OPCODE_THREAD_END

TODO:
- Verify that I'm returning the correct value from implied_mrf_writes() for this new opcode.