Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Date:   Thu, 16 Nov 2023 12:14:51 +0000
To:     Thomas Zimmermann <tzimmermann@suse.de>
From:   Simon Ser <contact@emersion.fr>
Cc:     Javier Martinez Canillas <javierm@redhat.com>,
        linux-kernel@vger.kernel.org,
        Pekka Paalanen <pekka.paalanen@collabora.com>,
        Sima Vetter <daniel.vetter@ffwll.ch>,
        Bilal Elmoussaoui <belmouss@redhat.com>,
        dri-devel@lists.freedesktop.org,
        Maxime Ripard <mripard@kernel.org>,
        Erico Nunes <nunes.erico@gmail.com>
Subject: Re: [PATCH v2 4/5] drm/plane: Extend damage tracking kernel-doc
Message-ID: <vhshocGSkXgVLycHIcJIVPsN9OQokPA2NCgIBqOvIzpKRZXQjN1uEiFKVudwa-S4hpBnFPaxxYh8hCFxd-u_ahYKBamQxFzIhBkYGkND9Kc=@emersion.fr>
In-Reply-To: <abfd41c7-dc9f-4cd3-be83-97b2c2c96b62@suse.de>
References: <20231115131549.2191589-1-javierm@redhat.com> <20231115131549.2191589-5-javierm@redhat.com> <abfd41c7-dc9f-4cd3-be83-97b2c2c96b62@suse.de>
Feedback-ID: 1358184:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thursday, November 16th, 2023 at 13:06, Thomas Zimmermann <tzimmermann@s=
use.de> wrote:

> > + * Note that there are two types of damage handling: frame damage and =
buffer
> > + * damage. The type of damage handling implemented depends on a driver=
's upload
> > + * target. Drivers implementing a per-plane or per-CRTC upload target =
need to
> > + * handle frame damage while drivers implementing a per-buffer upload =
target
> > + * need to handle buffer damage.
> > + *
> > + * The existing damage helpers only support the frame damage type, the=
re is no
> > + * buffer age support or similar damage accumulation algorithm impleme=
nted yet.
> > + *
> > + * Only drivers handling frame damage can use the mentiored damage hel=
pers to

Typo: mentioned

> > + * iterate over the damaged regions. Drivers that handle buffer damage=
, need to
> > + * set &struct drm_plane_state.ignore_damage_clips as an indication to
> > + * drm_atomic_helper_damage_iter_init() that the damage clips should b=
e ignored.
> > + * In that case, the returned damage rectangle is the &drm_plane_state=
.src since
> > + * a full plane update should happen.
> > + *
> > + * For more information about the two type of damage, see:
> > + * https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_swap_buffer=
s_with_damage.txt
> > + * https://emersion.fr/blog/2019/intro-to-damage-tracking/
>=20
> One thought you might want to consider.
>=20
> These URLs are helpful. The only issue I have is that frame damage and
> buffer damage are user-space concepts. The kernel bug is that damage
> handling expects the backing storage/upload buffer not to change for a
> given plane. If the upload buffer changes between page flips, the new
> upload buffer has to be updated as a whole. Hence no damage handling then=
.

Why would these concepts be specific to user-space? The kernel could
better handle buffer damage instead of forcing full damage, by doing
something similar to what user-space does.

Anyways:

Reviewed-by: Simon Ser <contact@emersion.fr>