Re: universal planes in drm backend
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 于2019年9月18日周三 下午3:54写道： > On Tue, 17 Sep 2019 10:02:44 + > Simon Ser wrote: > > > On Tuesday, September 17, 2019 12:29 PM, Pekka Paalanen < > ppaala...@gmail.com> wrote: > > > > > On Tue, 17 Sep 2019 19:50:01 +1200 > > > Scott Anderson scott.ander...@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
Re: universal planes in drm backend
On Tue, 17 Sep 2019 10:02:44 + Simon Ser wrote: > On Tuesday, September 17, 2019 12:29 PM, Pekka Paalanen > wrote: > > > On Tue, 17 Sep 2019 19:50:01 +1200 > > Scott Anderson scott.ander...@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 pgpvT8Thr7Pbg.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: universal planes in drm backend
On Tuesday, September 17, 2019 12:29 PM, Pekka Paalanen wrote: > On Tue, 17 Sep 2019 19:50:01 +1200 > Scott Anderson scott.ander...@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. > Thanks, > pq > > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: universal planes in drm backend
On Tue, 17 Sep 2019 19:50:01 +1200 Scott Anderson 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). Thanks, pq pgpkqEbcr9c1T.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: universal planes in drm backend
Hi scott yes, one CRTC bind to one primary plane. But if not all the crtcs are connected and universal planes is enable, the spare primary plane could be an overlay plane. for example, plane 0 ~ 5 for 6 CRTCs, they are all primary planes. But weston only enable 3 output, then plane 3 ~ 5 could treat as overlay plane. Thank you! Best regards Nancy Scott Anderson 于2019年9月17日周二 下午3:50写道： > 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. > > Scott > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: universal planes in drm backend
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. Scott ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
