From: Rob Clark Date: Sun, 12 Jan 2020 01:30:24 +0000 (-0800) Subject: freedreno/a6xx: fix lrz overflow X-Git-Tag: upstream/20.1.8~3760 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=2f4f46b7080a1087420939b2f4bf0bea414cd3ce;p=platform%2Fupstream%2Fmesa.git freedreno/a6xx: fix lrz overflow Running the complete deqp_gles2 seems to trigger an overflow in lrz cmdstream. We skip the blit clear fast-path if there have been any draws (so mid-batch clears of any attached buffer hit the 3d pipe). Which means it is safe to simply discard any lrz clear rendering. Signed-off-by: Rob Clark Part-of: --- diff --git a/src/gallium/drivers/freedreno/a6xx/fd6_draw.c b/src/gallium/drivers/freedreno/a6xx/fd6_draw.c index 013efb3..18f741f 100644 --- a/src/gallium/drivers/freedreno/a6xx/fd6_draw.c +++ b/src/gallium/drivers/freedreno/a6xx/fd6_draw.c @@ -350,16 +350,11 @@ fd6_clear_lrz(struct fd_batch *batch, struct fd_resource *zsbuf, double depth) struct fd_ringbuffer *ring; struct fd6_context *fd6_ctx = fd6_context(batch->ctx); - // TODO mid-frame clears (ie. app doing crazy stuff)?? Maybe worth - // splitting both clear and lrz clear out into their own rb's. And - // just throw away any draws prior to clear. (Anything not fullscreen - // clear, just fallback to generic path that treats it as a normal - // draw - - if (!batch->lrz_clear) { - batch->lrz_clear = fd_submit_new_ringbuffer(batch->submit, 0x1000, 0); + if (batch->lrz_clear) { + fd_ringbuffer_del(batch->lrz_clear); } + batch->lrz_clear = fd_submit_new_ringbuffer(batch->submit, 0x1000, 0); ring = batch->lrz_clear; emit_marker6(ring, 7);