From: Daniel Vetter <daniel@ffwll.ch>
To: Rob Clark <robdclark@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
freedreno <freedreno@lists.freedesktop.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
"Thomas Hellstrom" <thomas@shipmail.org>,
"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"Lukasz Spintzyk" <lukasz.spintzyk@displaylink.com>,
"Deepak Singh Rawat" <drawat@vmware.com>,
"Gustavo Padovan" <gustavo@padovan.org>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Sean Paul" <seanpaul@chromium.org>,
"David Airlie" <airlied@linux.ie>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Daniel Vetter" <daniel@ffwll.ch>
Subject: Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb
Date: Wed, 4 Apr 2018 14:18:43 +0200 [thread overview]
Message-ID: <20180404121843.GL3881@phenom.ffwll.local> (raw)
In-Reply-To: <CAF6AEGtowtdQmUxNF_F3B3Yow+PDB43Eb0VJ_ZqGKpVw1iZBzA@mail.gmail.com>
On Wed, Apr 04, 2018 at 07:35:58AM -0400, Rob Clark wrote:
> On Wed, Apr 4, 2018 at 6:21 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Wed, Apr 04, 2018 at 12:03:00PM +0200, Daniel Vetter wrote:
> >> On Tue, Apr 03, 2018 at 06:42:23PM -0400, Rob Clark wrote:
> >> > Add an atomic helper to implement dirtyfb support. This is needed to
> >> > support DSI command-mode panels with x11 userspace (ie. when we can't
> >> > rely on pageflips to trigger a flush to the panel).
> >> >
> >> > To signal to the driver that the async atomic update needs to
> >> > synchronize with fences, even though the fb didn't change, the
> >> > drm_atomic_state::dirty flag is added.
> >> >
> >> > Signed-off-by: Rob Clark <robdclark@gmail.com>
> >> > ---
> >> > Background: there are a number of different folks working on getting
> >> > upstream kernel working on various different phones/tablets with qcom
> >> > SoC's.. many of them have command mode panels, so we kind of need a
> >> > way to support the legacy dirtyfb ioctl for x11 support.
> >> >
> >> > I know there is work on a proprer non-legacy atomic property for
> >> > userspace to communicate dirty-rect(s) to the kernel, so this can
> >> > be improved from triggering a full-frame flush once that is in
> >> > place. But we kinda needa a stop-gap solution.
> >> >
> >> > I had considered an in-driver solution for this, but things get a
> >> > bit tricky if userspace ands up combining dirtyfb ioctls with page-
> >> > flips, because we need to synchronize setting various CTL.FLUSH bits
> >> > with setting the CTL.START bit. (ie. really all we need to do for
> >> > cmd mode panels is bang CTL.START, but is this ends up racing with
> >> > pageflips setting FLUSH bits, then bad things.) The easiest soln
> >> > is to wrap this up as an atomic commit and rely on the worker to
> >> > serialize things. Hence adding an atomic dirtyfb helper.
> >> >
> >> > I guess at least the helper, with some small addition to translate
> >> > and pass-thru the dirty rect(s) is useful to the final atomic dirty-
> >> > rect property solution. Depending on how far off that is, a stop-
> >> > gap solution could be useful.
> >> >
> >> > drivers/gpu/drm/drm_atomic_helper.c | 66 +++++++++++++++++++++++++++++++++++++
> >> > drivers/gpu/drm/msm/msm_atomic.c | 5 ++-
> >> > drivers/gpu/drm/msm/msm_fb.c | 1 +
> >> > include/drm/drm_atomic_helper.h | 4 +++
> >> > include/drm/drm_plane.h | 9 +++++
> >> > 5 files changed, 84 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> >> > index c35654591c12..a578dc681b27 100644
> >> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> > @@ -3504,6 +3504,7 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
> >> > if (state->fb)
> >> > drm_framebuffer_get(state->fb);
> >> >
> >> > + state->dirty = false;
> >> > state->fence = NULL;
> >> > state->commit = NULL;
> >> > }
> >> > @@ -3847,6 +3848,71 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
> >> > }
> >> > EXPORT_SYMBOL(drm_atomic_helper_legacy_gamma_set);
> >> >
> >> > +/**
> >> > + * drm_atomic_helper_dirtyfb - helper for dirtyfb
> >> > + *
> >> > + * A helper to implement drm_framebuffer_funcs::dirty
> >> > + */
> >> > +int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
> >> > + struct drm_file *file_priv, unsigned flags,
> >> > + unsigned color, struct drm_clip_rect *clips,
> >> > + unsigned num_clips)
> >> > +{
> >> > + struct drm_modeset_acquire_ctx ctx;
> >> > + struct drm_atomic_state *state;
> >> > + struct drm_plane *plane;
> >> > + int ret = 0;
> >> > +
> >> > + /*
> >> > + * When called from ioctl, we are interruptable, but not when
> >> > + * called internally (ie. defio worker)
> >> > + */
> >> > + drm_modeset_acquire_init(&ctx,
> >> > + file_priv ? DRM_MODESET_ACQUIRE_INTERRUPTIBLE : 0);
> >> > +
> >> > + state = drm_atomic_state_alloc(fb->dev);
> >> > + if (!state) {
> >> > + ret = -ENOMEM;
> >> > + goto out;
> >> > + }
> >> > + state->acquire_ctx = &ctx;
> >> > +
> >> > +retry:
> >> > + drm_for_each_plane(plane, fb->dev) {
> >> > + struct drm_plane_state *plane_state;
> >> > +
> >> > + if (plane->state->fb != fb)
> >> > + continue;
> >> > +
> >> > + plane_state = drm_atomic_get_plane_state(state, plane);
> >> > + if (IS_ERR(plane_state)) {
> >> > + ret = PTR_ERR(plane_state);
> >> > + goto out;
> >> > + }
> >> > +
> >> > + plane_state->dirty = true;
> >> > + }
> >> > +
> >> > + ret = drm_atomic_nonblocking_commit(state);
> >> > +
> >> > +out:
> >> > + if (ret == -EDEADLK) {
> >> > + drm_atomic_state_clear(state);
> >> > + ret = drm_modeset_backoff(&ctx);
> >> > + if (!ret)
> >> > + goto retry;
> >> > + }
> >> > +
> >> > + drm_atomic_state_put(state);
> >> > +
> >> > + drm_modeset_drop_locks(&ctx);
> >> > + drm_modeset_acquire_fini(&ctx);
> >> > +
> >> > + return ret;
> >> > +
> >> > +}
> >> > +EXPORT_SYMBOL(drm_atomic_helper_dirtyfb);
> >> > +
> >> > /**
> >> > * __drm_atomic_helper_private_duplicate_state - copy atomic private state
> >> > * @obj: CRTC object
> >> > diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
> >> > index bf5f8c39f34d..bb55a048e98b 100644
> >> > --- a/drivers/gpu/drm/msm/msm_atomic.c
> >> > +++ b/drivers/gpu/drm/msm/msm_atomic.c
> >> > @@ -201,7 +201,10 @@ int msm_atomic_commit(struct drm_device *dev,
> >> > * Figure out what fence to wait for:
> >> > */
> >> > for_each_oldnew_plane_in_state(state, plane, old_plane_state, new_plane_state, i) {
> >> > - if ((new_plane_state->fb != old_plane_state->fb) && new_plane_state->fb) {
> >> > + bool sync_fb = new_plane_state->fb &&
> >> > + ((new_plane_state->fb != old_plane_state->fb) ||
> >> > + new_plane_state->dirty);
> >>
> >> Why do you have this optimization even here? Imo flipping to the same fb
> >> should result in the fb getting fully uploaded, whether you're doing a
> >> legacy page_flip, and atomic one or just a plane update.
> >>
> >> Iirc some userspace does use that as essentially a full-plane frontbuffer
> >> rendering flush already. IOW I don't think we need your
> >> plane_state->dirty, it's implied to always be true - why would userspace
> >> do a flip otherwise?
> >>
> >> The helper itself to map dirtyfb to a nonblocking atomic commit looks
> >> reasonable, but misses a bunch of the trickery discussed with Noralf and
> >> others I think.
> >
> > Ok, I've done some history digging:
> >
> > - i915 and nouveau unconditionally wait for fences, even for same-fb
> > flips.
> > - no idea what amdgpu and vmwgfx are doing, they're not using
> > plane_state->fence for implicit fences.
> > - most arm-soc drivers do have this "optimization" in their code, and it
> > even managed to get into the new drm_gem_fb_prepare_fb helper (which I
> > reviewed, or well claimed to have ... oops). Afaict it goes back to the
> > original msm atomic code, and was then dutifully copypasted all over the
> > place.
> >
> > If folks are ok I'll do a patch series to align drivers with i915/nouveau.
> > Well, any driver using reservation_object_get_excl_rcu +
> > drm_atomic_set_fence_for_plane combo, since amdgpu and vmwgfx don't I have
> > no idea what they're doing or whether they might have the same bug.
>
> if you do a patch series, I think do it the other way around and align
> to msm ;-)
The problem is that this would break i915 userspace afaik, which I think
is using a frontbuffer page flip to flush out uploads (and re-enable self
refresh and stuff like that). So that we can't do easily.
> I think otherwise we could end up stalling while x11 does front buffer
> rendering for something unrelated (maybe I was hitting that with
> cursor updates?)
Why would you stall on something unrelated if we unconditionally fish out
the fence? Especially cursor rendering isn't done through the gpu at all
afaik.
-Daniel
>
> BR,
> -R
>
> > From looking at at least the various prepare_fb callbacks I don't see any
> > other drivers doing funny stuff around implicit fences.
> > -Daniel
> >
> >> > + if (sync_fb) {
> >> > struct drm_gem_object *obj = msm_framebuffer_bo(new_plane_state->fb, 0);
> >> > struct msm_gem_object *msm_obj = to_msm_bo(obj);
> >> > struct dma_fence *fence = reservation_object_get_excl_rcu(msm_obj->resv);
> >> > diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
> >> > index 0e0c87252ab0..a5d882a34a33 100644
> >> > --- a/drivers/gpu/drm/msm/msm_fb.c
> >> > +++ b/drivers/gpu/drm/msm/msm_fb.c
> >> > @@ -62,6 +62,7 @@ static void msm_framebuffer_destroy(struct drm_framebuffer *fb)
> >> > static const struct drm_framebuffer_funcs msm_framebuffer_funcs = {
> >> > .create_handle = msm_framebuffer_create_handle,
> >> > .destroy = msm_framebuffer_destroy,
> >> > + .dirty = drm_atomic_helper_dirtyfb,
> >> > };
> >> >
> >> > #ifdef CONFIG_DEBUG_FS
> >> > diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
> >> > index 26aaba58d6ce..9b7a95c2643d 100644
> >> > --- a/include/drm/drm_atomic_helper.h
> >> > +++ b/include/drm/drm_atomic_helper.h
> >> > @@ -183,6 +183,10 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
> >> > u16 *red, u16 *green, u16 *blue,
> >> > uint32_t size,
> >> > struct drm_modeset_acquire_ctx *ctx);
> >> > +int drm_atomic_helper_dirtyfb(struct drm_framebuffer *fb,
> >> > + struct drm_file *file_priv, unsigned flags,
> >> > + unsigned color, struct drm_clip_rect *clips,
> >> > + unsigned num_clips);
> >> > void __drm_atomic_helper_private_obj_duplicate_state(struct drm_private_obj *obj,
> >> > struct drm_private_state *state);
> >> >
> >> > diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> >> > index f7bf4a48b1c3..296fa22bda7a 100644
> >> > --- a/include/drm/drm_plane.h
> >> > +++ b/include/drm/drm_plane.h
> >> > @@ -76,6 +76,15 @@ struct drm_plane_state {
> >> > */
> >> > struct drm_framebuffer *fb;
> >> >
> >> > + /**
> >> > + * @dirty:
> >> > + *
> >> > + * Flag that indicates the fb contents have changed even though the
> >> > + * fb has not. This is mostly a stop-gap solution until we have
> >> > + * atomic dirty-rect(s) property.
> >> > + */
> >> > + bool dirty;
> >> > +
> >> > /**
> >> > * @fence:
> >> > *
> >> > --
> >> > 2.14.3
> >> >
> >>
> >> --
> >> Daniel Vetter
> >> Software Engineer, Intel Corporation
> >> http://blog.ffwll.ch
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2018-04-04 12:18 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-03 22:42 [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb Rob Clark
2018-04-04 6:58 ` Daniel Vetter
2018-04-04 8:22 ` Thomas Hellstrom
2018-04-04 8:43 ` Daniel Vetter
2018-04-04 9:10 ` Thomas Hellstrom
2018-04-04 9:56 ` Daniel Vetter
2018-04-04 10:28 ` Thomas Hellstrom
2018-04-04 11:46 ` Thomas Hellstrom
2018-04-04 12:13 ` Daniel Vetter
2018-04-04 11:40 ` Rob Clark
2018-04-04 12:16 ` Daniel Vetter
2018-04-04 13:24 ` Rob Clark
2018-04-04 13:28 ` Daniel Vetter
2018-04-05 13:30 ` Thomas Hellstrom
2018-04-05 13:35 ` Daniel Vetter
2018-04-06 0:19 ` Deepak Singh Rawat
2018-04-06 0:36 ` Rob Clark
2018-04-04 10:03 ` Daniel Vetter
2018-04-04 10:21 ` Daniel Vetter
2018-04-04 10:36 ` Maarten Lankhorst
2018-04-04 11:37 ` Rob Clark
2018-04-04 11:49 ` Maarten Lankhorst
2018-04-04 12:05 ` Rob Clark
2018-04-04 12:23 ` Maarten Lankhorst
2018-04-04 12:26 ` Daniel Vetter
2018-04-04 12:28 ` Maarten Lankhorst
2018-04-04 13:26 ` Rob Clark
2018-04-04 11:35 ` Rob Clark
2018-04-04 12:18 ` Daniel Vetter [this message]
2018-04-04 17:41 ` Noralf Trønnes
2018-04-04 17:56 ` Daniel Vetter
2018-04-04 18:52 ` Noralf Trønnes
2018-04-04 19:19 ` Rob Clark
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=20180404121843.GL3881@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@linux.ie \
--cc=drawat@vmware.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=gustavo@padovan.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz.spintzyk@displaylink.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=robdclark@gmail.com \
--cc=seanpaul@chromium.org \
--cc=thomas@shipmail.org \
--cc=ville.syrjala@linux.intel.com \
/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