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?
- 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.
- 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.
- 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.
- 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
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?
- 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.
- 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.
- 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.
- 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
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?
- 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.
- 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.
- 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.
- 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@lists.freedesktop.org
-
Daniel Vetter -
Pekka Paalanen -
Xiaowen Wu