aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_frontbuffer.c
diff options
context:
space:
mode:
authorDaniel Vetter <daniel.vetter@ffwll.ch>2014-09-30 16:10:52 -0400
committerDaniel Vetter <daniel.vetter@ffwll.ch>2014-10-01 04:52:56 -0400
commit11c9b6c628c646894e6ef53f92cfd33a814ee553 (patch)
tree056f5daacaa32b9457b27837480097c00d564dc5 /drivers/gpu/drm/i915/intel_frontbuffer.c
parent955e36d0b4d3e29c9c8a865d166a42718aed302e (diff)
drm/i915: Tighting frontbuffer tracking around flips
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. Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Diffstat (limited to 'drivers/gpu/drm/i915/intel_frontbuffer.c')
-rw-r--r--drivers/gpu/drm/i915/intel_frontbuffer.c5
1 files changed, 3 insertions, 2 deletions
diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c b/drivers/gpu/drm/i915/intel_frontbuffer.c
index 7eb74a62117f..c5a312d218f7 100644
--- a/drivers/gpu/drm/i915/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
@@ -248,8 +248,9 @@ void intel_frontbuffer_flip_prepare(struct drm_device *dev,
248 struct drm_i915_private *dev_priv = dev->dev_private; 248 struct drm_i915_private *dev_priv = dev->dev_private;
249 249
250 mutex_lock(&dev_priv->fb_tracking.lock); 250 mutex_lock(&dev_priv->fb_tracking.lock);
251 dev_priv->fb_tracking.flip_bits 251 dev_priv->fb_tracking.flip_bits |= frontbuffer_bits;
252 |= frontbuffer_bits; 252 /* Remove stale busy bits due to the old buffer. */
253 dev_priv->fb_tracking.busy_bits &= ~frontbuffer_bits;
253 mutex_unlock(&dev_priv->fb_tracking.lock); 254 mutex_unlock(&dev_priv->fb_tracking.lock);
254} 255}
255 256