backend-drm and scanning really large resolutions
ppaalanen at gmail.com
Thu Feb 13 09:37:40 UTC 2020
Adding Rob back in CC, I don't know if he is subscribed to
wayland-devel at . You forgot to CC dri-devel@ too.
On Tue, 11 Feb 2020 17:18:52 -0500
Xiaowen Wu <wxiaowen at codeaurora.org> wrote:
> Hi Rob,
> If the vendor driver doesn't have the hwpipe sub-object and kms plane is
> one-to-one mapped to hwpipe (sspp),
> do you think if below approach is acceptable if we still want to
> virtualize the kms plane to support 4K/8K scanout?
> 1. At kms atomic check before calling drm_atomic_helper_check, depending
> on scanout width of plane A in state, add idle planes B (C,D,...)
> into the same atomic state, backup and then modify
> src_x/src_w/crtc_x/crtc_w of plane A and the affected planes B (C,D,...)
> to meet scanout
> width limits, and set crtc/fb of the affected planes B (C,D,...) same as
> plane A.
> 2. At plane's state duplicate function, check if plane's
> src_x/src_w/crtc_x/crtc_w are updated at step 1), if so revert the
> change to
> plane A's backup value to allow plane A's scanout to update again. These
> value will again be updated in step 1) so nothing really changes
> if plane A continues updating.
> 3. If plane A's scanout is updated or detached from crtc, detach
> affected planes B (C,D,...) in the same atomic state in step 1) and then
> run step 1) again.
> 4. If user want to commit plane B (C,D,...), the commit/test will fail
> if planes are already used as sister plane of plane A. This failure is
> as insufficient hwpipe from plane B (C,D,...).
> With above change, any downstream driver can support virtualized plane.
> Also as the above approach is generic and not h/w specific, we can make
> it a helper function and it's up to vendor to choose if they want to use
> or not, if they don't have logic like drm/msm/disp/mdp5/mdp5_plane in
> their downstream driver.
> Conceptional above changes didn't borrow hwpipe resources from other
> plane but borrow planes themselves directly, however from user point of
> they should not feel any difference.
> What do you think?
> Xiaowen Wu
> On Tue Jan 21, 2020 at 4:12 PM Rob Clark <robdclark at gmail.com> wrote:
> > On Fri, Jan 17, 2020 at 8:52 AM Matt Hoosier <matt.hoosier at
> > gmail.com> wrote:
> >> Hi all,
> >> I'm confronting a situation where the hardware with which I work is
> >> capable of driving connectors at 4K or 8K, but doing so requires
> >> bonding the scanning of multiple planes together.
> >> The scenario is that you'd have a big primary framebuffer whose size
> >> is too large for an individual hardware scanning pipeline on the
> >> display controller to traverse within its maximum allowed clock rate.
> >> The hardware supplier's approach is to assign multiple planes, which
> >> in the KMS driver map to hardware scanning pipelines, to each be
> >> responsible for scanning a smaller section of the framebuffer. The
> >> planes are all assigned to the same CRTC, and in concert with each
> >> other they cover the whole area of the framebuffer and CRTC.
> >> This sounds a little bit wild to me. I hadn't been aware it's even
> >> legal to have more than one plane treated a the source of scanout for
> >> a single framebuffer. Maybe that distinction isn't really relevant
> >> nowadays with universal plane support.
> > fwiw, have a look at drm/msm/disp/mdp5/mdp5_plane, which will allocate
> > one or two hwpipe's from the devices global atomic state, depending on
> > scanout width.. the hwpipe (sspp) is the physical resource behind a
> > plane, so essentially the kms planes are virtualized. At some point
> > if you have too many wide layers, the atomic test step will fail due
> > to insufficient hwpipe's. But this sort of scenario is the reason for
> > the test step.
> > BR,
> > -R
> >> I'm wondering if anybody here knows whether this a legit approach for
> >> a compositor's DRM backend to take?
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel