[PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible

[Pekka Paalanen]

On Fri, 15 Mar 2024 13:09:56 -0400
<sunpeng.li at amd.com> wrote:

> From: Leo Li <sunpeng.li at amd.com>
> 
> These patches aim to make the amdgpgu KMS driver play nicer with compositors
> when building multi-plane scanout configurations. They do so by:
> 
> 1. Making cursor behavior more sensible.
> 2. Allowing placement of DRM OVERLAY planes underneath the PRIMARY plane for
>    'underlay' configurations (perhaps more of a RFC, see below).
> 
> Please see the commit messages for details.
> 
> 
> For #2, the simplest way to accomplish this was to increase the value of the
> immutable zpos property for the PRIMARY plane. This allowed OVERLAY planes with
> a mutable zpos range of (0-254) to be positioned underneath the PRIMARY for an
> underlay scanout configuration.
> 
> Technically speaking, DCN hardware does not have a concept of primary or overlay
> planes - there are simply 4 general purpose hardware pipes that can be maped in
> any configuration. So the immutable zpos restriction on the PRIMARY plane is
> kind of arbitrary; it can have a mutable range of (0-254) just like the
> OVERLAYs. The distinction between PRIMARY and OVERLAY planes is also somewhat
> arbitrary. We can interpret PRIMARY as the first plane that should be enabled on
> a CRTC, but beyond that, it doesn't mean much for amdgpu.
> 
> Therefore, I'm curious about how compositors devs understand KMS planes and
> their zpos properties, and how we would like to use them. It isn't clear to me
> how compositors wish to interpret and use the DRM zpos property, or
> differentiate between OVERLAY and PRIMARY planes, when it comes to setting up
> multi-plane scanout.

You already quoted me on the Weston link, so I don't think I have
anything to add. Sounds fine to me, and we don't have a standard plane
arrangement algorithm that the kernel could optimize zpos ranges
against, yet.

> Ultimately, what I'd like to answer is "What can we do on the KMS driver and DRM
> plane API side, that can make building multi-plane scanout configurations easier
> for compositors?" I'm hoping we can converge on something, whether that be
> updating the existing documentation to better define the usage, or update the
> API to provide support for something that is lacking.

I think there probably should be a standardised plane arrangement
algorithm in userspace, because the search space suffers from
permutational explosion. Either there needs to be very few planes (max
4 or 5 at-all-possible per CRTC, including shareable ones) for an
exhaustive search to be feasible, or all planes should be more or less
equal in capabilities and userspace employs some simplified or
heuristic search.

If the search algorithm is fixed, then drivers could optimize zpos
ranges to have the algorithm find a solution faster.

My worry is that userspace already has heuristic search algorithms that
may start failing if drivers later change their zpos ranges to be more
optimal for another algorithm.

OTOH, as long as exhaustive search is feasible, then it does not matter
how DRM drivers set up the zpos ranges.

In any case, the zpos ranges should try to allow all possible plane
arrangements while minimizing the number of arrangements that won't
work. The absolute values of zpos are pretty much irrelevant, so I
think setting one plane to have an immutable zpos is a good idea, even
if it's not necessary by the driver. That is one less moving part, and
only the relative ordering between the planes matters.


Thanks,
pq

> Some links to provide context and details:
> * What is underlay?: https://gitlab.freedesktop.org/emersion/libliftoff/-/issues/76
> * Discussion on how to implement underlay on Weston: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1258#note_2325164
> 
> Cc: Joshua Ashton <joshua at froggi.es>
> Cc: Michel Dänzer <mdaenzer at redhat.com>
> Cc: Chao Guo <chao.guo at nxp.com>
> Cc: Xaver Hugl <xaver.hugl at gmail.com>
> Cc: Vikas Korjani <Vikas.Korjani at amd.com>
> Cc: Robert Mader <robert.mader at posteo.de>
> Cc: Pekka Paalanen <pekka.paalanen at collabora.com>
> Cc: Sean Paul <sean at poorly.run>
> Cc: Simon Ser <contact at emersion.fr>
> Cc: Shashank Sharma <shashank.sharma at amd.com>
> Cc: Harry Wentland <harry.wentland at amd.com>
> Cc: Sebastian Wick <sebastian.wick at redhat.com>
> 
> Leo Li (2):
>   drm/amd/display: Introduce overlay cursor mode
>   drm/amd/display: Move PRIMARY plane zpos higher
> 
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 405 ++++++++++++++++--
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   7 +
>  .../amd/display/amdgpu_dm/amdgpu_dm_crtc.c    |   1 +
>  .../amd/display/amdgpu_dm/amdgpu_dm_plane.c   |  28 +-
>  4 files changed, 391 insertions(+), 50 deletions(-)
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20240328/6f62c69b/attachment-0001.sig>