Re: backend-drm and scanning really large resolutions
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 mail
Re: backend-drm and scanning really large resolutions
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? > > >> > > ___ > > waylan
Re: backend-drm and scanning really large resolutions
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? > > 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 pgp2P8CP7zVh3.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: backend-drm and scanning really large resolutions
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 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
Re: backend-drm and scanning really large resolutions
On Fri, 24 Jan 2020 10:25:05 +0200 Pekka Paalanen wrote: > On Tue, 21 Jan 2020 08:51:26 -0600 > Matt Hoosier wrote: > > > On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen wrote: > > > > > On Fri, 17 Jan 2020 10:51:45 -0600 > > > Matt Hoosier 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 pgpTaOBBiz8F5.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: backend-drm and scanning really large resolutions
On Tue, 21 Jan 2020 08:51:26 -0600 Matt Hoosier wrote: > On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen wrote: > > > On Fri, 17 Jan 2020 10:51:45 -0600 > > Matt Hoosier 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
Re: backend-drm and scanning really large resolutions
On Fri, Jan 17, 2020 at 8:52 AM Matt Hoosier 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
Re: backend-drm and scanning really large resolutions
On Mon, Jan 20, 2020 at 2:58 AM Pekka Paalanen wrote: > On Fri, 17 Jan 2020 10:51:45 -0600 > Matt Hoosier 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 > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: backend-drm and scanning really large resolutions
On Fri, 17 Jan 2020 10:51:45 -0600 Matt Hoosier 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 pgpnZI5zsnFVO.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
backend-drm and scanning really large resolutions
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? -Matt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
