mbox series

[RFC,v7,00/10] Support for Solid Fill Planes

Message ID 20231027-solid-fill-v7-0-780188bfa7b2@quicinc.com (mailing list archive)
Headers show
Series Support for Solid Fill Planes | expand

Message

Jessica Zhang Oct. 27, 2023, 10:32 p.m. UTC
Some drivers support hardware that have optimizations for solid fill
planes. This series aims to expose these capabilities to userspace as
some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
hardware composer HAL) that can be set by apps like the Android Gears
test app.

In order to expose this capability to userspace, this series will:

- Introduce solid_fill and pixel_source properties to allow userspace to
  toggle between FB and solid fill sources
- Loosen NULL FB checks within the DRM atomic commit callstack to allow
  for NULL FB when solid fill is enabled.
- Add NULL FB checks in methods where FB was previously assumed to be
  non-NULL
- Have MSM DPU driver use drm_plane_state.solid_fill instead of
  dpu_plane_state.color_fill

Note: The solid fill planes feature depends on both the solid_fill *and*
pixel_source properties.

To use this feature, userspace can set the solid_fill property to a blob
containing the solid fill color (in RGB323232 format) and and setting the
pixel_source property to DRM_PLANE_PIXEL_SOURCE_SOLID_FILL. This will
disable memory fetch and the resulting plane will display the color
specified by the solid_fill blob.

In order to disable a solid fill plane, the user must set the pixel_source
to NONE. A plane with a pixel_source of "solid_fill" and a NULL solid_fill
blob will cause an error on commit.

Currently, there's only one version of the solid_fill blob property.
However if other drivers want to support a similar feature, but require
more than just the solid fill color, they can extend this feature by
extending the pixel_source enum and adding another solid fill blob property.

This 2 property approach was chosen because passing in a special 1x1 FB
with the necessary color information would have unecessary overhead that
does not reflect the behavior of the solid fill feature. In addition,
assigning the solid fill blob to FB_ID would require loosening some core
drm_property checks that might cause unwanted side effects elsewhere.

---
Changes in v7:
- Updated cover letter (Sebastian)
- Updated the uAPI documentation (Sebastian, Pekka)
- Specify that padding must be set to zero in drm_mode_solid_fill
  documentation (Pekka)
- Use %08x format when printing solid fill info in plane state dump (Pekka)
- Use new_plane_state->fb directly in drm_atomic_plane_check() (Dmitry)
- Dropped documentation for alpha for _dpu_plane_color_fill() (Dmitry)
- Defined DPU_SOLID_FILL_FORMAT macro (Dmitry)
- Fixed some necessary checks being skipped in the DPU atomic
  commit path (Dmitry)
- Rebased to tip of msm-next
- Picked up Acked-by and Reviewed-by tags

Changes in v6:
- Have _dpu_plane_color_fill() take in a single ABGR8888 color instead
  of having separate alpha and BGR color parameters (Dmitry)
- Drop plane->state->pixel_source != DRM_PLANE_PIXEL_SOURCE_FB check
  in SetPlane ioctl (Dmitry)
- Add DRM_PLANE_PIXEL_SOURCE_NONE as a default pixel source (Sebastian)
- Dropped versioning from solid fill property blob (Dmitry)
- Use DRM_ENUM_NAME_FN (Dmitry)
- Use drm_atomic_replace_property_blob_from_id() (Dmitry)
- drm_atomic_check_fb -> drm_atomic_plane_check_fb (Dmitry)
- Group redundant NULL FB checks (Dmitry)
- Squashed drm_plane_needs_disable() implementation with 
  DRM_PLANE_PIXEL_SOURCE_NONE declaration (Sebastian)
- Add comment to support RGBA solid fill color in the future (Dmitry)
- Link to v5: https://lore.kernel.org/r/20230728-solid-fill-v5-0-053dbefa909c@quicinc.com

Changes in v5:
- Added support for PIXEL_SOURCE_NONE (Sebastian)
- Added WARN_ON() in drm_plane_has_visible_data() if pixel_source isn't
  set (Dmitry)
- Added debugfs support for both properties (Dmitry)
- Corrected u32 to u8 conversion (Pekka)
- Moved drm_solid_fill_info struct and related documentation to
  include/uapi (Pekka)
- Changed drm_solid_fill_info.version to __u32 for data alignment (Pekka)
- Added more detailed UAPI and kernel documentation (Pekka)
- Reordered patch series so that the pixel_source property is introduced
  before solid_fill (Dmitry)
- Fixed inconsistent ABGR8888/RGBA8888 format declaration (Pekka)
- Reset pixel_source to FB in drm_mode_setplane() (Dmitry)
- Rename supported_sources to extra_sources (Dmitry)
- Only destroy old solid_fill blob state if new state is valid (Pekka)
- Link to v4: https://lore.kernel.org/r/20230404-solid-fill-v4-0-f4ec0caa742d@quicinc.com

Changes in v4:
- Rebased onto latest kernel
- Reworded cover letter for clarity (Dmitry)
- Reworded commit messages for clarity
- Split existing changes into smaller commits
- Added pixel_source enum property (Dmitry, Pekka, Ville)
- Updated drm-kms comment docs with pixel_source and solid_fill
  properties (Dmitry)
- Inlined drm_atomic_convert_solid_fill_info() (Dmitry)
- Passed in plane state alpha value to _dpu_plane_color_fill_pipe()
- Link to v3: https://lore.kernel.org/r/20230104234036.636-1-quic_jesszhan@quicinc.com

Changes in v3:
- Fixed some logic errors in atomic checks (Dmitry)
- Introduced drm_plane_has_visible_data() and drm_atomic_check_fb() helper
  methods (Dmitry)
- Fixed typo in drm_solid_fill struct documentation
- Created drm_plane_has_visible_data() helper and corrected CRTC and FB
  NULL-check logic (Dmitry)
- Merged `if (fb)` blocks in drm_atomic_plane_check() and abstracted
  them into helper method (Dmitry)
- Inverted `if (solid_fill_enabled) else if (fb)` check order (Dmitry)
- Fixed indentation (Dmitry)

Changes in v2:
- Dropped SOLID_FILL_FORMAT property (Simon)
- Switched to implementing solid_fill property as a blob (Simon, Dmitry)
- Added drm_solid_fill and drm_solid_fill_info structs (Simon)
- Changed to checks for if solid_fill_blob is set (Dmitry)
- Abstracted (plane_state && !solid_fill_blob) checks to helper method
  (Dmitry)
- Removed DPU_PLANE_COLOR_FILL_FLAG
- Fixed whitespace and indentation issues (Dmitry)
- Changed to checks for if solid_fill_blob is set (Dmitry)
- Abstracted (plane_state && !solid_fill_blob) checks to helper method
  (Dmitry)
- Fixed dropped 'const' warning
- Added helper to convert color fill to BGR888 (Rob)
- Fixed indentation issue (Dmitry)
- Added support for solid fill on planes of varying sizes

---
Jessica Zhang (10):
      drm: Introduce pixel_source DRM plane property
      drm: Introduce solid fill DRM plane property
      drm: Add solid fill pixel source
      drm/atomic: Add pixel source to plane state dump
      drm/atomic: Add solid fill data to plane state dump
      drm/atomic: Move framebuffer checks to helper
      drm/atomic: Loosen FB atomic checks
      drm/msm/dpu: Allow NULL FBs in atomic commit
      drm/msm/dpu: Use DRM solid_fill property
      drm/msm/dpu: Add solid fill and pixel source properties

 drivers/gpu/drm/drm_atomic.c              | 148 +++++++++++++++++-------------
 drivers/gpu/drm/drm_atomic_helper.c       |  39 ++++----
 drivers/gpu/drm/drm_atomic_state_helper.c |  10 ++
 drivers/gpu/drm/drm_atomic_uapi.c         |  30 ++++++
 drivers/gpu/drm/drm_blend.c               | 133 +++++++++++++++++++++++++++
 drivers/gpu/drm/drm_crtc_internal.h       |   1 +
 drivers/gpu/drm/drm_plane.c               |  27 +++++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  |   9 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |  75 ++++++++++-----
 include/drm/drm_atomic_helper.h           |   4 +-
 include/drm/drm_blend.h                   |   3 +
 include/drm/drm_plane.h                   |  90 ++++++++++++++++++
 include/uapi/drm/drm_mode.h               |  24 +++++
 13 files changed, 481 insertions(+), 112 deletions(-)
---
base-commit: b08d26dac1a1075c874f40ee02ec8ddc39e20146
change-id: 20230404-solid-fill-05016175db36

Best regards,

Comments

Dmitry Baryshkov Dec. 2, 2023, 9:41 p.m. UTC | #1
On Fri, 27 Oct 2023 15:32:50 -0700, Jessica Zhang wrote:
> Some drivers support hardware that have optimizations for solid fill
> planes. This series aims to expose these capabilities to userspace as
> some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
> hardware composer HAL) that can be set by apps like the Android Gears
> test app.
> 
> In order to expose this capability to userspace, this series will:
> 
> [...]

Applied to drm-misc-next, thanks!

[01/10] drm: Introduce pixel_source DRM plane property
        commit: e50e5fed41c7eed2db4119645bf3480ec43fec11
[02/10] drm: Introduce solid fill DRM plane property
        commit: 85863a4e16e77079ee14865905ddc3ef9483a640
[03/10] drm: Add solid fill pixel source
        commit: 4b64167042927531f4cfaf035b8f88c2f7a05f06
[04/10] drm/atomic: Add pixel source to plane state dump
        commit: 8283ac7871a959848e09fc6593b8c12b8febfee6
[05/10] drm/atomic: Add solid fill data to plane state dump
        commit: e86413f5442ee094e66b3e75f2d3419ed0df9520
[06/10] drm/atomic: Move framebuffer checks to helper
        commit: 4ba6b7a646321e740c7f2d80c90505019c4e8fce
[07/10] drm/atomic: Loosen FB atomic checks
        commit: f1e75da5364e780905d9cd6043f9c74cdcf84073

Best regards,
Simon Ser Dec. 3, 2023, 12:15 p.m. UTC | #2
On Saturday, December 2nd, 2023 at 22:41, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:

> On Fri, 27 Oct 2023 15:32:50 -0700, Jessica Zhang wrote:
> 
> > Some drivers support hardware that have optimizations for solid fill
> > planes. This series aims to expose these capabilities to userspace as
> > some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
> > hardware composer HAL) that can be set by apps like the Android Gears
> > test app.
> > 
> > In order to expose this capability to userspace, this series will:
> > 
> > [...]
> 
> 
> Applied to drm-misc-next, thanks!

Where are the IGT and userspace for this uAPI addition?
Dmitry Baryshkov Dec. 3, 2023, 6:10 p.m. UTC | #3
On Sun, 3 Dec 2023 at 14:15, Simon Ser <contact@emersion.fr> wrote:
>
> On Saturday, December 2nd, 2023 at 22:41, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
>
> > On Fri, 27 Oct 2023 15:32:50 -0700, Jessica Zhang wrote:
> >
> > > Some drivers support hardware that have optimizations for solid fill
> > > planes. This series aims to expose these capabilities to userspace as
> > > some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
> > > hardware composer HAL) that can be set by apps like the Android Gears
> > > test app.
> > >
> > > In order to expose this capability to userspace, this series will:
> > >
> > > [...]
> >
> >
> > Applied to drm-misc-next, thanks!
>
> Where are the IGT and userspace for this uAPI addition?

Indeed. I checked that there are uABI acks/reviews, but I didn't check
these requirements. Frankly speaking, I thought that they were handled
already, before giving the ack. How should we proceed? Should I land a
revert?
Maxime Ripard Dec. 4, 2023, 9 a.m. UTC | #4
On Sun, Dec 03, 2023 at 08:10:31PM +0200, Dmitry Baryshkov wrote:
> On Sun, 3 Dec 2023 at 14:15, Simon Ser <contact@emersion.fr> wrote:
> >
> > On Saturday, December 2nd, 2023 at 22:41, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> >
> > > On Fri, 27 Oct 2023 15:32:50 -0700, Jessica Zhang wrote:
> > >
> > > > Some drivers support hardware that have optimizations for solid fill
> > > > planes. This series aims to expose these capabilities to userspace as
> > > > some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
> > > > hardware composer HAL) that can be set by apps like the Android Gears
> > > > test app.
> > > >
> > > > In order to expose this capability to userspace, this series will:
> > > >
> > > > [...]
> > >
> > >
> > > Applied to drm-misc-next, thanks!
> >
> > Where are the IGT and userspace for this uAPI addition?
> 
> Indeed. I checked that there are uABI acks/reviews, but I didn't check
> these requirements. Frankly speaking, I thought that they were handled
> already, before giving the ack. How should we proceed? Should I land a
> revert?

Yes

Maxime
Abhinav Kumar Dec. 4, 2023, 5:51 p.m. UTC | #5
Hi Simon

On 12/3/2023 4:15 AM, Simon Ser wrote:
> On Saturday, December 2nd, 2023 at 22:41, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote:
> 
>> On Fri, 27 Oct 2023 15:32:50 -0700, Jessica Zhang wrote:
>>
>>> Some drivers support hardware that have optimizations for solid fill
>>> planes. This series aims to expose these capabilities to userspace as
>>> some compositors have a solid fill flag (ex. SOLID_COLOR in the Android
>>> hardware composer HAL) that can be set by apps like the Android Gears
>>> test app.
>>>
>>> In order to expose this capability to userspace, this series will:
>>>
>>> [...]
>>
>>
>> Applied to drm-misc-next, thanks!
> 
> Where are the IGT and userspace for this uAPI addition?

Yes, we made IGT changes to test and validate this. We will post them on 
the IGT dev list shortly and CC you.

We do not have a compositor change yet for this as we primarily used IGT 
to validate this.

Can we re-try to land this once IGT changes are accepted?

Thanks

Abhinav
Simon Ser Dec. 4, 2023, 5:57 p.m. UTC | #6
On Monday, December 4th, 2023 at 18:51, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote:

> > Where are the IGT and userspace for this uAPI addition?
> 
> Yes, we made IGT changes to test and validate this. We will post them on
> the IGT dev list shortly and CC you.
> 
> We do not have a compositor change yet for this as we primarily used IGT
> to validate this.

Yes, please post the IGT.

> Can we re-try to land this once IGT changes are accepted?

There will need to be a user-space implementation as well, since this is
a hard requirement for new uAPI [1]. Maybe I'll give this a go if I have
time.

[1]: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
Abhinav Kumar Dec. 4, 2023, 5:58 p.m. UTC | #7
On 12/4/2023 9:57 AM, Simon Ser wrote:
> On Monday, December 4th, 2023 at 18:51, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote:
> 
>>> Where are the IGT and userspace for this uAPI addition?
>>
>> Yes, we made IGT changes to test and validate this. We will post them on
>> the IGT dev list shortly and CC you.
>>
>> We do not have a compositor change yet for this as we primarily used IGT
>> to validate this.
> 
> Yes, please post the IGT.
> 
>> Can we re-try to land this once IGT changes are accepted?
> 
> There will need to be a user-space implementation as well, since this is
> a hard requirement for new uAPI [1]. Maybe I'll give this a go if I have
> time.
> 

Much appreciated.

> [1]: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements