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 ("reorder
trailing") 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 "triangle-strip-orientation".

On Haswell, fixes piglit tests "glsl-1.50-geometry-primitive-types
{GL_TRIANGLE_STRIP,GL_TRIANGLE_STRIP_ADJACENCY}" and
"glsl-1.50-geometry-tri-strip-ordering-with-prim-restart *".

v2: Rename the bit to "REORDER_TRAILING" for consistency with Haswell
docs.

Reviewed-by: Matt Turner <mattst88@gmail.com>
mesa: fix transform feedback when a geometry shader is active.

When a geometry shader is active, the transform feedback primitive
type ("mode") needs to be validated against the geometry shader output
primitive type, not the primitive type passed to the glDraw*()
function.

Fixes the following piglit tests:
- glsl-1.50-geometry-primitive-types GL_LINES
- glsl-1.50-geometry-primitive-types GL_LINES_ADJACENCY
- glsl-1.50-geometry-primitive-types GL_LINE_STRIP
- glsl-1.50-geometry-primitive-types GL_LINE_STRIP_ADJACENCY
- glsl-1.50-geometry-primitive-types GL_TRIANGLES
- glsl-1.50-geometry-primitive-types GL_TRIANGLES_ADJACENCY
- glsl-1.50-geometry-primitive-types GL_TRIANGLE_FAN

Exposes previously hidden failures in the following piglit tests:
- glsl-1.50-geometry-primitive-id-restart GL_LINES other
- glsl-1.50-geometry-primitive-id-restart GL_LINES_ADJACENCY other
- glsl-1.50-geometry-primitive-id-restart GL_LINE_LOOP ffs
- glsl-1.50-geometry-primitive-id-restart GL_LINE_LOOP other
- glsl-1.50-geometry-primitive-id-restart GL_LINE_STRIP other
- glsl-1.50-geometry-primitive-id-restart GL_LINE_STRIP_ADJACENCY other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLES other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLES_ADJACENCY other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_FAN ffs
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_FAN other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_STRIP other
- glsl-1.50-geometry-primitive-id-restart GL_TRIANGLE_STRIP_ADJACENCY other

(These failures were previously hidden due to a flaw in the test: it
doesn't check for GL errors.  I'll fix the test shortly).

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
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.
i965/gs: Fix gl_PrimitiveIDIn when using SW primitive restart.

Ivy Bridge hardware doesn't support primitve restart under all
circumstances--when it doesn't, we emulate it in software by splitting
up each logical draw operation into multiple 3DPRIMITIVE commands.
This causes the hardware's primitive ID counter to be reset to 0,
producing incorrect values for gl_PrimitiveIDIn.

To work around that problem, we create a hidden uniform which is added
to the hardware's primitive ID counter at the top of the geometry
shader; the software primitive restart mechanism ensures that this
uniform always contains the number of primitives that were sent down
the pipeline by previous 3DPRIMITIVE commands within the same logical
draw operation.

To reduce the performance impact of the workaround, we only compile it
into the shader when the hardware is Ivy Bridge and the shader
accesses gl_PrimitiveIDIn.  To reduce unnecessary state updates, we
only flag _NEW_PROGRAM_CONSTANTS when when the workaround is compiled
in *and* software primitive restart is active.

On Ivy Bridge, fixes all variants of
"glsl-1.50-geometry-primitive-id-restart" except the GL_LINE_LOOP
variants, which are broken due to an unrelated hardware limitation.
!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/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.
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, ATTR2
    D mov ATTR2, 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, ATTR2
    D mov ATTR2, 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.
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 either primitive
restart or instanced rendering is in use, triangles may have opposite
parity relative to the entire draw call vs. relative to the strip.
Unfortunately there's no easy way around this.  Fortunately, geometry
shaders that truly rely on the proper ordering of vertices within a
triangle strip are likely to be rare, so I think we can live with the
order being wrong when primitive restart or instanced rendering is in
use.

Fixes the following piglit tests on Ivy Bridge:

- glsl-1.50-geometry-primitive-types GL_TRIANGLE_STRIP

- glsl-1.50-geometry-primitive-types GL_TRIANGLE_STRIP_ADJACENCY

- glsl-1.50-geometry-tri-strip-ordering-with-prim-restart
  GL_TRIANGLE_STRIP other

- glsl-1.50-geometry-tri-strip-ordering-with-prim-restart
  GL_TRIANGLE_STRIP_ADJACENCY other
glsl: Allow mixing of GLSL 1.40 and later shader versions.