On Tue, 21 Jan 2020 08:51:26 -0600 Matt Hoosier <matt.hoosier@xxxxxxxxx> wrote: > On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: > > > On Fri, 17 Jan 2020 10:51:45 -0600 > > Matt Hoosier <matt.hoosier@xxxxxxxxx> 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:
pgpmZDhKDEHC9.pgp
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
