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

From: Alex Deucher <alexdeucher@gmail.com>
To: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: "Leo Li" <sunpeng.li@amd.com>,
	"Marius Vlad" <marius.vlad@collabora.com>,
	"Harry Wentland" <harry.wentland@amd.com>,
	dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
	"Joshua Ashton" <joshua@froggi.es>,
	"Michel Dänzer" <mdaenzer@redhat.com>,
	"Chao Guo" <chao.guo@nxp.com>,
	"Xaver Hugl" <xaver.hugl@gmail.com>,
	"Vikas Korjani" <Vikas.Korjani@amd.com>,
	"Robert Mader" <robert.mader@posteo.de>,
	"Sean Paul" <sean@poorly.run>, "Simon Ser" <contact@emersion.fr>,
	"Shashank Sharma" <shashank.sharma@amd.com>,
	"Sebastian Wick" <sebastian.wick@redhat.com>
Subject: Re: [PATCH 0/2] drm/amdgpu/display: Make multi-plane configurations more flexible
Date: Fri, 12 Apr 2024 11:31:22 -0400	[thread overview]
Message-ID: <CADnq5_MD4EBm4kGuK3fa0azKsMimEnTM3tm-Hy8CN-NNtom3Kw@mail.gmail.com> (raw)
In-Reply-To: <20240412180741.360d8c2b.pekka.paalanen@collabora.com>

On Fri, Apr 12, 2024 at 11:08 AM Pekka Paalanen
<pekka.paalanen@collabora.com> wrote:
>
> On Fri, 12 Apr 2024 10:28:52 -0400
> Leo Li <sunpeng.li@amd.com> wrote:
>
> > On 2024-04-12 04:03, Pekka Paalanen wrote:
> > > On Thu, 11 Apr 2024 16:33:57 -0400
> > > Leo Li <sunpeng.li@amd.com> wrote:
> > >
>
> ...
>
> > >> That begs the question of what can be nailed down and what can left to
> > >> independent implementation. I guess things like which plane should be enabled
> > >> first (PRIMARY), and how zpos should be interpreted (overlay, underlay, mixed)
> > >> can be defined. How to handle atomic test failures could be as well.
> > >
> > > What room is there for the interpretation of zpos values?
> > >
> > > I thought they are unambiguous already: only the relative numerical
> > > order matters, and that uniquely defines the KMS plane ordering.
> >
> > The zpos value of the PRIMARY plane relative to OVERLAYS, for example, as a way
> > for vendors to communicate overlay, underlay, or mixed-arrangement support. I
> > don't think allowing OVERLAYs to be placed under the PRIMARY is currently
> > documented as a way to support underlay.
>
> I always thought it's obvious that the zpos numbers dictate the plane
> order without any other rules. After all, we have the universal planes
> concept, where the plane type is only informational to aid heuristics
> rather than defining anything.
>
> Only if the zpos property does not exist, the plane types would come
> into play.
>
> Of course, if there actually exists userspace that fails if zpos allows
> an overlay type plane to be placed below primary, or fails if primary
> zpos is not zero, then DRM needs a new client cap.
>
> > libliftoff for example, assumes that the PRIMARY has the lowest zpos. So
> > underlay arrangements will use an OVERLAY for the scanout plane, and the PRIMARY
> > for the underlay view.
>
> That's totally ok. It works, right? Plane type does not matter if the
> KMS driver accepts the configuration.
>
> What is a "scanout plane"? Aren't all KMS planes by definition scanout
> planes?
>
> IOW, if the KMS client understands zpos and can do a proper KMS
> configuration search, and all planes have zpos property, then there is
> no need to look at the plane type at all. That is the goal of the
> universal planes feature.

The optimal configuration with DCN hardware is using underlays.  E.g.,
the desktop plane would be at the top and would have holes cut out of
it for videos or windows that want their own plane.  If you do it the
other way around, there are lots of limitations.

Alex

>
>
> Thanks,
> pq