<div dir="ltr"><div dir="ltr"><div>My plan is to require support for IN_FENCE_FD at least. If the driver doesn't</div><div>allow tearing with that, then tearing just doesn't happen.</div><div><br></div>For overlay planes though, it depends on how the compositor prioritizes things.</div><div>If the compositor prioritizes overlay planes and would like to do tearing if possible,</div><div>then this patch works.</div><div>If the compositor prioritizes tearing and would like to do overlay planes if possible,</div><div>it would have to know that switching to synchronous commits for a single frame,</div><div>setting up the overlay planes and then switching back to async commits works, and</div><div>that can't be figured out with TEST_ONLY commits.</div><div>So I think having a CAP or immutable plane property to signal that async commits</div><div>with overlay and/or cursor planes is supported would be useful.<br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Di., 16. Jan. 2024 um 14:35 Uhr schrieb André Almeida <<a href="mailto:andrealmeid@igalia.com">andrealmeid@igalia.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">+ Joshua<br>
<br>
Em 16/01/2024 10:14, Pekka Paalanen escreveu:<br>
> On Tue, 16 Jan 2024 08:50:59 -0300<br>
> André Almeida <<a href="mailto:andrealmeid@igalia.com" target="_blank">andrealmeid@igalia.com</a>> wrote:<br>
> <br>
>> Hi Pekka,<br>
>><br>
>> Em 16/01/2024 06:45, Pekka Paalanen escreveu:<br>
>>> On Tue, 16 Jan 2024 01:51:57 -0300<br>
>>> André Almeida <<a href="mailto:andrealmeid@igalia.com" target="_blank">andrealmeid@igalia.com</a>> wrote:<br>
>>>    <br>
>>>> Hi,<br>
>>>><br>
>>>> AMD hardware can do more on the async flip path than just the primary plane, so<br>
>>>> to lift up the current restrictions, this patchset allows drivers to write their<br>
>>>> own check for planes for async flips.<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> what's the userspace story for this, how could userspace know it could do more?<br>
>>> What kind of userspace would take advantage of this and in what situations?<br>
>>><br>
>>> Or is this not meant for generic userspace?<br>
>><br>
>> Sorry, I forgot to document this. So the idea is that userspace will<br>
>> query what they can do here with DRM_MODE_ATOMIC_TEST_ONLY calls,<br>
>> instead of having capabilities for each prop.<br>
> <br>
> That's the theory, but do you have a practical example?<br>
> <br>
> What other planes and props would one want change in some specific use<br>
> case?<br>
> <br>
> Is it just "all or nothing", or would there be room to choose and pick<br>
> which props you change and which you don't based on what the driver<br>
> supports? If the latter, then relying on TEST_ONLY might be yet another<br>
> combinatorial explosion to iterate through.<br>
> <br>
<br>
That's a good question, maybe Simon, Xaver or Joshua can share how they <br>
were planning to use this on Gamescope or Kwin.<br>
<br>
> <br>
> Thanks,<br>
> pq<br>
> <br>
>>>> I'm not sure if adding something new to drm_plane_funcs is the right way to do,<br>
>>>> because if we want to expand the other object types (crtc, connector) we would<br>
>>>> need to add their own drm_XXX_funcs, so feedbacks are welcome!<br>
>>>><br>
>>>>    André<br>
>>>><br>
>>>> André Almeida (2):<br>
>>>>     drm/atomic: Allow drivers to write their own plane check for async<br>
>>>>       flips<br>
>>>>     drm/amdgpu: Implement check_async_props for planes<br>
>>>><br>
>>>>    .../amd/display/amdgpu_dm/amdgpu_dm_plane.c   | 30 +++++++++<br>
>>>>    drivers/gpu/drm/drm_atomic_uapi.c             | 62 ++++++++++++++-----<br>
>>>>    include/drm/drm_atomic_uapi.h                 | 12 ++++<br>
>>>>    include/drm/drm_plane.h                       |  5 ++<br>
>>>>    4 files changed, 92 insertions(+), 17 deletions(-)<br>
>>>>   <br>
>>>    <br>
> <br>
</blockquote></div></div>