| Message ID | 1412107853-23964-1-git-send-email-daniel.vetter@ffwll.ch (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
2014-09-30 17:10 GMT-03:00 Daniel Vetter <daniel.vetter@ffwll.ch>: > So I think I've spotted a small gap in the frontbuffer tracking > while discussing the logic with Paulo on irc: > > 1. Userspace schedules gpu rendering to the current frontbuffer. > This gets tracked in dev_priv->fb_tracking.busy_bits. > > 2. We pageflip a fully rendered buffer before the frontbuffer > rendering completes. > > 3. The request retiring will never clear busy_bits (since at retire > time the old frontbuffer won't have obj->frontbuffer_bits set), so > these bits now are stuck until someone again does a bit of frontbuffer > tracking. > > If we clear stale busy_bits in flip_prepare this gap is closed. > > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> > --- > drivers/gpu/drm/i915/intel_frontbuffer.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c b/drivers/gpu/drm/i915/intel_frontbuffer.c > index f74744c091cb..969af6e7b634 100644 > --- a/drivers/gpu/drm/i915/intel_frontbuffer.c > +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c > @@ -246,8 +246,9 @@ void intel_frontbuffer_flip_prepare(struct drm_device *dev, > struct drm_i915_private *dev_priv = dev->dev_private; > > mutex_lock(&dev_priv->fb_tracking.lock); > - dev_priv->fb_tracking.flip_bits > - |= frontbuffer_bits; > + dev_priv->fb_tracking.flip_bits |= frontbuffer_bits; > + /* Remove stale busy bits due to the old buffer. */ > + dev_priv->fb_tracking.busy_bits &= ~frontbuffer_bits; > mutex_unlock(&dev_priv->fb_tracking.lock); > } > > -- > 2.1.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c b/drivers/gpu/drm/i915/intel_frontbuffer.c index f74744c091cb..969af6e7b634 100644 --- a/drivers/gpu/drm/i915/intel_frontbuffer.c +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c @@ -246,8 +246,9 @@ void intel_frontbuffer_flip_prepare(struct drm_device *dev, struct drm_i915_private *dev_priv = dev->dev_private; mutex_lock(&dev_priv->fb_tracking.lock); - dev_priv->fb_tracking.flip_bits - |= frontbuffer_bits; + dev_priv->fb_tracking.flip_bits |= frontbuffer_bits; + /* Remove stale busy bits due to the old buffer. */ + dev_priv->fb_tracking.busy_bits &= ~frontbuffer_bits; mutex_unlock(&dev_priv->fb_tracking.lock); }
So I think I've spotted a small gap in the frontbuffer tracking while discussing the logic with Paulo on irc: 1. Userspace schedules gpu rendering to the current frontbuffer. This gets tracked in dev_priv->fb_tracking.busy_bits. 2. We pageflip a fully rendered buffer before the frontbuffer rendering completes. 3. The request retiring will never clear busy_bits (since at retire time the old frontbuffer won't have obj->frontbuffer_bits set), so these bits now are stuck until someone again does a bit of frontbuffer tracking. If we clear stale busy_bits in flip_prepare this gap is closed. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> --- drivers/gpu/drm/i915/intel_frontbuffer.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)