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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
