backend-drm and scanning really large resolutions

[Pekka Paalanen]

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?
> 
> 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

-------------- 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/dri-devel/attachments/20200213/e08ee98d/attachment.sig>