Messages in this thread | | | Date | Fri, 17 Nov 2023 12:47:58 +0100 | Subject | Re: [PATCH v2 4/5] drm/plane: Extend damage tracking kernel-doc | From | Thomas Zimmermann <> |
| |
Hi
Am 16.11.23 um 16:24 schrieb Pekka Paalanen: > On Thu, 16 Nov 2023 13:34:07 +0100 > Thomas Zimmermann <tzimmermann@suse.de> wrote: > >> Hi >> >> Am 16.11.23 um 13:14 schrieb Simon Ser: >>> On Thursday, November 16th, 2023 at 13:06, Thomas Zimmermann <tzimmermann@suse.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, there is no >>>>> + * buffer age support or similar damage accumulation algorithm implemented yet. >>>>> + * >>>>> + * Only drivers handling frame damage can use the mentiored damage helpers 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 be 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_buffers_with_damage.txt >>>>> + * https://emersion.fr/blog/2019/intro-to-damage-tracking/ >>>> >>>> One thought you might want to consider. >>>> >>>> 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. >> >> The terms 'frame damage' and 'buffer damage' do not exist in the kernel. >> The problem can be better described in wording that is common within the >> context of the kernel drivers. > > What terms does the kernel use for these two different concepts of > damage?
None AFAIK. Damage is relative to the plane's backing storage/upload buffer. That's frame damage. We never needed a name for buffer damage as we don't support it.
Best regards Thomas
> > > Thanks, > pq
-- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) [unhandled content-type:application/pgp-signature] | |