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>,
Rob Clark <robdclark@chromium.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@linux.ie>,
open list <linux-kernel@vger.kernel.org>,
Matthew Brost <matthew.brost@intel.com>,
Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [RFC 2/3] drm/atomic: Call dma_fence_boost() when we've missed a vblank
Date: Tue, 1 Jun 2021 16:18:52 +0200 [thread overview]
Message-ID: <YLZBzKlb7xpJaG4+@phenom.ffwll.local> (raw)
In-Reply-To: <CAF6AEGv470U7fujLrJOE8fJh1o-BW3=mOpKJ45FFz=Xb8Q0D6A@mail.gmail.com>
On Sun, May 30, 2021 at 07:33:57AM -0700, Rob Clark wrote:
> On Thu, May 20, 2021 at 9:29 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Wed, May 19, 2021 at 11:38:53AM -0700, Rob Clark wrote:
> > > From: Rob Clark <robdclark@chromium.org>
> > >
> > > Signed-off-by: Rob Clark <robdclark@chromium.org>
> > > ---
> > > drivers/gpu/drm/drm_atomic_helper.c | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 560aaecba31b..fe10fc2e7f86 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -1435,11 +1435,15 @@ int drm_atomic_helper_wait_for_fences(struct drm_device *dev,
> > > int i, ret;
> > >
> > > for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> > > + u64 vblank_count;
> > > +
> > > if (!new_plane_state->fence)
> > > continue;
> > >
> > > WARN_ON(!new_plane_state->fb);
> > >
> > > + vblank_count = drm_crtc_vblank_count(new_plane_state->crtc);
> > > +
> > > /*
> > > * If waiting for fences pre-swap (ie: nonblock), userspace can
> > > * still interrupt the operation. Instead of blocking until the
> > > @@ -1449,6 +1453,13 @@ int drm_atomic_helper_wait_for_fences(struct drm_device *dev,
> > > if (ret)
> > > return ret;
> > >
> > > + /*
> > > + * Check if we've missed a vblank while waiting, and if we have
> > > + * signal the fence that it's signaler should be boosted
> > > + */
> > > + if (vblank_count != drm_crtc_vblank_count(new_plane_state->crtc))
> > > + dma_fence_boost(new_plane_state->fence);
> >
> > I think we should do a lot better here:
> > - maybe only bother doing this for single-crtc updates, and only if
> > modeset isn't set. No one else cares about latency.
> >
> > - We should boost _right_ when we've missed the frame, so I think we
> > should have a _timeout wait here that guesstimates when the vblank is
> > over (might need to throw in a vblank wait if we missed) and then boost
> > immediately. Not wait a bunch of frames (worst case) until we finally
> > decide to boost.
>
> I was thinking about this a bit more.. How about rather than calling
> some fence->op->boost() type thing when we are about to miss a vblank
> (IMO that is also already too late), we do something more like
> fence->ops->set_deadline() before we even wait?
Hm yeah that sounds like a clean idea.
Even more, why not add the deadline/waiter information to the callback
we're adding? That way drivers can inspect it whenever they feel like and
don't have to duplicate the tracking. And it's probably easier to
tune/adjust to the myriads of use-cases (flip target miss, userspace wait,
wakeup boost maybe too ...).
I like this direction a lot more than what we discussed with post-miss
hints thus far.
> It's probably a bit impossible for a gpu driver to really predict how
> long some rendering will take, but other cases like video decoder are
> somewhat more predictable.. the fence provider could predict given the
> remaining time until the deadline what clk rates are required to get
> you there.
Well if we do have a deadline the driver can note that in its scheduler
and arm a driver to kick the clocks. Or maybe use past history to do this
upfront.
-Daniel
>
> BR,
> -R
>
>
> >
> > Otherwise I really like this, I think it's about the only real reason i915
> > isn't using atomic helpers.
> >
> > Also adding Matt B for this topic.
> > -Daniel
> >
> > > +
> > > dma_fence_put(new_plane_state->fence);
> > > new_plane_state->fence = NULL;
> > > }
> > > --
> > > 2.30.2
> > >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Rob Clark <robdclark@gmail.com>
Cc: Rob Clark <robdclark@chromium.org>,
Matthew Brost <matthew.brost@intel.com>,
David Airlie <airlied@linux.ie>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
open list <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
freedreno <freedreno@lists.freedesktop.org>
Subject: Re: [RFC 2/3] drm/atomic: Call dma_fence_boost() when we've missed a vblank
Date: Tue, 1 Jun 2021 16:18:52 +0200 [thread overview]
Message-ID: <YLZBzKlb7xpJaG4+@phenom.ffwll.local> (raw)
In-Reply-To: <CAF6AEGv470U7fujLrJOE8fJh1o-BW3=mOpKJ45FFz=Xb8Q0D6A@mail.gmail.com>
On Sun, May 30, 2021 at 07:33:57AM -0700, Rob Clark wrote:
> On Thu, May 20, 2021 at 9:29 AM Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > On Wed, May 19, 2021 at 11:38:53AM -0700, Rob Clark wrote:
> > > From: Rob Clark <robdclark@chromium.org>
> > >
> > > Signed-off-by: Rob Clark <robdclark@chromium.org>
> > > ---
> > > drivers/gpu/drm/drm_atomic_helper.c | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 560aaecba31b..fe10fc2e7f86 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -1435,11 +1435,15 @@ int drm_atomic_helper_wait_for_fences(struct drm_device *dev,
> > > int i, ret;
> > >
> > > for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> > > + u64 vblank_count;
> > > +
> > > if (!new_plane_state->fence)
> > > continue;
> > >
> > > WARN_ON(!new_plane_state->fb);
> > >
> > > + vblank_count = drm_crtc_vblank_count(new_plane_state->crtc);
> > > +
> > > /*
> > > * If waiting for fences pre-swap (ie: nonblock), userspace can
> > > * still interrupt the operation. Instead of blocking until the
> > > @@ -1449,6 +1453,13 @@ int drm_atomic_helper_wait_for_fences(struct drm_device *dev,
> > > if (ret)
> > > return ret;
> > >
> > > + /*
> > > + * Check if we've missed a vblank while waiting, and if we have
> > > + * signal the fence that it's signaler should be boosted
> > > + */
> > > + if (vblank_count != drm_crtc_vblank_count(new_plane_state->crtc))
> > > + dma_fence_boost(new_plane_state->fence);
> >
> > I think we should do a lot better here:
> > - maybe only bother doing this for single-crtc updates, and only if
> > modeset isn't set. No one else cares about latency.
> >
> > - We should boost _right_ when we've missed the frame, so I think we
> > should have a _timeout wait here that guesstimates when the vblank is
> > over (might need to throw in a vblank wait if we missed) and then boost
> > immediately. Not wait a bunch of frames (worst case) until we finally
> > decide to boost.
>
> I was thinking about this a bit more.. How about rather than calling
> some fence->op->boost() type thing when we are about to miss a vblank
> (IMO that is also already too late), we do something more like
> fence->ops->set_deadline() before we even wait?
Hm yeah that sounds like a clean idea.
Even more, why not add the deadline/waiter information to the callback
we're adding? That way drivers can inspect it whenever they feel like and
don't have to duplicate the tracking. And it's probably easier to
tune/adjust to the myriads of use-cases (flip target miss, userspace wait,
wakeup boost maybe too ...).
I like this direction a lot more than what we discussed with post-miss
hints thus far.
> It's probably a bit impossible for a gpu driver to really predict how
> long some rendering will take, but other cases like video decoder are
> somewhat more predictable.. the fence provider could predict given the
> remaining time until the deadline what clk rates are required to get
> you there.
Well if we do have a deadline the driver can note that in its scheduler
and arm a driver to kick the clocks. Or maybe use past history to do this
upfront.
-Daniel
>
> BR,
> -R
>
>
> >
> > Otherwise I really like this, I think it's about the only real reason i915
> > isn't using atomic helpers.
> >
> > Also adding Matt B for this topic.
> > -Daniel
> >
> > > +
> > > dma_fence_put(new_plane_state->fence);
> > > new_plane_state->fence = NULL;
> > > }
> > > --
> > > 2.30.2
> > >
> >
> > --
> > 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:[~2021-06-01 14:19 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-19 18:38 [RFC 0/3] dma-fence: Add a "boost" mechanism Rob Clark
2021-05-19 18:38 ` Rob Clark
2021-05-19 18:38 ` [RFC 1/3] dma-fence: Add boost fence op Rob Clark
2021-05-19 18:38 ` Rob Clark
2021-05-20 6:46 ` Christian König
2021-05-20 6:46 ` Christian König
2021-05-20 14:07 ` Rob Clark
2021-05-20 14:07 ` Rob Clark
2021-05-20 14:11 ` Christian König
2021-05-20 14:11 ` Christian König
2021-05-20 14:54 ` Rob Clark
2021-05-20 14:54 ` Rob Clark
2021-05-20 16:01 ` [Linaro-mm-sig] " Christian König
2021-05-20 16:34 ` Daniel Vetter
2021-05-20 16:34 ` Daniel Vetter
2021-05-20 16:40 ` Christian König
2021-05-20 17:08 ` Daniel Vetter
2021-05-20 17:08 ` Daniel Vetter
2021-05-21 7:43 ` Christian König
2021-05-21 7:43 ` Christian König
2021-05-21 14:21 ` Daniel Vetter
2021-05-21 14:21 ` Daniel Vetter
2021-05-20 16:25 ` Daniel Vetter
2021-05-20 16:25 ` Daniel Vetter
2021-05-19 18:38 ` [RFC 2/3] drm/atomic: Call dma_fence_boost() when we've missed a vblank Rob Clark
2021-05-19 18:38 ` Rob Clark
2021-05-20 16:29 ` Daniel Vetter
2021-05-20 16:29 ` Daniel Vetter
2021-05-30 14:33 ` Rob Clark
2021-05-30 14:33 ` Rob Clark
2021-06-01 14:18 ` Daniel Vetter [this message]
2021-06-01 14:18 ` Daniel Vetter
2021-06-01 15:46 ` Rob Clark
2021-06-01 15:46 ` Rob Clark
2021-06-01 16:11 ` Daniel Vetter
2021-06-01 16:11 ` Daniel Vetter
2021-05-19 18:38 ` [RFC 3/3] drm/msm: Wire up gpu boost Rob Clark
2021-05-19 18:38 ` 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=YLZBzKlb7xpJaG4+@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=robdclark@chromium.org \
--cc=robdclark@gmail.com \
--cc=tzimmermann@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.