i965: Make fs gl_PrimitiveID input work even when there's no gs.

When a geometry shader is present, the fragment shader gl_PrimitiveID
input acts like an ordinary varying, receiving data from the gs
gl_PrimitiveID output.  When there's no geometry shader, we have to
ask the fixed function SF hardware to provide the primitive ID to the
fragment shader instead.

Previously, the SF setup code would handle this situation by
recognizing that the FS gl_PrimitiveID input didn't match to any VS
output; since normally an FS input with no corresponding VS output
leads to undefined data, the SF setup code used to just arbitrarily
assign it to receive data from attribute 0.

This patch changes the SF setup code so that instead of arbitrarily
using attribute 0, it assigns the unmatched FS input to receive
gl_PrimitiveID.  In the case where the FS input really is
gl_PrimitiveID, this produces the intended result.  In all other
cases, no harm is done since GL specifies that the behaviour is
undefined.

Fixes piglit test primitive-id-no-gs.
i965/gs: Set force_writemask_all when setting up g0.

All geometry shaders begin this instruction:

    mov(1) g0.2<1>:ud 0x0:ud { align1 }

which sets up GRF0 properly for scratch reads and writes.  Since this
instruction has a SIMD size of 1, it will only have an effect if the
first channel is enabled.  In practice, the hardware seems to always
dispatch geometry shaders with the first channel enabled, but I can't
find anything in the docs to guarantee that.

So to be on the safe side, set force_writemask_all on the instruction,
which guarantees that it will have the desired effect regardless of
which channels are enabled.
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.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70604
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.

v2: move the source register region fixup to the top of
vec4_generator::generate_vec4_instruction(), so that it applies to all
instructions rather than just MOV.

Reviewed-by: Eric Anholt <eric@anholt.net>
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.

Reviewed-by: Eric Anholt <eric@anholt.net>
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>
glsl: Pull interpolation_string() out of ir_variable.

Future patches will need to call this function when there isn't an
ir_varible present to refer to.
glsl: Extract interpretation of interpolation to its own function.

In future patches, we will need this in order to interpret
interpolation qualifiers that appear inside interface blocks.
glsl: Pass variable mode into ast_process_structure_or_interface_block().

Later patches will use this information to do proper error checking of
interpolation qualifiers that appear inside of interface blocks.
glsl: Keep track of centroid/interpolation mode for interface block members.

Fixes piglit tests:
- interface-block-interpolation-{array,named,unnamed}
- glsl-1.50-interface-block-centroid {array,named,unnamed}
glsl/gs: Prevent illegal input/output primitive types.

From the GLSL 1.50 spec, section 4.3.8.1 (Input Layout Qualifiers):

    The layout qualifier identifiers for geometry shader inputs are

        layout-qualifier-id
            points
            lines
            lines_adjacency
            triangles
            triangles_adjacency

And from section 4.3.8.2 (Output Layout Qualifiers)

    The layout qualifier identifiers for geometry shader outputs are

        layout-qualifier-id
            points
            line_strip
            triangle_strip
            max_vertices = integer-constant

We were erroneously allowing line_strip and triangle_strip to be used
as input qualifiers, and we were allowing lines, lines_adjacency,
triangles, and triangles_adjacency to be used as output qualifiers.

Fixes piglit tests "glsl-1.50-gs-{input,output}-layout-qualifiers *".
i965/fs: Only unroll high-accuracy dFdy() from SIMD16 to SIMD8 on gen4 and IVB.

In commit 800610f (i965/fs: Improve accuracy of dFdy() to match
dFdx()) I unrolled the high-accuracy dFdy() computation from a single
SIMD16 instruction to two SIMD8 instructions because of text I found
in the i965 (gen4) PRM saying that instruction compression could not
be used in align16 mode.  I couldn't find similar text in later
hardware docs, and I observed problems trying to use instruction
compression on align16 mode on Ivy Bridge, so I assumed that the
restriction still applied and the associated documentation had simply
been lost.

After consultation with the hardware engineers, it turns out this is
not the case.  In point of fact, the restriction was dropped in gen5,
re-introduced in Ivy Bridge, and dropped again in Haswell.  The reason
I didn't notice this is that in the Ivy Bridge documentation, the
restriction was in a different section, and described using different
language.

Now that we know that the restriction only applies to Gen4 and Ivy
Bridge, we can limit the unrolling to those platforms.

Tested on gen5, gen6, and gen7 (both Ivy Bridge and Haswell).
glsl: mark variables produced by lower_named_interface_blocks.

These variables will need to be treated specially by
program_resource_visitor, so that they can be addressed through the
API using their interface block name (and array index, for interface
block arrays).
glsl: Account for interface block lowering in program_resource_visitor.

When program_resource_visitor visits variables that were created by
lower_named_interface_blocks, it needs to do extra work to un-do the
effects of lower_named_interface_blocks and construct the proper API
names.

Fixes piglit test
spec/glsl-1.50/execution/interface-blocks-api-access-members.