dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lyude Paul <lyude@redhat.com>
To: dri-devel@lists.freedesktop.org, virtualization@lists.linux.dev,
	linux-kernel@lists.freedesktop.org
Cc: Christian Hergert <christian@sourceandstack.com>,
	"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
	"David Airlie" <airlied@redhat.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	linux-kernel@vger.kernel.org, "Simona Vetter" <simona@ffwll.ch>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Lyude Paul" <lyude@redhat.com>
Subject: [PATCH 1/2] drm/virtio: preserve damage clips for rendered resources
Date: Thu,  3 Sep 2026 17:15:51 -0400	[thread overview]
Message-ID: <20260903211914.1109100-2-lyude@redhat.com> (raw)
In-Reply-To: <20260903211914.1109100-1-lyude@redhat.com>

From: Christian Hergert <christian@sourceandstack.com>

virtio_gpu_plane_atomic_check() unconditionally ignores FB_DAMAGE_CLIPS
when the framebuffer changes. This forces a full resource flush on every
page flip when a compositor rotates through multiple framebuffers, even
when userspace supplies accumulated per-buffer damage.

The full update is required for dumb buffers because their contents are
uploaded per buffer. Rendered resources are already coherent on the host,
so replacing their damage with the full plane only discards useful
information.

Restrict ignore_damage_clips to dumb buffers. This allows damage-aware
compositors to propagate partial updates through RESOURCE_FLUSH while
preserving the existing full-upload behavior for dumb buffers.

Signed-off-by: Christian Hergert <christian@sourceandstack.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
---
 drivers/gpu/drm/virtio/virtgpu_plane.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c
index 1d1b27ece62a7..d9579a4b4714c 100644
--- a/drivers/gpu/drm/virtio/virtgpu_plane.c
+++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
@@ -103,6 +103,7 @@ static int virtio_gpu_plane_atomic_check(struct drm_plane *plane,
 										 plane);
 	struct drm_plane_state *old_plane_state = drm_atomic_get_old_plane_state(state,
 										 plane);
+	struct virtio_gpu_object *bo;
 	bool is_cursor = plane->type == DRM_PLANE_TYPE_CURSOR;
 	struct drm_crtc_state *crtc_state;
 	int ret;
@@ -113,9 +114,12 @@ static int virtio_gpu_plane_atomic_check(struct drm_plane *plane,
 	/*
 	 * Ignore damage clips if the framebuffer attached to the plane's state
 	 * has changed since the last plane update (page-flip). In this case, a
-	 * full plane update should happen because uploads are done per-buffer.
+	 * full plane update should happen for dumb buffers because uploads are
+	 * done per-buffer. Rendered resources are already coherent on the host,
+	 * so preserve userspace's accumulated per-buffer damage for those.
 	 */
-	if (old_plane_state->fb != new_plane_state->fb)
+	bo = gem_to_virtio_gpu_obj(new_plane_state->fb->obj[0]);
+	if (old_plane_state->fb != new_plane_state->fb && bo->dumb)
 		new_plane_state->ignore_damage_clips = true;
 
 	crtc_state = drm_atomic_get_crtc_state(state,
-- 
2.55.0


  reply	other threads:[~2026-09-03 21:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-03 21:15 [PATCH 0/2] drm/virtio: Damage clip fixes Lyude Paul
2026-09-03 21:15 ` Lyude Paul [this message]
2026-09-03 21:15 ` [PATCH 2/2] drm/virtio: Recalculate ignore_damage_clips on every update Lyude Paul
2026-09-03 21:27   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260903211914.1109100-2-lyude@redhat.com \
    --to=lyude@redhat.com \
    --cc=airlied@redhat.com \
    --cc=christian@sourceandstack.com \
    --cc=dmitry.osipenko@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kraxel@redhat.com \
    --cc=linux-kernel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    --cc=virtualization@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox