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 <[email protected]>
Reviewed-by: Paul Berry <[email protected]>

1 files changed, 4 insertions, 0 deletions

diff --git a/src/mesa/drivers/dri/i965/intel_blit.c b/src/mesa/drivers/dri/i965/intel_blit.c
index df85dc9759e..d1c16d5aa6a 100644
--- 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.).