i965/vec4: Add the ability for attributes to be interleaved.

When geometry shaders are operated in "single" or "dual instanced"
mode, a single set of geometry shader inputs is interleaved into the
thread payload (with each payload register containing a pair of
inputs) in order to save register space.

This patch modifies vec4_visitor::lower_attributes_to_hw_regs so that
it can handle the interleaved format.

Reviewed-by: Eric Anholt <eric@anholt.net>
i965/vec4: if register allocation fails, don't try to schedule.

Otherwise the scheduler would be invoked with prog_data->total_grf ==
0, causing havoc.

In a future patch, this will allow us to try compiling a geometry
shader in DUAL_OBJECT mode with spilling disabled, and then fall back
to DUAL_INSTANCED mode if that failed.

Reviewed-by: Eric Anholt <eric@anholt.net>
i965/vec4: Add the ability to suppress register spilling.

In future patches, this will allow us to first try compiling a
geometry shader in DUAL_OBJECT mode (which is more efficient but uses
more registers) and then if spilling is required, fall back on
DUAL_INSTANCED mode.

Reviewed-by: Eric Anholt <eric@anholt.net>
i965/gs: Add the ability to compile a DUAL_INSTANCED geometry shader.

Not yet enabled.

Reviewed-by: Eric Anholt <eric@anholt.net>
i965/gs: Fix up gl_PointSize input swizzling for DUAL_INSTANCED gs.

Geometry shaders that run in "DUAL_INSTANCED" mode store their inputs
in vec4's.  This means that when compiling gl_PointSize input
swizzling (a MOV instruction which uses a geometry shader input as
both source and destination), we need to do two things:

- Set force_writemask_all to ensure that the MOV happens regardless of
  which channels are enabled.

- Set the source register region to <4;4,1> (instead of <0;4,1> to
  satisfy register region restrictions.
i965/gs: fix up primitive ID workaround for DUAL_INSTANCE dispatch.

Parallel change to "i965/gs: Fix up gl_PointSize input swizzling for
DUAL_INSTANCED gs.", except applied to the gl_PrimitiveID fixup
instead of the gl_PointSize fixup.
i965/gs: If a DUAL_OBJECT gs would spill, fall back to DUAL_INSTANCED.

This is similar to what we do for 16-wide vs 8-wide fragment shaders.
First we try compiling the geometry shader in DUAL_OBJECT mode.  If we
can't do that without spilling, we fall back on DUAL_INSTANCED mode,
which should require less spilling (since it uses an interleaved
layout of payload registers).

In an ideal world we'd fall back to SINGLE mode, which would allow us
to interleave general-purpose registers too (resulting in even less
likelihood of spilling).  But at the moment, the vec4 generator and
visitor classes don't have the infrastructure to interleave general
purpose registers, so DUAL_INSTANCED is the best we can do.

As a side benefit this paves the way for implementing instanced
geometry shaders (which are incompatible with DUAL_OBJECT mode).

Since most geometry shaders used in piglit testing are small,
DUAL_INSTANCED mode won't get exercised very much in a normal piglit
run.  To force DUAL_INSTANCED mode to be used for all geometry
shaders, set INTEL_DEBUG=nodualobj.

Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Reduce gl_MaxGeometryInputComponents to 64.

Although in principle there is no hardware limitation that prevents
gl_MaxGeometryInputComponents from being set to 128 on Gen7, we have
the following limitations in the vec4 compiler back end:

- Registers assigned to geometry shader inputs can't be spilled or
  later re-used for any other purpose.

- The last 16 registers are set aside for the "MRF hack", meaning they
  can only be used to send messages, and not for general purpose
  computation.

- Up to 32 registers may be reserved for push constants, even if there
  is sufficient register pressure to make this impractical.

A shader using 128 geometry input components, and having an input type
of triangles_adjacency, would use up:

- 1 register for r0 (which holds URB handles and various pieces of
  control information).

- 1 register for gl_PrimitiveID.

- 102 registers for geometry shader inputs (17 registers per input
  vertex, assuming DUAL_INSTANCED dispatch mode and allowing for one
  register of overhead for gl_Position and gl_PointSize, which are
  present in the URB map even if they are not used).

- Up to 32 registers for push constants.

- 16 registers for the "MRF hack".

That's a total of 152 registers, which is well over the 128 registers
the hardware supports.

Fortunately, the GLSL 1.50 spec allows us to reduce
gl_MaxGeometryInputComponents to 64.  Doing that frees up 48
registers, brining the total down to 104 registers, leaving 24
registers available to do computation.

Fixes piglit test
spec/glsl-1.50/execution/geometry/max-input-components.

Reviewed-by: Eric Anholt <eric@anholt.net>
mesa: Fix geometry shader program queries.

The queries GEOMETRY_VERTICES_OUT, GEOMETRY_INPUT_TYPE, and
GEOMETRY_OUTPUT_TYPE (defined by GL 3.2) differ from the corresponding
queries in ARB_geometry_shader4 in the following ways:

- They use different enum values

- They can only be queried; they cannot be set.

- Attempting to query them yields INVALID_OPERATION if the program is
  not linked, or lacks a geometry shader.

This patch switches us over from the ARB_geometry_shader4 behaviour to
the GL 3.2 behaviour.

Fixes piglit test query-gs-prim-types.

v2: Improve comment above has_core_gs.
glsl: Call check_builtin_array_max_size when redeclaring gl_in.

Normally when a built-in array (such as gl_ClipDistance) is
redeclared, we call get_variable_being_redeclared() to do the
redeclaration, and it in turn calls check_builtin_array_max_size() to
make sure that the redeclared array size isn't too large.

However when a built-in array is redeclared as part of redeclaring
gl_in, we don't call get_variable_being_redeclared() (since the
individual built-ins aren't each represented by their own ir_variable
anymore).  So we need to add an explicit call to
check_builtin_array_max_size() to make sure the new array size isn't
too large.

Note: at the moment this is redundant with a test that's done at link
time, so there's no change to piglit results.  But the patch that
follows will prevent link errors from being reported if gl_PerVertex
isn't used, so in order to prevent that patch from causing
regressions, we need to add the compile check now.  Besides, it's
nicer to report this error at compile time anyhow.
glsl: Remove unused gl_PerVertex interface blocks.

The GLSL 4.10 rules for redeclaration of built-in interface blocks
(which we've chosen to regard as clarifications of GLSL 1.50) only
require gl_PerVertex blocks to match in shaders that actually use
those blocks.  The easiest way to implement this is to detect
situations where a compiled shader doesn't refer to any elements of
gl_PerVertex, and remove all the associated ir_variables from the
shader at the end of ast-to-ir conversion.

Fixes piglit tests
linker/interstage-{pervertex,pervertex-in,pervertex-out}-redeclaration-unneeded.
glsl: When disabling gl_PerVertex variables, check that mode matches.

In commit 1b4a737 (glsl: Support redeclaration of VS and GS
gl_PerVertex output), I added code to ensure that when an unnamed
gl_PerVertex interface block is redeclared, any ir_variables that
weren't included in the redeclaration are removed from the IR (and the
symbol table).  This ensures that only those variables that were
explicitly redeclared may be used.

However, when I wrote this code, I neglected to match the variable
mode when finding variables to remove.  This meant that redeclaring a
built-in output block might cause the built-in input gl_in to be
accidentally removed.

Fixes piglit test gs-redeclares-pervertex-out-only.
!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: Only set force_writemask_all on attr fixups when DUAL_INSTANCED.

Previously, we set force_writemask_all unconditionally for attr
fixups, because this caused the right thing to happen when compiling
DUAL_INSTANCED geometry shaders and did no harm to DUAL_OBJECT
geometry shaders.

However, we're about to introduce a new attr fixup that reorders
vertices in odd-numbered primitives.  This fixup needs
force_writemask_all to be false for DUAL_OBJECT shaders, because the
two primitives processed by a given DUAL_OBJECT geometry shader thread
are usually going to have opposite parity.

This patch creates a new function, emit_attr_fixup(), which sets
force_writemask_all to true in DUAL_INSTANCED mode, and leaves it
alone in DUAL_OBJECT mode.
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
!UPSTREAM: possible rework of "i965/gs: Fix up gl_PointSize input swizzling for DUAL_INSTANCED gs."