Hi Am 16.11.23 um 13:14 schrieb Simon Ser:
On Thursday, November 16th, 2023 at 13:06, Thomas Zimmermann <tzimmermann@xxxxxxx> 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 toTypo: 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.
Best regards Thomas
Anyways: Reviewed-by: Simon Ser <contact@xxxxxxxxxxx>
-- 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)
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
