i965: Don't try to use the hardware blitter for multisampled miptrees.

The blitter is completely ignorant of MSAA buffer layouts, so any
attempt to use BLT paths with MSAA buffers is likely to break
spectacularly.

In most cases, BLORP handles MSAA blits, so we never hit this bug.
Until recently, it also wasn't worth fixing, since Meta couldn't handle
MSAA either, so there was nothing to fall back to.  But now there is.

+143 piglit tests on Broadwell (which doesn't have BLORP support).
Surprisingly, three also start failing.  Since non-IMS MSAA buffers
store samples in successive array slices, using the blitter ought to
access sample 0 and ignore the rest, which is apparently good enough for
a few not-very-picky Piglit tests.  Presumably the meta replacement code
is still broken.

No Piglit changes on Ivybridge.

v2: Move the early return to the top of the function (suggested by
    Paul).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

diff --git a/src/mesa/drivers/dri/i965/intel_blit.c b/src/mesa/drivers/dri/i965/intel_blit.c
index df85dc9759e8586a80552610533a98458e062d29..d1c16d5aa6afe571233f7b52d7e0d11ce3bdc7a7 100644 (file)
--- a/src/mesa/drivers/dri/i965/intel_blit.c
+++ b/src/mesa/drivers/dri/i965/intel_blit.c
@@ -158,6 +158,10 @@ intel_miptree_blit(struct brw_context *brw,
                    uint32_t width, uint32_t height,
                    GLenum logicop)
 {
+   /* The blitter doesn't understand multisampling at all. */
+   if (src_mt->num_samples > 0 || dst_mt->num_samples > 0)
+      return false;
+
    /* No sRGB decode or encode is done by the hardware blitter, which is
     * consistent with what we want in the callers (glCopyTexSubImage(),
     * glBlitFramebuffer(), texture validation, etc.).