Linux virtualization list
 help / color / mirror / Atom feed
From: Zack Rusin <zackr@vmware.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"javierm@redhat.com" <javierm@redhat.com>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
	"olvaffe@gmail.com" <olvaffe@gmail.com>,
	"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"nunes.erico@gmail.com" <nunes.erico@gmail.com>,
	"airlied@redhat.com" <airlied@redhat.com>,
	"pekka.paalanen@collabora.com" <pekka.paalanen@collabora.com>,
	"tzimmermann@suse.de" <tzimmermann@suse.de>,
	"belmouss@redhat.com" <belmouss@redhat.com>,
	"mripard@kernel.org" <mripard@kernel.org>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	"gurchetansingh@chromium.org" <gurchetansingh@chromium.org>,
	"maarten.lankhorst@linux.intel.com"
	<maarten.lankhorst@linux.intel.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"kraxel@redhat.com" <kraxel@redhat.com>,
	"virtualization@lists.linux.dev" <virtualization@lists.linux.dev>,
	"airlied@gmail.com" <airlied@gmail.com>,
	Linux-graphics-maintainer <Linux-graphics-maintainer@vmware.com>,
	"contact@emersion.fr" <contact@emersion.fr>
Subject: Re: [PATCH v2 0/5] drm: Allow the damage helpers to handle buffer damage
Date: Thu, 16 Nov 2023 04:04:09 +0000	[thread overview]
Message-ID: <a16a61582f90a5b490fb7681b44864a4801c830a.camel@vmware.com> (raw)
In-Reply-To: <20231115131549.2191589-1-javierm@redhat.com>

On Wed, 2023-11-15 at 14:15 +0100, Javier Martinez Canillas wrote:
> Hello,
>
> This series is to fix an issue that surfaced after damage clipping was
> enabled for the virtio-gpu by commit 01f05940a9a7 ("drm/virtio: Enable
> fb damage clips property for the primary plane").
>
> After that change, flickering artifacts was reported to be present with
> both weston and wlroots wayland compositors when running in a virtual
> machine. The cause was identified by Sima Vetter, who pointed out that
> virtio-gpu does per-buffer uploads and for this reason it needs to do
> a buffer damage handling, instead of frame damage handling.
>
> Their suggestion was to extend the damage helpers to cover that case
> and given that there's isn't a buffer damage accumulation algorithm
> (e.g: buffer age), just do a full plane update if the framebuffer that
> is attached to a plane changed since the last plane update (page-flip).
>
> It is a v2 that addresses issues pointed out by Thomas Zimmermann in v1:
> https://lists.freedesktop.org/archives/dri-devel/2023-November/430138.html
>
> Patch #1 adds a ignore_damage_clips field to struct drm_plane_state to be
> set by drivers that want the damage helpers to ignore the damage clips.
>
> Patch #2 fixes the virtio-gpu damage handling logic by asking the damage
> helper to ignore the damage clips if the framebuffer attached to a plane
> has changed since the last page-flip.
>
> Patch #3 does the same but for the vmwgfx driver that also needs to handle
> buffer damage and should have the same issue (although I haven't tested it
> due not having a VMWare setup).
>
> Patch #4 adds to the KMS damage tracking kernel-doc some paragraphs about
> damage tracking types and references to links that explain frame damage vs
> buffer damage.
>
> Finally patch #5 adds an item to the DRM todo, about the need to implement
> some buffer damage accumulation algorithm instead of just doing full plane
> updates in this case.
>
> Because commit 01f05940a9a7 landed in v6.4, the first 2 patches are marked
> as Fixes and Cc stable.
>
> I've tested this on a VM with weston, was able to reproduce the issue
> reported and the patches did fix the problem.
>
> Best regards,
> Javier
>
> Changes in v2:
> - Add a struct drm_plane_state .ignore_damage_clips to set in the plane's
>   .atomic_check, instead of having different helpers (Thomas Zimmermann).
> - Set struct drm_plane_state .ignore_damage_clips in virtio-gpu plane's
>   .atomic_check instead of using a different helpers (Thomas Zimmermann).
> - Set struct drm_plane_state .ignore_damage_clips in vmwgfx plane's
>   .atomic_check instead of using a different helpers (Thomas Zimmermann).

The series looks good to me, thanks for tackling this. I'm surprised that we don't
have any IGT tests for this. Seems like it shouldn't be too hard to test it in a
generic way with just a couple of dumb buffers.

z

  parent reply	other threads:[~2023-11-16  4:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-15 13:15 [PATCH v2 0/5] drm: Allow the damage helpers to handle buffer damage Javier Martinez Canillas
2023-11-15 13:15 ` [PATCH v2 2/5] drm/virtio: Disable damage clipping if FB changed since last page-flip Javier Martinez Canillas
2023-11-16  4:04 ` Zack Rusin [this message]
2023-11-16  7:46   ` [PATCH v2 0/5] drm: Allow the damage helpers to handle buffer damage Javier Martinez Canillas
2023-11-16 12:07 ` Thomas Zimmermann

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=a16a61582f90a5b490fb7681b44864a4801c830a.camel@vmware.com \
    --to=zackr@vmware.com \
    --cc=Linux-graphics-maintainer@vmware.com \
    --cc=airlied@gmail.com \
    --cc=airlied@redhat.com \
    --cc=belmouss@redhat.com \
    --cc=contact@emersion.fr \
    --cc=corbet@lwn.net \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gurchetansingh@chromium.org \
    --cc=javierm@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=nunes.erico@gmail.com \
    --cc=olvaffe@gmail.com \
    --cc=pekka.paalanen@collabora.com \
    --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