backend-drm and scanning really large resolutions

[Matt Hoosier]

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

> On Fri, 17 Jan 2020 10:51:45 -0600
> 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.
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200121/c0c22695/attachment.htm>