Re: backend-drm and scanning really large resolutions

[Xiaowen Wu]

On 2020-02-13 05:16, Daniel Vetter wrote:

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@. You forgot to CC dri-devel@ too.


On Tue, 11 Feb 2020 17:18:52 -0500
Xiaowen Wu  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  wrote:
> > On Fri, Jan 17, 2020 at 8:52 AM Matt Hoosier  > 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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel






___
wayland-devel 

Re: Basic API usage

[Jan Bruns]

Pekka Paalanen wrote:
> Jan Bruns  wrote:
>
>> Ok. I now have an even earlier point of missing knowledge than I 
expected:

>>
>> Why does the generated version of wayland-client-protocol.h reference a
>> server object called "wl_registry_interface"?
>
> These interface structures are used both server and client side. The
> core of libwayland needs to know the message signatures for it to be
> able to marshall them. As we want people to be able to use
> new extensions (XML files) without needing to rebuild libwayland to
> match, the signatures must be provided to libwayland.

I see. Probably an implementation detail a beginner like me shouldn't 
focus on too much.


I've just stumbled upon a more serious question:

registry.bind() doesn't have a version parameter, and also 
wl_proxy_add_listener().


Doesn't this mean that an App that doesn't know the latest version of an 
interface cannot use libwayland anymore?


How to tell libwayland to not attempt to call nonexisting callbacks?

Gruss

Jan Bruns

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[ANNOUNCE] libxkbcommon 1.0.1

[Ran Benita]

This is a fixup release to 1.0.0 to fix a failing test.

libxkbcommon 1.0.1
==

- Fix the tool-option-parsing test failing.

- Remove requirement for pytest in the tool-option-parsing test.

- Make the table output of `xkbcli how-to-type` aligned.

- Some portability and test isolation fixes.

Tarball:


git tag: xkbcommon-1.0.1

https://xkbcommon.org/download/libxkbcommon-1.0.1.tar.xz 

SHA256: ab68b25341c99f2218d7cf3dad459c1827f411219901ade05bbccbdb856b6c8d 
libxkbcommon-1.0.1.tar.xz

Ran___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel