backend-drm and scanning really large resolutions

[Pekka Paalanen]

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

> On Tue, 21 Jan 2020 08:51:26 -0600
> Matt Hoosier <matt.hoosier at gmail.com> wrote:
> 
> > 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?  
> 
> 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
-------------- 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/20200124/83cf5b0a/attachment-0001.sig>