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 *".

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
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).

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
i965: Fix gl_MaxCombinedTextureImageUnits.

We've always overriden
ctx->Const.{Vertex,Fragment}Program.MaxTextureImageUnits to reflect
the number of texture image units supported by the hardware (rather
than using the default values assigned by Mesa core) so it seems
sensible to do that for GeometryProgram.MaxTextureImageUnits too.  We
set it to 0 if geometry shaders aren't supported.

Once that is done, we can just unconditionally add
GeometryProgram.MaxTextureImageUnits to MaxCombinedTextureImageUnits.

Fixes piglit test "spec/glsl-1.50/built-in
constants/gl_MaxCombinedTextureImageUnits".
glsl/gs: Fix transform feedback of gl_ClipDistance.

Since gl_ClipDistance is lowered from an array of floats to an array
of vec4's during compilation, transform feedback has special logic to
keep track of the pre-lowered array size so that attempting to perform
transform feedback on gl_ClipDistance produces a result with the
correct size.

Previously, this special logic always consulted the vertex shader's
size for gl_ClipDistance.  This patch fixes it so that it uses the
geometry shader's size for gl_ClipDistance when a geometry shader is
in use.

Fixes piglit test spec/glsl-1.50/transform-feedback-type-and-size.
glsl: Move UsesClipDistance from gl_{vertex,geometry}_program into gl_program.

This will make it easier for back-ends to share code between geometry
shader and vertex shader compilation.  Also, it is renamed to
"UsesClipDistanceOut" to clarify that (a) in geometry shaders, it
refers to the gl_ClipDistance output rather than the gl_ClipDistance
input, and (b) it is irrelevant in fragment shaders.
i965/vec4: Remove uses_clip_distance from program key.

This should never have been in the program key in the first place,
since it's determined by the shader source, not by GL state.  Change
the code to just refer to gl_program::UsesClipDistanceOut directly.
i965/vec4: Extract function to set up vec4 prog key for precompiling.

This will allow us to re-use it for precompiling geometry shaders.
i965/gs: Precompile geometry shaders.
glsl: set explicit_location correctly in lower_named_interface_blocks.

When lower_named_interface_blocks lowers a built-in interface block
member to an ir_variable, it needs to set explicit_location in the
ir_variable.  Otherwise the linker gets confused and treats the
variable as a generic varying.

Fixes the following piglit tests, which were regressed by commit
63974c0 (glsl: Simplify the interface to
link_invalidate_variable_locations):
- clip-distance-bulk-copy
- clip-distance-in-bulk-read
- clip-distance-in-explicitly-sized
- clip-distance-in-param
- clip-distance-in-values
- core-inputs
- gs-redeclares-both-pervertex-blocks
- gs-redeclares-pervertex-in-only
- redeclare-pervertex-subset-vs-to-gs
- unsized-in-named-interface-block-gs
- unsized-in-named-interface-block-multiple
- unsized-in-unnamed-interface-block-gs
- unsized-in-unnamed-interface-block-multiple
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>