glsl: In update_max_array_access, fix interface instance check.

In commit f878d20 (glsl: Update ir_variable::max_ifc_array_access
properly), I accidentally used the wrong kind of check to determine
whether the variable being accessed was an interface instance (I used
var->get_interface_type() != NULL when I should have used
var->is_interface_instance()).  As a result, if an unnamed interface
block contained a struct which contained an array,
update_max_array_access() would mistakenly interpret the struct as a
named interface block and try to dereference a null
var->max_ifc_array_access.

This patch corrects the check, fixing the null dereference.

Fixes piglit test interface-block-struct-nesting.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70368
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.
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.
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.
i965/gs: Add the ability to compile a DUAL_INSTANCED geometry shader.

Not yet enabled.
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=nogualobj.
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.
!UPSTREAM: i965/gs: fix up primitive ID workaround for DUAL_INSTANCE dispatch.

TODO:

- Add better explanatory comments in generate_vec4_instruction.
!UPSTREAM: 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.
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