backend-drm and scanning really large resolutions

Thu Feb 13 10:16:55 UTC 2020

On Thu, Feb 13, 2020 at 11:37:40AM +0200, Pekka Paalanen wrote:
> 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 
> > same
> > 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 
> > view
> > they should not feel any difference.
> > 
> > What do you think?

The trouble with modifying the real plane states (instead of a 2nd layer
of hw objects) is that changes the userspace visible state. Which could
confuse the heck out of userspace. That's why in all these cases where the
hw needs 2 things in gang mode (we have other examples where you need to
double up clocks or crtcs or whatever in other drivers/hw) we've made a
driver specific layer - that way you can store the stuff you exactly need,
and not something generic.

Maybe there is some room for generic helpers, but you'd need to prove your
case by converting a few drivers over to this model. There's a lot
already which virtualize planes in one way or another, but they're all
slightly different. Thus far simply rolling your own in each driver
proved to be quicker.
-Daniel

> > 
> > BR,
> > 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
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch