2015-06-17 17:25 GMT-03:00 Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>: > On Wed, Jun 17, 2015 at 04:39:32PM -0300, Paulo Zanoni wrote: >> 2015-06-17 4:52 GMT-03:00 Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>: >> > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
