This change adds support for inline rotation in the dpu driver.
When inline rotation is enabled the VIG pipes will directly fetch the image
from memory in a rotated fashion
Inline rotation has following restrictions
1) Supported only with compressed formats
2) max pre rotated height is 1088
3) restrictions with downscaling ratio
Queries:
1) Since inline rotation works for fewer pixel formats with specific modifier, how can we provide this information to the compositor so that
chrome compositor can choose between overlaying or falling back to GPU. In the patch it fails in the atomic check.
2) If a display composition fails in atomic check due to any of the restrictions in overlays
can chrome compositor switch it back to the GPU and re trigger the commit ?
posting it as RFC as validation is not complete, please share early comments on this.
Kalyan Thota (1):
drm/msm/disp/dpu1: add support for inline rotation in dpu driver
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 47 +++++++++----
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 20 ++++++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 93 ++++++++++++++++++++------
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 +
4 files changed, 128 insertions(+), 34 deletions(-)
--
2.7.4
On Sat, Jul 3, 2021 at 4:32 AM Kalyan Thota <[email protected]> wrote:
>
> This change adds support for inline rotation in the dpu driver.
> When inline rotation is enabled the VIG pipes will directly fetch the image
> from memory in a rotated fashion
>
> Inline rotation has following restrictions
> 1) Supported only with compressed formats
> 2) max pre rotated height is 1088
> 3) restrictions with downscaling ratio
>
> Queries:
>
> 1) Since inline rotation works for fewer pixel formats with specific modifier, how can we provide this information to the compositor so that
> chrome compositor can choose between overlaying or falling back to GPU. In the patch it fails in the atomic check.
>
> 2) If a display composition fails in atomic check due to any of the restrictions in overlays
> can chrome compositor switch it back to the GPU and re trigger the commit ?
The correct way to provide this information to userspace is for the
atomic test step to fail. Admittedly the CrOS compositor makes some
invalid assumptions that if a given state was valid in the past, it
will be valid in the future. But I don't see height/format/downscale
restrictions as a thing that would change from frame to frame.
BR,
-R
> posting it as RFC as validation is not complete, please share early comments on this.
>
> Kalyan Thota (1):
> drm/msm/disp/dpu1: add support for inline rotation in dpu driver
>
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 47 +++++++++----
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 20 ++++++
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 93 ++++++++++++++++++++------
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 +
> 4 files changed, 128 insertions(+), 34 deletions(-)
>
> --
> 2.7.4
>
On 03/07/2021 14:32, Kalyan Thota wrote:
> This change adds support for inline rotation in the dpu driver.
> When inline rotation is enabled the VIG pipes will directly fetch the image
> from memory in a rotated fashion
>
> Inline rotation has following restrictions
> 1) Supported only with compressed formats
NV12, which is the only format you declare, is not compressed.
> 2) max pre rotated height is 1088
> 3) restrictions with downscaling ratio
>
> Queries:
>
> 1) Since inline rotation works for fewer pixel formats with specific modifier, how can we provide this information to the compositor so that
> chrome compositor can choose between overlaying or falling back to GPU. In the patch it fails in the atomic check.
>
> 2) If a display composition fails in atomic check due to any of the restrictions in overlays
> can chrome compositor switch it back to the GPU and re trigger the commit ?
>
> posting it as RFC as validation is not complete, please share early comments on this.
>
> Kalyan Thota (1):
> drm/msm/disp/dpu1: add support for inline rotation in dpu driver
>
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 47 +++++++++----
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 20 ++++++
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 93 ++++++++++++++++++++------
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 +
> 4 files changed, 128 insertions(+), 34 deletions(-)
>
--
With best wishes
Dmitry
On Sun, Jul 4, 2021 at 1:25 AM Dmitry Baryshkov
<[email protected]> wrote:
>
> On 03/07/2021 14:32, Kalyan Thota wrote:
> > This change adds support for inline rotation in the dpu driver.
> > When inline rotation is enabled the VIG pipes will directly fetch the image
> > from memory in a rotated fashion
> >
> > Inline rotation has following restrictions
> > 1) Supported only with compressed formats
>
> NV12, which is the only format you declare, is not compressed.
nv12 can be used with the UBWC modifier, fwiw.. we use this in CrOS,
albeit with a hack on the v4l2 side to work around lack of modifier
support in v4l2
BR,
-R
> > 2) max pre rotated height is 1088
> > 3) restrictions with downscaling ratio
> >
> > Queries:
> >
> > 1) Since inline rotation works for fewer pixel formats with specific modifier, how can we provide this information to the compositor so that
> > chrome compositor can choose between overlaying or falling back to GPU. In the patch it fails in the atomic check.
> >
> > 2) If a display composition fails in atomic check due to any of the restrictions in overlays
> > can chrome compositor switch it back to the GPU and re trigger the commit ?
> >
> > posting it as RFC as validation is not complete, please share early comments on this.
> >
> > Kalyan Thota (1):
> > drm/msm/disp/dpu1: add support for inline rotation in dpu driver
> >
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 47 +++++++++----
> > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 20 ++++++
> > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 93 ++++++++++++++++++++------
> > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 2 +
> > 4 files changed, 128 insertions(+), 34 deletions(-)
> >
>
>
> --
> With best wishes
> Dmitry