[Intel-gfx] [PATCH 61/70] drm/i915: Make fb_tracking.lock a spinlock

Chris Wilson chris at chris-wilson.co.uk
Tue Apr 14 08:05:48 PDT 2015


On Tue, Apr 14, 2015 at 03:52:09PM +0100, Tvrtko Ursulin wrote:
> >  	/* Delay flushing when rings are still busy.*/
> >-	mutex_lock(&dev_priv->fb_tracking.lock);
> >+	spin_lock(&dev_priv->fb_tracking.lock);
> >  	frontbuffer_bits &= ~dev_priv->fb_tracking.busy_bits;
> >-	mutex_unlock(&dev_priv->fb_tracking.lock);
> >+	spin_unlock(&dev_priv->fb_tracking.lock);
> 
> Looks like you could just remove the lock here in process.

...as in we are always protected by struct_mutex? I think Daniel was
planning for a future where that was guaranteed.

Anyway my v2 patch does:

void __intel_fb_obj_invalidate(struct drm_i915_gem_object *obj,
                               struct intel_engine_cs *ring,
                               enum fb_op_origin origin);

static inline void intel_fb_obj_invalidate(struct drm_i915_gem_object *obj,
                                           struct intel_engine_cs *ring,
                                           enum fb_op_origin origin)
{
        if (!obj->frontbuffer_bits || !obj->pin_display)
                return;

        __intel_fb_obj_invalidate(obj, ring, origin);
}


As the function call overhead itself was annoying me in the execbuffer
profiles.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list