redonkable/remarkable-linux
redonkable/remarkable-linux
1
0
Fork 0
Code Releases Activity

drm/i915: Tighting frontbuffer tracking around flips

Browse source 
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:
Daniel Vetter 2014-09-30 22:10:52 +02:00
parent 955e36d0b4
commit 11c9b6c628
1 changed files with 3 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
drivers/gpu/drm/i915/intel_frontbuffer.c
View file

@ -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);
}