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(-)
On Sat, Jul 3, 2021 at 4:32 AM Kalyan Thota kalyan_t@codeaurora.org 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
- Supported only with compressed formats
- max pre rotated height is 1088
- restrictions with downscaling ratio
Queries:
- 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.
- 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
- Supported only with compressed formats
NV12, which is the only format you declare, is not compressed.
- max pre rotated height is 1088
- restrictions with downscaling ratio
Queries:
- 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.
- 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(-)
On Sun, Jul 4, 2021 at 1:25 AM Dmitry Baryshkov dmitry.baryshkov@linaro.org 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
- 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
- max pre rotated height is 1088
- restrictions with downscaling ratio
Queries:
- 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.
- 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
dri-devel@lists.freedesktop.org
-
Dmitry Baryshkov -
Kalyan Thota -
Rob Clark