universal planes in drm backend

[Pekka Paalanen]

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 --------------
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/wayland-devel/attachments/20190918/73083b04/attachment.sig>