[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47c6866a-34d6-48b1-a977-d21c48d991dc@igalia.com>
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(-)
>>>>
>>>
>
Powered by blists - more mailing lists