universal planes in drm backend

[zou lan]

Hi all

Thank you for your feedback.

>From your opinions, the drm backend reserve primary plane for each CRTC to
avoid the failure in hotplug cases. However, as weston already enabled
DRM_CLIENT_CAP_ATOMIC and DRM_CLIENT_CAP_UNIVERSAL_PLANES, the concept of
primary/overlay is no necessary
https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#c.drm_plane_type:



For historical reasons not all planes are made the same. This enumeration
is used to tell the different types of planes apart to implement the
different uapi semantics for them. For userspace which is universal plane
aware and which is using that atomic IOCTL there's no difference between
these planes (beyong what the driver and hardware can support of course).



So weston should add the proper way to handle the case when output B is
newly connected while output A is using up all planes, e.g. trigger a
repaint for output A with less plane staged if new output B is hotplugged.
This will optimize the general performance of weston and avoid h/w resource
waste.



It’s popular that the number of CRTCs is more than the number of outputs. A
typical use case is DP-MST, where there could be multiple outputs in the
daisy chain but total link rate is limited, e.g. H/W can either support 2
monitors with 4K output, or 4 monitors with 2K output. 4 CRTCs will be
created at boot to support the 4 monitors with 2K output use case, but for
2 monitors with 4K output use case two planes will be completely wasted.


Thank you!


Best Regards

Nancy

Pekka Paalanen <ppaalanen at gmail.com> 于2019年9月18日周三 下午3:54写道：

> On Tue, 17 Sep 2019 10:02:44 +0000
> Simon Ser <contact at emersion.fr> wrote:
>
> > On Tuesday, September 17, 2019 12:29 PM, Pekka Paalanen <
> ppaalanen at gmail.com> wrote:
> >
> > > On Tue, 17 Sep 2019 19:50:01 +1200
> > > Scott Anderson scott.anderson at collabora.com wrote:
> > >
> > > > On 17/09/19 7:38 pm, zou lan wrote:
> > > >
> > > > > Hi Daniel & all
> > > > > I find the function drm_output_prepare_overlay_view() only use the
> plane
> > > > > type of WDRM_PLANE_TYPE_OVERLAY. it could be a waste for some
> planes of
> > > > > type WDRM_PLANE_TYPE_PRIMARY if the universal planes is enable.
> > > > > For example, the kernel define 6 crtcs, and each crtc will have one
> > > > > primary type plane, but not all of the crtcs are used by
> weston_output.
> > > > > Some crtcs may never used, if we reserve  all the primary type
> planes as
> > > > > scanout plane, that could waste some of them.
> > > > > Could the open source drm backend modify the logic of judge the
> overlay
> > > > > plane? let the primary plane equal to overlay plane or judge in
> > > > > drm_output_prepare_overlay_view(), if the plane is not used by
> outputs,
> > > > > it could be used by overlay?
> > > > > Thank you!
> > > > > Best regards
> > > > > Nancy
> > > > > Hi,
> > > >
> > > > As far as I'm aware, the kernel never advertises more than one
> primary
> > > > plane per CRTC and they're never possible to be used with multiple
> > > > CRTCs:
> > > >
> https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#plane-abstraction
> > > >
> > > > > All drivers should provide one primary plane per CRTC to avoid
> > > > > surprising userspace too much
> > > >
> > > > Perhaps that restriction is not as strict as I interpret it to be,
> but
> > > > I'm not aware of anything which does not have a one-to-one
> relationship
> > > > between primary planes and CRTCs.
> > >
> > > If the kernel actually did expose multiple primary planes on the same
> > > CRTC, they would also need zpos property to tell their stacking order,
> > > and Weston needs to use it (which it does not yet).
> > >
> > > However, given the special expectations that all userspace likely has
> > > for primary planes, the kernel driver might be better exposing more
> > > planes of type OVERLAY while internally mapping them to the "other
> > > primary planes".
> > >
> > > However, that would still pose a problem, that userspace would need to
> > > know to disable some/all overlay planes when activating a new output
> > > fails and try again with the hope that a primary plane was made
> > > available under the hood. That would be pretty special. So it is
> > > possible that exposing the additional planes would break existing
> > > userspace for hotplug output activation under special circumstances
> > > (overlay planes used on old outputs).
> >
> > I don't think that's an issue. Enabling overlay planes can fail for a
> > lot of other reasons, including for instance bandwidth limitations.
>
> Sure, an overlay plane failing is not an issue. A primary plane failing
> when no overlays on *that* CRTC are in used is an issue.
>
> To clarify, let's assume we have outputs A and B, and CRTCs A and B
> respectively.
>
> Output A is active, using one primary plane and three overlays on CRTC
> A. Output B is off.
>
> Output B needs to be activated. It needs a primary plane on CRTC B.
> However, no primary planes are actually usable, because output A is
> using them all. The compositor probably does not guess that it needs to
> stop using overlays on output A to be able to turn output B on.(*)
>
> If previously it was impossible for output A to use up all primary
> planes, enabling output B always succeeded. If the kernel driver then
> offers all primary planes on all CRTCs, allowing CRTC A to use them all
> up, then enabling output B will fail. By definition, this is a kernel
> induced regression: it used to work, then you upgraded the kernel, and
> now it doesn't work.
>
> (*) Or should it guess? If we think of global bandwidth limitations, it
> probably should. But if it doesn't, we are still facing a situation
> where the kernel regressed, because userspace stopped working.
>
>
> Thanks,
> pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190919/6ef1df63/attachment.html>