lkml.org 
[lkml]   [2023]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2 4/5] drm/plane: Extend damage tracking kernel-doc
From
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]
\
 
 \ /
  Last update: 2023-11-20 14:02    [W:0.044 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site