i965/msaa: Work around problems with null render targets on Gen6.

On Gen6, multisampled null render targets don't seem to work
properly--they cause the GPU to hang.  So, as a workaround, we render
into a dummy color buffer.

Fortunately this situation (multisampled rendering without a color
buffer) is rare, and we don't have to waste too much memory, because
we can give the workaround buffer a very small pitch.

Fixes piglit test "EXT_framebuffer_multisample/no-color {2,4}
depth-computed *" on Gen6.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/blorp: Simplify check that src/dst width/height match.

When checking that the source and destination dimensions match, we
don't need to store the width and height in variables; doing so just
risks confusion since right after the check, we do clipping and
scissoring, which may alter the width and height.

No functional change.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/blorp: Fixup scissoring of blits to window system buffers.

This patch modifies the order of operations in the blorp engine so
that clipping and scissoring are performed before adjusting the
coordinates to account for the difference in origin convention between
window system buffers and framebuffer objects.  Previously, we would
do clipping and scissoring after adjusting for origin conventions, so
we would get scissoring wrong in window system buffers.

Fixes Piglit test "fbo-scissor-blit window".

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/blorp: Don't fall back to swrast when miptrees absent.

Previously, the blorp engine would fall back to swrast if the source
or destination of a blit had no associated miptree.  This was
unnecessary, since _mesa_BlitFramebufferEXT() already takes care of
making the blit silently succeed if there are no buffers bound, so the
fallback paths could never actually happen in practice.

Removing these fallback paths will simplify the implementation of
correct DrawBuffers support in blorp.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/blorp: Rearrange order of blit validation and preparation steps.

This patch rearranges the order of steps performed by a blorp blit
from this:

- Sync up state of window system buffers.
- Find buffers.
- Find miptrees.
- Make sure buffer formats match.
- Handle mirroring.
- Make sure width and height match.
- Handle clipping/scissoring.
- Account for window system origin conventions.
- Do depth resolves, if applicable.
- Do the blit.
- Record the need for a future HiZ resolve, if applicable.

To this:

- Sync up state of window system buffers.
- Handle mirroring.
- Make sure width and height match.
- Handle clipping/scissoring.
- Account for window system origin conventions.
- Find buffers.
- Make sure buffer formats match.
- Find miptrees.
- Do depth resolves, if applicable.
- Do the blit.
- Record the need for a future HiZ resolve, if applicable.

The steps are the same, but they are now performed in an order that
will make it possible to implement correct DrawBuffers support.  Note
that the last four steps are now in a separate function
(do_blorp_blit), since they will need to be executed repeatedly when
DrawBuffers support is added.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/blorp: Handle DrawBuffers properly.

When the client program uses glDrawBuffer() or glDrawBuffers() to
select more than one color buffer for drawing into, and then performs
a blit, we need to blit into every single enabled draw buffer.

+2 oglconforms.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50407

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/msaa: Remove comment about falsely claiming to support MSAA.

Gen6+ hardware now supports MSAA properly.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
mesa: Make more consistent use of _mesa_is_{user,winsys}_fbo()

A lot of code was still differentiating between between winsys and
user fbos by testing the fbo's name against zero.  This converts
everything in core mesa, the state tracker, and src/mesa/program over
to use _mesa_is_user_fbo() and _mesa_is_winsys_fbo().
intel: Make more consistent use of _mesa_is_{user,winsys}_fbo()

A lot of code was still differentiating between between winsys and
user fbos by testing the fbo's name against zero.  This converts
everything in the i915 and 965 drivers over to use _mesa_is_user_fbo()
and _mesa_is_winsys_fbo().
i965/blorp: Parameterize manual_blend() by num_samples.

This patch adds a num_samples argument to the blorp function
manual_blend(), allowing it to be told how many samples need to be
blended together.  Previously it assumed 4x MSAA, since that was all
we supported.

We also bump up LOG2_MAX_BLEND_SAMPLES from 2 to 3, so that
manual_blend() will be able to handle 8x MSAA.
i965/blorp: Properly adjust primitive size for 8x MSAA.

When rendering to an IMS MSAA surface on Gen7, blorp sets up the
rendering pipeline as though it were rendering to a single-sampled
surface; accordingly it must adjust the size of the primitive it sends
down the pipeline to account for the interleaving of samples in an IMS
surface.

This patch modifies the size adjustment code to properly handle 8x
MSAA, which makes room for the extra samples by using an interleaving
pattern that is twice as wide as 4x MSAA.
i965/blorp: Compute sample number correctly for 8x MSAA.

When operating in persample dispatch mode, the blorp engine would
previously assume that subspan N always represented sample N (this is
correct assuming 4x MSAA and a 16-wide dispatch).  In order to support
8x MSAA, we must compute which sample is associated with each subspan,
using the "Starting Sample Pair Index" field in the thread payload.
i965/blorp: Encode and decode IMS format for 8x MSAA correctly.

This patch updates the blorp functions encode_msaa() and decode_msaa()
to properly handle the encoding of IMS MSAA buffers when
num_samples=8.
i965/msaa: Adjust 3DSTATE_MULTISAMPLE packet for 8x MSAA.
i965/msaa: Remove assertion in 3DSTATE_SAMPLE_MASK to allow 8x MSAA.

The code to emit 3DSTATE_SAMPLE_MASK was already correct for 8x
MSAA--this patch just removes an assertion that would have prevented
it from being used for 8x MSAA.
i965/msaa: Adjust MCS buffer allocation for 8x MSAA.

MCS buffers use 32 bits per pixel in 8x MSAA, and 8 bits per pixel in
4x MSAA.  This patch adjusts the format we use to allocate the buffer
so that enough memory is set aside for 8x MSAA.
i965/msaa: Switch on 8x MSAA for Gen7.
i965/msaa: Remove TODO comments that are no longer relevant.
i965/blorp: Ensure that blorp uses sendc instructions.

The hardware docs don't provide much guidance about when we need to
use the sendc instruction.  From the Ivy Bridge PRM, Vol4 Part3 p218
(sendc - Conditional Send Message):

    "The sendc instruction has the same behavior as the send
    instruction except the following.  sendc first checks the
    dependent threads inside the Thread Dependency Register.  There
    are up to 8 dependent threads in the TDR register. The sendc
    instruction executes only when all the dependent threads in the
    TDR register are retired."

And from p54 (TDR Registers):

    "The thread dependency registers are read only, the valids can
    only be set with a thread dispatch, and are reset by broadcasting
    end of thread messages after a thread retired."

The brw_fb_WRITE() function uses sendc in place of send when using
binding table index 0.  In practice, for normal fragment shaders, this
meeans that the first render target write uses sendc instead of send.
This has the effect of preventing a fragment shader thread from
starting to write to render targets before the threads it depends on
have finished writing to render targets.  So my speculation is that
these thread dependencies are used, in conjunction with the pixel
scoreboard, to ensure that render target writes are correctly ordered.

Assuming that speculation is correct, we need to use the sendc
instruction in blorp fragment shader threads too.  This patch
accomplishes that by using binding table entry 0 for blorp's render
target.