Mesa (master): i965: Don' t try to use the hardware blitter for multisampled miptrees.

Kenneth Graunke kwg at kemper.freedesktop.org
Mon Feb 24 04:16:08 UTC 2014


Module: Mesa
Branch: master
Commit: 73c78c514f8db0605c0deb85382003d0f66b5525
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=73c78c514f8db0605c0deb85382003d0f66b5525

Author: Kenneth Graunke <kenneth at whitecape.org>
Date:   Fri Feb 21 19:15:51 2014 -0800

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 at whitecape.org>
Reviewed-by: Paul Berry <stereotype441 at gmail.com>

---

 src/mesa/drivers/dri/i965/intel_blit.c |    4 ++++
 1 file changed, 4 insertions(+)

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




More information about the mesa-commit mailing list