i965/gs: generalize brw_texture_surfaces in preparation for gs.

There is a slight functionality change.  Previously we would compute a
common value for num_samplers for all stages, and populate that many
entries in each stage's surf_offset table regardless of how many
samplers each stage used.  Now we only populate the number of entries
in the surf_offset table corresponding to the number of samplers
actually used by the stage.
i965/gs: add geometry shader support to brw_texture_surfaces.
!UPSTREAM: Primitive ID part 1.
!UPSTREAM: Primitive ID part 2.
!UPSTREAM: Primitive ID part 3.
!UPSTREAM: Primitive ID part 4.
i965/gs: Fixup gl_PointSize on entry to geometry shaders.

gl_PointSize is stored in the w component of VARYING_SLOT_PSIZ, but
the geometry shader infrastructure assumes that it should look for all
geometry shader inputs of type float in the x component.  So when
compiling a geomtery shader that uses a gl_PointSize input, fix it up
during the shader prolog by moving the x component to the w component.

This is similar to how we emit fixups and workarounds for vertex
shader attributes.
!UPSTREAM: i965: Add new primitive types.

TODO: test.
!UPSTREAM: glsl: Add new geometry shader constants.

TOOD:
- These constants need to be plumbed through to the driver back-ends.
main: Expose geometry shader constants in GL 3.0.
!UPSTREAM: WIP: add gl_in to builtin_variables.cpp.
!UPSTREAM: mesa: fix transform feedback when a geometry shader is active.

TODO: test
!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: i965: turn on GS.

TODO:
- Commit message
!UPSTREAM: Debug optimization passes.
!UPSTREAM: Expose GLSL 1.50 and GL 3.2 core contexts.

This lets me run tests normally, since globally doing GL version override
can break tests that require a compatibility context.
i965/vec4: Teach copy propagation about writes to non-GRFs.

During copy propagation, when we encounter an instruction that writes
to register R, we clear out any record of other registers that
previously contained copies of R, since after the write they will
contain the old value of R.

Previously, we only did this for GRFs (since this pass occurs before
register allocation, input ATTRs don't count as GRFs).  As a result,
an instruction stream that moved from an ATTR to a GRF, and then
overwrote the ATTR, might get incorrectly optimized.

In this past this hasn't really been a problem because the only time
we wrote to ATTRs was during vertex attribute fixup, and we never had
a reason to save the old value of the ATTR in a GRF.

However, a future patch will introduce a geometry shader workaround
which re-orders input vertices before executing the body of a geometry
shader--this workaround will produce code like the following:

    A mov tmp, ATTR0
    B mov ATTR0, ATTR1
    C mov ATTR1, tmp

Without this patch, copy propagation would incorrectly conclude that
after instruction B, tmp still contained a copy of ATTR0, so it would
"optimize" this to:

    B mov ATTR0, ATTR1
    C mov ATTR1, ATTR0

Which is clearly incorrect.

The solution is to have copy propagation consider writes to non-GRFs
the same way as writes to GRFs--in either case, the write invalidates
previous copies.
i965/vec4_scheduler: Account for WAW deps between HW_REGs

The vec4 instruction scheduler wasn't accounting for write-after-write
dependencies between fixed hardware registers.  As a result, an
instruction stream that contained a sequence of writes to fixed
hardware registers might get scheduled incorrectly.

In the past this hasn't really been a problem because the only time we
wrote to fixed hardware registers was during vertex attribute fixup,
and these could safely occur in any order.

However, a future patch will introduce a geometry shader workaround
which re-orders input vertices before executing the body of a geometry
shader--this workaround will produce code like the following:

    A mov tmp1 g2
    B mov tmp2 g6
    C mov g2   g18
    D mov g6   g22
    E mov g18  g10
    F mov g22  g14
    G mov g10  tmp1
    H mov g14  tmp2

(where the g's represent fixed hardware registers and the tmps
represent GRFs allocated by the register allocator).

This can't occur in any order; H has a write-after-read dependency on
F (H may not safely write to g14 until after F has read from it).

However, since instruction scheduling operates conservatively with
respect to fixed hardware registers (it regards all fixed hardware
registers as a single unit rather than distinguishing between them),
it sees the above instruction stream as:

    A mov tmp1 g??
    B mov tmp2 g??
    C mov g??  g??
    D mov g??  g??
    E mov g??  g??
    F mov g??  g??
    G mov g??  tmp1
    H mov g??  tmp2

And so it considers G to have a write-after-read dependency on F,
rather than H.  As a result, H may wind up getting scheduled before F,
leading to incorrect execution.

The solution is to consider H to have a write-after-write dependency
on G.  This ensures that H won't get scheduled before F, because of
G's dependency on F.

In the long run we may want to consider modifying instruction
scheduling to distinguish between fixed hardware registers, but that's
a performance concern rather than a correctness concern.  Adding the
write-after-write dependency checking for fixed hardware registers
restores correctness.
!UPSTREAM: i965/gs: Reorder triangle strip vertices on Ivy Bridge.

When rendering a triangle strip or triangle strip with adjacency, Ivy
Bridge doesn't order the input vertices of odd numbered triangles in
the way OpenGL requires.  We work around this by using the primitive
ID to detect which triangles are odd numbered, and rearrange the order
of vertices during the geometry shader prolog.

TODO:
- Confirm that HSW doesn't need this.