i965: Compute dFdy() correctly for FBOs.

On i965, dFdx() and dFdy() are computed by taking advantage of the
fact that each consecutive set of 4 pixels dispatched to the fragment
shader always constitutes a contiguous 2x2 block of pixels in a fixed
arrangement known as a "sub-span".  So we calculate dFdx() by taking
the difference between the values computed for the left and right
halves of the sub-span, and we calculate dFdy() by taking the
difference between the values computed for the top and bottom halves
of the sub-span.

However, there's a subtlety when FBOs are in use: since FBOs use a
coordinate system where the origin is at the upper left, and window
system framebuffers use a coordinate system where the origin is at the
lower left, the computation of dFdy() needs to be negated for FBOs.

This patch modifies the fragment shader back-ends to negate the value
of dFdy() when an FBO is in use.  It also modifies the code that
populates the program key (brw_wm_populate_key() and
brw_fs_precompile()) so that they always record in the program key
whether we are rendering to an FBO or to a window system framebuffer;
this ensures that the fragment shader will get recompiled when
switching between FBO and non-FBO use.

This will result in unnecessary recompiles of fragment shaders that
don't use dFdy().  To fix that, we will need to adapt the GLSL and
NV_fragment_program front-ends to record whether or not a given shader
uses dFdy().  I plan to implement this in a future patch series; I've
left FIXME comments in the code as a reminder.

Fixes Piglit test "fbo-deriv".

NOTE: This is a candidate for stable release branches.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Add IsCentroid bitfield to gl_fragment_program.

This bitfield tells the back-ends which of a fragment shader's inputs
require centroid interpolation.  It is only set for GLSL fragment
shaders, since assembly fragment shaders don't support centroid
interpolation.
i965/msaa: Adapt clip setup for centroid noperspective interpolation.

To save time, we only instruct the clip stage of the pipeline to
compute noperspective barycentric coordinates if those coordinates are
needed by the fragment shader.  Previously, we would determine whether
the coordinates were needed by seeing whether the fragment shader used
the BRW_WM_NONPERSPECTIVE_PIXEL_BARYCENTRIC interpolation mode.

However, with MSAA, it's possible that the fragment shader might use
BRW_WM_NONPERSPECTIVE_CENTROID_BARYCENTRIC instead.  In the future,
when we support ARB_sample_shading, it might use
BRW_WM_NONPERSPECTIVE_SAMPLE_BARYCENTRIC.

This patch modifies the upload_clip_state() functions to check for all
three possible noperspective interpolation modes.
i965/fs: Refactor interpolation code to prepare for adding centroid support.
i965/msaa: Add backend support for centroid interpolation.

This patch causes the fragment shader to be configured correctly (and
the correct code to be generated) for centroid interpolation.  This
required two changes: brw_compute_barycentric_interp_modes() needs to
determine when centroid barycentric coordinates need to be included in
the pixel shader thread payload, and
fs_visitor::emit_general_interpolation() needs to interpolate using
the correct set of barycentric coordinates.

Fixes piglit tests "EXT_framebuffer_multisample/interpolation {2,4}
centroid-edges" on i965.
i965/fs: Add FS_OPCODE_GET_MASK to fragment shader backend.

In order to compute centroid varyings correctly, the fragment shader
needs to be able to load the current pixel/sample mask into a flag
register.  This patch adds an opcode to the fragment shader back-end
to do this; the opcode gets translated into the instruction

mov(1)  f0<1>UW  g1.14<0,1,0>UW  { align1 WE_all }

Since this instruction clobbers f0, instruction scheduling has to
treat it the same as instructions that have a conditional modifier.
i965/msaa: Fix centroid interpolation of unlit pixels.

i965 hardware doesn't do centroid interpolation correctly on unlit
pixels, causing incorrect values for derivatives near triangle edges.
To work around this problem, after doing centroid interpolation, we
replace the centroid-interpolated values for unlit pixels with
non-centroid-interpolated values (which are interpolated at pixel
centers).  This produces correct rendering at the expense of a slight
increase in shader execution time.

I've conditioned the workaround with a runtime flag
(brw->needs_unlit_centroid_workaround) in the hopes that we won't need
it in future chip generations.

Fixes piglit tests "EXT_framebuffer_multisample/interpolation {2,4}
{centroid-deriv,centroid-deriv-disabled}".  All MSAA interpolation
tests pass now.