linux-kernel - Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane check for async

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 16 Jan 2024 10:35:16 -0300
From: André Almeida <andrealmeid@...lia.com>
To: Pekka Paalanen <ppaalanen@...il.com>
Cc: dri-devel@...ts.freedesktop.org, amd-gfx@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, kernel-dev@...lia.com,
 alexander.deucher@....com, christian.koenig@....com,
 Simon Ser <contact@...rsion.fr>, daniel@...ll.ch,
 Daniel Stone <daniel@...ishbar.org>, 'Marek Olšák'
 <maraeo@...il.com>, Dave Airlie <airlied@...il.com>,
 ville.syrjala@...ux.intel.com, Xaver Hugl <xaver.hugl@...il.com>,
 Joshua Ashton <joshua@...ggi.es>
Subject: Re: [PATCH 0/2] drm/atomic: Allow drivers to write their own plane
 check for async

+ Joshua

Em 16/01/2024 10:14, Pekka Paalanen escreveu:
> On Tue, 16 Jan 2024 08:50:59 -0300
> André Almeida <andrealmeid@...lia.com> wrote:
> 
>> Hi Pekka,
>>
>> Em 16/01/2024 06:45, Pekka Paalanen escreveu:
>>> On Tue, 16 Jan 2024 01:51:57 -0300
>>> André Almeida <andrealmeid@...lia.com> wrote:
>>>    
>>>> Hi,
>>>>
>>>> AMD hardware can do more on the async flip path than just the primary plane, so
>>>> to lift up the current restrictions, this patchset allows drivers to write their
>>>> own check for planes for async flips.
>>>
>>> Hi,
>>>
>>> what's the userspace story for this, how could userspace know it could do more?
>>> What kind of userspace would take advantage of this and in what situations?
>>>
>>> Or is this not meant for generic userspace?
>>
>> Sorry, I forgot to document this. So the idea is that userspace will
>> query what they can do here with DRM_MODE_ATOMIC_TEST_ONLY calls,
>> instead of having capabilities for each prop.
> 
> That's the theory, but do you have a practical example?
> 
> What other planes and props would one want change in some specific use
> case?
> 
> Is it just "all or nothing", or would there be room to choose and pick
> which props you change and which you don't based on what the driver
> supports? If the latter, then relying on TEST_ONLY might be yet another
> combinatorial explosion to iterate through.
> 

That's a good question, maybe Simon, Xaver or Joshua can share how they 
were planning to use this on Gamescope or Kwin.

> 
> Thanks,
> pq
> 
>>>> I'm not sure if adding something new to drm_plane_funcs is the right way to do,
>>>> because if we want to expand the other object types (crtc, connector) we would
>>>> need to add their own drm_XXX_funcs, so feedbacks are welcome!
>>>>
>>>> 	André
>>>>
>>>> André Almeida (2):
>>>>     drm/atomic: Allow drivers to write their own plane check for async
>>>>       flips
>>>>     drm/amdgpu: Implement check_async_props for planes
>>>>
>>>>    .../amd/display/amdgpu_dm/amdgpu_dm_plane.c   | 30 +++++++++
>>>>    drivers/gpu/drm/drm_atomic_uapi.c             | 62 ++++++++++++++-----
>>>>    include/drm/drm_atomic_uapi.h                 | 12 ++++
>>>>    include/drm/drm_plane.h                       |  5 ++
>>>>    4 files changed, 92 insertions(+), 17 deletions(-)
>>>>   
>>>    
>