public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Flush outstanding unpin tasks before pageflipping
Date: Fri, 28 Sep 2012 13:07:59 +0100	[thread overview]
Message-ID: <453bf0$5t4oh8@azsmga001.ch.intel.com> (raw)
In-Reply-To: <20120928120501.GO19732@intel.com>

[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]

On Fri, 28 Sep 2012 15:05:01 +0300, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Fri, Sep 28, 2012 at 12:29:56PM +0100, Chris Wilson wrote:
> > If we accumulate unpin tasks because we are pageflipping faster than the
> > system can schedule its workers, we can effectively create a
> > pin-leak. The solution taken here is to limit the number of unpin tasks
> > we have per-crtc and to flush those outstanding tasks if we accumulate
> > too many. This should prevent any jitter in the normal case, and also
> > prevent the hang if we should run too fast.
> > 
> > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46991
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c |   20 +++++++++++++++-----
> >  drivers/gpu/drm/i915/intel_drv.h     |    4 +++-
> >  2 files changed, 18 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 04407fd..14f1b51 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -6310,14 +6310,19 @@ static void intel_unpin_work_fn(struct work_struct *__work)
> >  {
> >  	struct intel_unpin_work *work =
> >  		container_of(__work, struct intel_unpin_work, work);
> > +	struct drm_device *dev = work->crtc->dev;
> >  
> > -	mutex_lock(&work->dev->struct_mutex);
> > +	mutex_lock(&dev->struct_mutex);
> >  	intel_unpin_fb_obj(work->old_fb_obj);
> >  	drm_gem_object_unreference(&work->pending_flip_obj->base);
> >  	drm_gem_object_unreference(&work->old_fb_obj->base);
> >  
> > -	intel_update_fbc(work->dev);
> > -	mutex_unlock(&work->dev->struct_mutex);
> > +	intel_update_fbc(dev);
> > +	mutex_unlock(&dev->struct_mutex);
> > +
> > +	BUG_ON(atomic_read(&to_intel_crtc(work->crtc)->unpin_work_count) == 0);
> > +	atomic_dec(&to_intel_crtc(work->crtc)->unpin_work_count);
> 
> AFAICS you always have struct_mutex locked in the relevant functions,
> so no need for an atomic variable.

It's not in every case, since we need to do the flush without holding
the lock, we have the choice of making this variable atomic, or taking
and dropping the lock. Obviously I choose the former.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2012-09-28 12:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-28 11:29 [PATCH] drm/i915: Flush outstanding unpin tasks before pageflipping Chris Wilson
2012-09-28 12:05 ` Ville Syrjälä
2012-09-28 12:07   ` Chris Wilson [this message]
2012-09-28 12:20     ` Ville Syrjälä
  -- strict thread matches above, loose matches on Subject: below --
2012-11-01  9:26 Chris Wilson
2012-11-01 15:07 ` Jesse Barnes
2012-11-01 15:18   ` Chris Wilson
2012-11-01 15:29     ` Daniel Vetter
2012-11-01 15:34       ` Jesse Barnes
2012-11-01 15:52         ` Chris Wilson
2012-11-01 16:04           ` Jesse Barnes
2012-11-01 16:20             ` Chris Wilson
2012-11-01 16:52               ` Tvrtko Ursulin
2012-11-01 16:58                 ` Jesse Barnes
2012-11-05 11:36                   ` Simon Farnsworth
2012-11-02 21:31                 ` Eric Anholt
2012-11-20 16:15 ` Daniel Vetter

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='453bf0$5t4oh8@azsmga001.ch.intel.com' \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@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