mesa: Remove warning that geometry shader support is experimental.

Geometry shader support is now working well, and adequately piglit
tested.  There are just a few piglit failures left to fix.  So there's
no need for an "experimental" warning anymore.
i965: Turn on GLSL 1.50 and GL 3.2 support for i965 gen7.

Geometry shaders were the last thing we needed to finish before
turning on GLSL 1.50 and GL 3.2 support.  They are now working well,
with just a few piglit failures left to fix.
!UPSTREAM: i965/gs: Generalize some error messages for GS.

TODO: find more places to generalize.
TODO: Don't use "VS/GS" terminology.  Use "vec4" terminology, since that will endure longer.
!UPSTREAM: glsl: Add new geometry shader constants.

TOOD:
- These constants need to be plumbed through to the driver back-ends.
!UPSTREAM: mesa: fix transform feedback when a geometry shader is active.

TODO: test
!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: Debug optimization passes.
vbo: Make vbo_sw_primitive_restart optionally count primitives.

This will be necessary in order to get the i965 back-end to produce
the correct value of gl_PrimitiveIDIn when using software primitive
restart.
!UPSTREAM: i965/gs: Fix gl_PrimitiveIDIn when using SW primitive restart.

TODO: We really ought to set _NEW_PROGRAM_CONSTANTS only when software
primitive restart is in use.  Currently we set it for hardware
primitive restart too.
!UPSTREAM: i965/gs: Set the REORDER bit in 3DSTATE_GS.

Ivy Bridge's "reorder enable" bit gives us a binary choice for the
order in which vertices from triangle strips are delivered to the
geometry shader.  Neither choice follows the OpenGL spec, but setting
the bit is better, because it gets triangle orientation correct.

Haswell replaces the "reorder enable" bit with a new "reorder mode"
bit (which occupies the same location in the command packet).  This
bit gives us a different binary choice, which affects both triangle
strips and triangle strips with adjacency.  Setting the bit gives the
proper order according to the OpenGL spec.

So in either case we want to set the bit.

On Ivy Bridge, fixes piglit test
spec/glsl-1.50/execution/geometry/triangle-strip-orientation.

On Haswell, should fix piglit tests
spec/glsl-1.50/glsl-1.50-geometry-primitive-types
{GL_TRIANGLE_STRIP,GL_TRIANGLE_STRIP_ADJACENCY}, but I haven't tested
this.

TODO: test on HSW
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.

A problem with consulting the primitive ID is that if primitive
restart is in use, triangles may have opposite parity relative to the
entire draw call vs. relative to the strip.  We need to look at the
parity of the triangle relative to the strip.  Fortunately, we can
work around this by using software primitive restart in this case.

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

- Consider dropping this whole sub-series, since it still doesn't do
  the right thing in the presence of instanced rendering.
i965/fs: Remove bogus field prog_data->dispatch_width.

Despite the name, this field wasn't being set to the dispatch width at
all; it was always 8.  The only place it was used was that the
constant buffer read length was aligned to it, and as far as I can
tell from the docs, there is no need to align this value to the
dispatch width; aligning it to a multiple of 8 is sufficient.  So I've
just replaced it with a hardcoded 8.