[Intel-gfx] [PATCH 2/3] drm/i915: add the FBC mutex

[Paulo Zanoni]

2015-06-17 17:25 GMT-03:00 Chris Wilson <chris at chris-wilson.co.uk>:
> On Wed, Jun 17, 2015 at 04:39:32PM -0300, Paulo Zanoni wrote:
>> 2015-06-17 4:52 GMT-03:00 Chris Wilson <chris at chris-wilson.co.uk>:
>> > These busy bits are locked higher up. In fact I want to migrate that
>> > lock to a spinlock, which has implications here. I didn't see anything
>> > that mandated using a mutex for fbc, right?
>>
>> I didn't understand your idea. You want to replace the whole FBC mutex
>> for a spinlock? Why?
>
> I want to replace the frontbuffer mutex with a spinlock. You are
> inserting a mutex under my intended spinlock, which blows my idea of
> trying to speed up the normal operations.

As far as I can see, fb_tracking.lock is not held when we call
intel_fbc_flush and intel_fbc_invalidate. So your change could be
possible now.

>
>> Please notice that we have dev_priv->fbc.busy_bits and also
>> dev_priv->fb_tracking.busy_bits. The FBC busy bits are only handled in
>> the intel_fbc.c functions. So maybe you want the spilock around the
>> fb_tracking ones? That wouldn't require changing the FBC mutex to a
>> spinlock, and it could be done today.
>
> Somehow I need to avoid the mutex here, so kicking off the fbc
> enable/disable needs to be lockless (or spinlocked at most). Of course,
> if that is not practical, I will just have to live with not converting
> the higher mutex into the spinlock.

I think we will reach a point where this doable. After we migrate some
of the FBC stuff to pipe_config, and make FBC fully rely on the
frontbuffer tracking infrastructure (i.e., no intel_fbc_something
calls from intel_display.c), the FBC update/flush/invalidate functions
will get much simpler, not needing to handle stolen memory, etc.
Another current problem I can see is the delayed work stuff we have,
but Daniel is already requesting to simplify/remove it, so that might
die too. I'll try to keep the spinlock in mind when thinking about
this. We can always try :). I hope you're fine with the idea of just
converting the mutex to a spinlock later.

> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre



-- 
Paulo Zanoni