From: Daniel Vetter <daniel@ffwll.ch>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Jessica Zhang <quic_jesszhan@quicinc.com>,
Daniel Vetter <daniel@ffwll.ch>,
freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
dri-devel@lists.freedesktop.org, robdclark@gmail.com,
seanpaul@chromium.org, swboyd@chromium.org,
quic_abhinavk@quicinc.com, contact@emersion.fr,
daniel.vetter@ffwll.ch, laurent.pinchart@ideasonboard.com,
ppaalanen@gmail.com, sebastian.wick@redhat.com,
wayland-devel@lists.freedesktop.org,
ville.syrjala@linux.intel.com
Subject: Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes
Date: Fri, 6 Jan 2023 19:41:28 +0100 [thread overview]
Message-ID: <Y7hrWDpg8msuefgZ@phenom.ffwll.local> (raw)
In-Reply-To: <CAA8EJppnAmN6+S-emEfXJEc1iVf+DjeLBmCQpGd-nRY2M2AAQQ@mail.gmail.com>
On Fri, Jan 06, 2023 at 05:43:23AM +0200, Dmitry Baryshkov wrote:
> On Fri, 6 Jan 2023 at 02:38, Jessica Zhang <quic_jesszhan@quicinc.com> wrote:
> >
> >
> >
> > On 1/5/2023 3:33 AM, Daniel Vetter wrote:
> > > On Wed, Jan 04, 2023 at 03:40:33PM -0800, Jessica Zhang wrote:
> > >> Introduce and add support for a solid_fill property. When the solid_fill
> > >> property is set, and the framebuffer is set to NULL, memory fetch will be
> > >> disabled.
> > >>
> > >> In addition, loosen the NULL FB checks within the atomic commit callstack
> > >> to allow a NULL FB when the solid_fill property is set and add FB checks
> > >> in methods where the FB was previously assumed to be non-NULL.
> > >>
> > >> Finally, have the DPU driver use drm_plane_state.solid_fill and instead of
> > >> dpu_plane_state.color_fill, and add extra checks in the DPU atomic commit
> > >> callstack to account for a NULL FB in cases where solid_fill is set.
> > >>
> > >> 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
> > >> app.
> > >>
> > >> Userspace can set the solid_fill property to a blob containing the
> > >> appropriate version number and solid fill color (in RGB323232 format) and
> > >> setting the framebuffer to NULL.
> > >>
> > >> Note: 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
> > >> creating additional versions of the drm_solid_fill struct.
> > >>
> > >> Changes in V2:
> > >> - Dropped SOLID_FILL_FORMAT property (Simon)
> > >> - Switched to implementing solid_fill property as a blob (Simon, Dmitry)
> > >> - 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)
> > >
> > > Now that this is a blob, I do wonder again whether it's not cleaner to set
> > > the blob as the FB pointer. Or create some kind other kind of special data
> > > source objects (because solid fill is by far not the only such thing).
> > >
> > > We'd still end up in special cases like when userspace that doesn't
> > > understand solid fill tries to read out such a framebuffer, but these
> > > cases already exist anyway for lack of priviledges.
> > >
> > > So I still think that feels like the more consistent way to integrate this
> > > feature. Which doesn't mean it has to happen like that, but the
> > > patches/cover letter should at least explain why we don't do it like this.
> >
> > Hi Daniel,
> >
> > IIRC we were facing some issues with this check [1] when trying to set
> > FB to a PROP_BLOB instead. Which is why we went with making it a
> > separate property instead. Will mention this in the cover letter.
>
> What kind of issues? Could you please describe them?
We switched from bitmask to enum style for prop types, which means it's
not possible to express with the current uapi a property which accepts
both an object or a blob.
Which yeah sucks a bit ...
But!
blob properties are kms objects (like framebuffers), so it should be
possible to stuff a blob into an object property as-is. Of course you need
to update the validation code to make sure we accept either an fb or a
blob for the internal representation. But that kind of split internally is
required no matter what I think.
-Daniel
>
> >
> > [1]
> > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/drm_property.c#L71
> >
> > Thanks,
> >
> > Jessica Zhang
> >
> > > -Daniel
> > >
> > >>
> > >> 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)
> > >>
> > >> Jessica Zhang (3):
> > >> drm: Introduce solid fill property for drm plane
> > >> drm: Adjust atomic checks for solid fill color
> > >> drm/msm/dpu: Use color_fill property for DPU planes
> > >>
> > >> drivers/gpu/drm/drm_atomic.c | 136 +++++++++++++---------
> > >> drivers/gpu/drm/drm_atomic_helper.c | 34 +++---
> > >> drivers/gpu/drm/drm_atomic_state_helper.c | 9 ++
> > >> drivers/gpu/drm/drm_atomic_uapi.c | 59 ++++++++++
> > >> drivers/gpu/drm/drm_blend.c | 17 +++
> > >> drivers/gpu/drm/drm_plane.c | 8 +-
> > >> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 +-
> > >> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 65 +++++++----
> > >> include/drm/drm_atomic_helper.h | 5 +-
> > >> include/drm/drm_blend.h | 1 +
> > >> include/drm/drm_plane.h | 62 ++++++++++
> > >> 11 files changed, 302 insertions(+), 103 deletions(-)
> > >>
> > >> --
> > >> 2.38.1
> > >>
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
>
>
>
> --
> With best wishes
> Dmitry
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2023-01-06 18:41 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-04 23:40 [RFC PATCH v3 0/3] Support for Solid Fill Planes Jessica Zhang
2023-01-04 23:40 ` [RFC PATCH v3 1/3] drm: Introduce solid fill property for drm plane Jessica Zhang
2023-01-05 1:50 ` Dmitry Baryshkov
2023-01-05 2:12 ` Dmitry Baryshkov
2023-01-18 18:57 ` Harry Wentland
2023-01-18 22:53 ` Jessica Zhang
2023-01-19 15:57 ` Harry Wentland
2023-01-19 16:24 ` Jessica Zhang
2023-01-19 16:27 ` Harry Wentland
2023-01-04 23:40 ` [RFC PATCH v3 2/3] drm: Adjust atomic checks for solid fill color Jessica Zhang
2023-01-05 1:57 ` Dmitry Baryshkov
2023-01-06 20:51 ` Jessica Zhang
2023-01-04 23:40 ` [RFC PATCH v3 3/3] drm/msm/dpu: Use color_fill property for DPU planes Jessica Zhang
2023-01-05 2:16 ` Dmitry Baryshkov
2023-01-06 20:57 ` [Freedreno] " Jessica Zhang
2023-01-06 21:56 ` Dmitry Baryshkov
2023-01-05 11:33 ` [RFC PATCH v3 0/3] Support for Solid Fill Planes Daniel Vetter
2023-01-06 0:37 ` Jessica Zhang
2023-01-06 3:43 ` Dmitry Baryshkov
2023-01-06 18:41 ` Daniel Vetter [this message]
2023-01-06 21:49 ` Dmitry Baryshkov
2023-01-07 0:33 ` Abhinav Kumar
2023-01-11 22:29 ` Daniel Vetter
2023-01-24 10:42 ` Simon Ser
2023-01-31 9:25 ` Pekka Paalanen
2023-01-31 10:06 ` Simon Ser
2023-01-31 11:13 ` Pekka Paalanen
2023-01-31 11:21 ` Simon Ser
2023-01-31 12:49 ` Pekka Paalanen
2023-02-02 2:06 ` Jessica Zhang
2023-02-02 8:55 ` Pekka Paalanen
2023-01-06 19:44 ` Jessica Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y7hrWDpg8msuefgZ@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=contact@emersion.fr \
--cc=daniel.vetter@ffwll.ch \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=ppaalanen@gmail.com \
--cc=quic_abhinavk@quicinc.com \
--cc=quic_jesszhan@quicinc.com \
--cc=robdclark@gmail.com \
--cc=seanpaul@chromium.org \
--cc=sebastian.wick@redhat.com \
--cc=swboyd@chromium.org \
--cc=ville.syrjala@linux.intel.com \
--cc=wayland-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox