Re: backend-drm and scanning really large resolutions

Re: backend-drm and scanning really large resolutions

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 3024 bytes --]

On Fri, 17 Jan 2020 10:51:45 -0600
Matt Hoosier <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.
> 
> I'm wondering if anybody here knows whether this a legit approach for a
> compositor's DRM backend to take?

Hi,

I was aware of tiled monitors that need two connectors driven by two
CRTCs to cover the whole display, but that sounds new to me.
Libweston/DRM still doesn't support tiled monitors.

What a compositor's DRM-backend can or should do must be generic. It
cannot be driver or hardware dependent, so handling your case specially
in userspace would need KMS UAPI to communicate the need in the first
place. (There is no shared library for "KMS userspace drivers", yet at
least.)

I am not aware of any KMS UAPI that would indicate the need to use two
primary planes in a specific configuration for a specific video mode.
I'm saying two primary planes, because that is the only way I can see
this situation even hinted at userspace with the current UAPI. I also
don't know if multiple primary planes is allowed, but it certainly is
not expected by userspace, so userspace can't make use of it as is.

The idea that comes to my mind is to hide all the details in the
driver. Expose just one primary plane as usual, and if the video mode
and FB actually need two scanout units, then steal one under the hood
in the driver. If that makes another KMS plane (exposed to userspace)
unusable, that is fine. Userspace with atomic modesetting needs to be
checking with TEST_ONLY to see if a configuration is possible, and will
fall back to something else.

For legacy modesetting I guess you would need to pick between
supporting the really large video modes vs. exposing all planes. But
that's a no-brainer, since the legacy API for planes is practically
unusable. Then again, I don't know if the kernel DRM core allows you to
make such distinction.

Btw. AFAIK there is nothing wrong with using the exact same FB on
multiple planes simultaneously.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: backend-drm and scanning really large resolutions

[Matt Hoosier]

[-- Attachment #1.1: Type: text/plain, Size: 4054 bytes --]

On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:

> On Fri, 17 Jan 2020 10:51:45 -0600
> Matt Hoosier <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.
> >
> > I'm wondering if anybody here knows whether this a legit approach for a
> > compositor's DRM backend to take?
>

Hi Pekka; thanks for the reply.


>
> Hi,
>
> I was aware of tiled monitors that need two connectors driven by two
> CRTCs to cover the whole display, but that sounds new to me.
> Libweston/DRM still doesn't support tiled monitors.
>
> What a compositor's DRM-backend can or should do must be generic. It
> cannot be driver or hardware dependent, so handling your case specially
> in userspace would need KMS UAPI to communicate the need in the first
> place. (There is no shared library for "KMS userspace drivers", yet at
> least.)
>
> I am not aware of any KMS UAPI that would indicate the need to use two
> primary planes in a specific configuration for a specific video mode.
> I'm saying two primary planes, because that is the only way I can see
> this situation even hinted at userspace with the current UAPI. I also
> don't know if multiple primary planes is allowed, but it certainly is
> not expected by userspace, so userspace can't make use of it as is.
>

Just to double-check: I think we're still talking here about
universal-plane mode, so we only mean "primary plane" in an informal sense?
This problem would crop up on any attempt to attach a huge framebuffer to a
single plane (whether it happened to be the bottom z-sorted one or a
something used as an overlay).


>
> The idea that comes to my mind is to hide all the details in the
> driver. Expose just one primary plane as usual, and if the video mode
> and FB actually need two scanout units, then steal one under the hood
> in the driver. If that makes another KMS plane (exposed to userspace)
> unusable, that is fine. Userspace with atomic modesetting needs to be
> checking with TEST_ONLY to see if a configuration is possible, and will
> fall back to something else.
>

I think that's about the only approach that would make sense. Who would be
a good person to sanity-check that with? Daniel V? Daniel S?

I suppose in principle that if this is a valid corner-case of the KMS api,
then maybe it wouldn't be wrong to enhance compositors DRM backends to
progressively attempt attaching more and more planes to scan a framebuffer
if the drmModeAtomicCommit(DRM_MODE_ATOMIC_TEST_ONLY) fails for the base
case. But whether anybody in the Weston world would want that patch is
probably another story...


>
> For legacy modesetting I guess you would need to pick between
> supporting the really large video modes vs. exposing all planes. But
> that's a no-brainer, since the legacy API for planes is practically
> unusable. Then again, I don't know if the kernel DRM core allows you to
> make such distinction.
>
> Btw. AFAIK there is nothing wrong with using the exact same FB on
> multiple planes simultaneously.
>
>
> Thanks,
> pq
>

[-- Attachment #1.2: Type: text/html, Size: 5357 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: backend-drm and scanning really large resolutions

[Rob Clark]

On Fri, Jan 17, 2020 at 8:52 AM Matt Hoosier <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?
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: backend-drm and scanning really large resolutions

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 7179 bytes --]

On Tue, 21 Jan 2020 08:51:26 -0600
Matt Hoosier <matt.hoosier@gmail.com> wrote:

> On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> 
> > On Fri, 17 Jan 2020 10:51:45 -0600
> > Matt Hoosier <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.
> > >
> > > I'm wondering if anybody here knows whether this a legit approach for a
> > > compositor's DRM backend to take?  
> >  
> 
> Hi Pekka; thanks for the reply.
> 
> 
> >
> > Hi,
> >
> > I was aware of tiled monitors that need two connectors driven by two
> > CRTCs to cover the whole display, but that sounds new to me.
> > Libweston/DRM still doesn't support tiled monitors.
> >
> > What a compositor's DRM-backend can or should do must be generic. It
> > cannot be driver or hardware dependent, so handling your case specially
> > in userspace would need KMS UAPI to communicate the need in the first
> > place. (There is no shared library for "KMS userspace drivers", yet at
> > least.)
> >
> > I am not aware of any KMS UAPI that would indicate the need to use two
> > primary planes in a specific configuration for a specific video mode.
> > I'm saying two primary planes, because that is the only way I can see
> > this situation even hinted at userspace with the current UAPI. I also
> > don't know if multiple primary planes is allowed, but it certainly is
> > not expected by userspace, so userspace can't make use of it as is.
> >  
> 
> Just to double-check: I think we're still talking here about
> universal-plane mode, so we only mean "primary plane" in an informal sense?

Hi,

I'm talking in both universal-planes and atomic modesetting mode. I
always talk from the userspace point of view as I'm not a kernel
developer. In my mind, the concept of "primary plane" does not exist
before universal planes. There is only drmModeSetCrtc() in the
pre-atomic world and that acts on a CRTC, not a plane, and assumes
the FB must cover the whole CRTC area exactly and without scaling.

IOW, there is no legacy UAPI that you could even use to poke more than
one (primary) plane AFAIU.

> This problem would crop up on any attempt to attach a huge framebuffer to a
> single plane (whether it happened to be the bottom z-sorted one or a
> something used as an overlay).

Traditionally hardware has required that a CRTC must have exactly one
primary plane enabled and that plane must cover the whole CRTC area
exactly. Otherwise the CRTC will not light up. Therefore userspace has
been written with this assumption, so it special-cases the primary
plane. Some KMS programs might try other things first, but this is the
baseline they expect to be the right thing to do when nothing else
works.

Non-primary planes, that is overlays and underlays (both as type
"overlay" in universal planes), and cursors kind of, are traditionally
much more flexible, but I don't know of any userspace that would
attempt to use more than one plane to present one FB. If using a
non-primary plane fails on the first try, userspace doesn't know why -
there are a million things it could attempt to change, so it probably
just doesn't bother. Documenting what fallback strategies to try would
be nice on one hand, but OTOH the more strategies there are, the more
time it will take for userspace to search that solution space.

> > The idea that comes to my mind is to hide all the details in the
> > driver. Expose just one primary plane as usual, and if the video mode
> > and FB actually need two scanout units, then steal one under the hood
> > in the driver. If that makes another KMS plane (exposed to userspace)
> > unusable, that is fine. Userspace with atomic modesetting needs to be
> > checking with TEST_ONLY to see if a configuration is possible, and will
> > fall back to something else.
> >  
> 
> I think that's about the only approach that would make sense. Who would be
> a good person to sanity-check that with? Daniel V? Daniel S?

Daniel Vetter is an authority to me in these matters.

> I suppose in principle that if this is a valid corner-case of the KMS api,
> then maybe it wouldn't be wrong to enhance compositors DRM backends to
> progressively attempt attaching more and more planes to scan a framebuffer
> if the drmModeAtomicCommit(DRM_MODE_ATOMIC_TEST_ONLY) fails for the base
> case. But whether anybody in the Weston world would want that patch is
> probably another story...

I suspect that would lead to a mess on both kernel and userspace sides,
since once you establish something like that, you cannot get rid of it.
You would need to document it as UAPI that if userspace fails to enable
the primary plane in isolation, then it needs to try with more primary
planes splitting the FB among them in a specific way. What way?
Horizontally? Vertically? Both? How future-proof is that?

Besides, Weston is not at all the only display server you'd have to
patch. There is Xorg/modesetting, every single DE that runs with
Wayland, and all apps written for KMS directly. Even more, you also get
to fix all apps that use DRM leases, which likely includes things like
VR compositors.

Hiding all this inside your driver in the kernel is a much more
attractive approach to me. Userspace will always be shooting in the
dark, but the driver knows its constraints. I don't see the use of
multiple hwpipes or whatever as something the userspace would want to
control explicitly. Userspace just wants the hardware to work, it
doesn't care how.


Thanks,
pq

> > For legacy modesetting I guess you would need to pick between
> > supporting the really large video modes vs. exposing all planes. But
> > that's a no-brainer, since the legacy API for planes is practically
> > unusable. Then again, I don't know if the kernel DRM core allows you to
> > make such distinction.
> >
> > Btw. AFAIK there is nothing wrong with using the exact same FB on
> > multiple planes simultaneously.
> >
> >
> > Thanks,
> > pq
> >  


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: backend-drm and scanning really large resolutions

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 4324 bytes --]

On Fri, 24 Jan 2020 10:25:05 +0200
Pekka Paalanen <ppaalanen@gmail.com> wrote:

> On Tue, 21 Jan 2020 08:51:26 -0600
> Matt Hoosier <matt.hoosier@gmail.com> wrote:
> 
> > On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >   
> > > On Fri, 17 Jan 2020 10:51:45 -0600
> > > Matt Hoosier <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.
> > > >
> > > > I'm wondering if anybody here knows whether this a legit approach for a
> > > > compositor's DRM backend to take?    
> > >    
> > 
> > Hi Pekka; thanks for the reply.
> > 
> >   
> > >
> > > Hi,
> > >
> > > I was aware of tiled monitors that need two connectors driven by two
> > > CRTCs to cover the whole display, but that sounds new to me.
> > > Libweston/DRM still doesn't support tiled monitors.
> > >
> > > What a compositor's DRM-backend can or should do must be generic. It
> > > cannot be driver or hardware dependent, so handling your case specially
> > > in userspace would need KMS UAPI to communicate the need in the first
> > > place. (There is no shared library for "KMS userspace drivers", yet at
> > > least.)
> > >
> > > I am not aware of any KMS UAPI that would indicate the need to use two
> > > primary planes in a specific configuration for a specific video mode.
> > > I'm saying two primary planes, because that is the only way I can see
> > > this situation even hinted at userspace with the current UAPI. I also
> > > don't know if multiple primary planes is allowed, but it certainly is
> > > not expected by userspace, so userspace can't make use of it as is.
> > >    
> > 
> > Just to double-check: I think we're still talking here about
> > universal-plane mode, so we only mean "primary plane" in an informal sense?  
> 
> Hi,
> 
> I'm talking in both universal-planes and atomic modesetting mode. I
> always talk from the userspace point of view as I'm not a kernel
> developer. In my mind, the concept of "primary plane" does not exist
> before universal planes. There is only drmModeSetCrtc() in the
> pre-atomic world and that acts on a CRTC, not a plane, and assumes
> the FB must cover the whole CRTC area exactly and without scaling.
> 
> IOW, there is no legacy UAPI that you could even use to poke more than
> one (primary) plane AFAIU.

...

> Besides, Weston is not at all the only display server you'd have to
> patch. There is Xorg/modesetting, every single DE that runs with
> Wayland, and all apps written for KMS directly. Even more, you also get
> to fix all apps that use DRM leases, which likely includes things like
> VR compositors.

Btw. GNOME/Wayland (Mutter) is only getting into atomic modesetting
soon(?), it has had a long road of re-architecting to get into a
position where it can start implementing atomic KMS usage. And
Xorg/modesetting is still legacy-only too, in spite of the poor attempt
to make it atomic which had to be disabled on the kernel DRM side, and
probably unlikely to ever be atomic really due to the amount of work
needed to make it fit in IIUC.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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 <wxiaowen@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@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

Hi Daniel,

Sorry the email was buried among others for half a year... I hope it's 
still not too late to continue the discussion...

Yes I agree directly modifying the real plane may confuse the user, 
however this is not the first time DRM is doing such thing. When 
handling conflicted encoders in handle_conflicting_encoders(), DRM 
atomic helper is already doing in such a way that:

1. Add connector/crtc that has conflicted encoder to state
2. Set these affected connectors' CRTC_ID to 0
3. Set these affected crtcs' active to false

Above 2) and 3) are also state that are visible to user.

So if 2) and 3) is allowed for CRTC and connector, I don't see why 
updating affected plane would be a problem? This is just another 
conflict handling, but this time it's on plane resource.

As a comparison, when do it in a second level under plane without 
updating plane's visible state, as internally the resource is still 
stolen, user will get failure during atomic check. In this model user 
also get the failure, although the failure reason in this model is CRTC 
conflict.

I can make a helper function for this, in the same way as 
handle_conflicting_encoders(). As the helper only steals plane that is 
currently idle to all CRTCs, do you foresee any existing driver will be 
affected by this model? Driver should treat it as configuration from 
user so they don't need to do anything in extra.

-Xiaowen
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: backend-drm and scanning really large resolutions

[Daniel Vetter]

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 <wxiaowen@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@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


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: backend-drm and scanning really large resolutions

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 4253 bytes --]

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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel