mirror of https://gitee.com/openkylin/linux.git
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>
This commit is contained in:
parent
955e36d0b4
commit
11c9b6c628
|
@ -248,8 +248,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);
|
||||
}
|
||||
|
||||
|
|
Loading…
Reference in New Issue