Mesa (master): panfrost: Make sure we reset the damage region of RTs at flush time

GitLab Mirror gitlab-mirror at kemper.freedesktop.org
Fri Nov 29 10:20:51 UTC 2019


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

Author: Boris Brezillon <boris.brezillon at collabora.com>
Date:   Thu Nov 14 09:35:27 2019 +0100

panfrost: Make sure we reset the damage region of RTs at flush time

We must reset the damage info of our render targets here even though a
damage reset normally happens when the DRI layer swaps buffers. That's
because there can be implicit flushes the GL app is not aware of, and
those might impact the damage region: if part of the damaged portion
is drawn during those implicit flushes, you have to reload those areas
before next draws are pushed, and since the driver can't easily know
what's been modified by the draws it flushed, the easiest solution is
to reload everything.

Reported-by: Carsten Haitzler <raster at rasterman.com>
Fixes: 65ae86b85422 ("panfrost: Add support for KHR_partial_update()")
Cc: <mesa-stable at lists.freedesktop.org>
Signed-off-by: Boris Brezillon <boris.brezillon at collabora.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig at collabora.com>

---

 src/gallium/drivers/panfrost/pan_job.c      | 19 +++++++++++++++++++
 src/gallium/drivers/panfrost/pan_resource.c |  2 +-
 src/gallium/drivers/panfrost/pan_resource.h |  3 +++
 3 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/src/gallium/drivers/panfrost/pan_job.c b/src/gallium/drivers/panfrost/pan_job.c
index 3df1cc226ee..ea6bd022511 100644
--- a/src/gallium/drivers/panfrost/pan_job.c
+++ b/src/gallium/drivers/panfrost/pan_job.c
@@ -940,6 +940,25 @@ panfrost_batch_submit(struct panfrost_batch *batch)
         if (ret)
                 fprintf(stderr, "panfrost_batch_submit failed: %d\n", ret);
 
+        /* We must reset the damage info of our render targets here even
+         * though a damage reset normally happens when the DRI layer swaps
+         * buffers. That's because there can be implicit flushes the GL
+         * app is not aware of, and those might impact the damage region: if
+         * part of the damaged portion is drawn during those implicit flushes,
+         * you have to reload those areas before next draws are pushed, and
+         * since the driver can't easily know what's been modified by the draws
+         * it flushed, the easiest solution is to reload everything.
+         */
+        for (unsigned i = 0; i < batch->key.nr_cbufs; i++) {
+                struct panfrost_resource *res;
+
+                if (!batch->key.cbufs[i])
+                        continue;
+
+                res = pan_resource(batch->key.cbufs[i]->texture);
+                panfrost_resource_reset_damage(res);
+        }
+
 out:
         panfrost_freeze_batch(batch);
         panfrost_free_batch(batch);
diff --git a/src/gallium/drivers/panfrost/pan_resource.c b/src/gallium/drivers/panfrost/pan_resource.c
index c3fb12777b7..df0fc9e5cac 100644
--- a/src/gallium/drivers/panfrost/pan_resource.c
+++ b/src/gallium/drivers/panfrost/pan_resource.c
@@ -48,7 +48,7 @@
 #include "pan_util.h"
 #include "pan_tiling.h"
 
-static void
+void
 panfrost_resource_reset_damage(struct panfrost_resource *pres)
 {
         /* We set the damage extent to the full resource size but keep the
diff --git a/src/gallium/drivers/panfrost/pan_resource.h b/src/gallium/drivers/panfrost/pan_resource.h
index 22404a609e1..a9c4d7cc539 100644
--- a/src/gallium/drivers/panfrost/pan_resource.h
+++ b/src/gallium/drivers/panfrost/pan_resource.h
@@ -136,6 +136,9 @@ panfrost_blit_wallpaper(struct panfrost_context *ctx,
                         struct pipe_box *box);
 
 void
+panfrost_resource_reset_damage(struct panfrost_resource *pres);
+
+void
 panfrost_resource_set_damage_region(struct pipe_screen *screen,
                                     struct pipe_resource *res,
                                     unsigned int nrects,




More information about the mesa-commit mailing list