On Wed, Jun 18, 2014 at 11:28:09PM +0200, Daniel Vetter wrote: > So from just a quick look we seem to have enough information to > accurately figure out whether a given gem bo is used as a frontbuffer > and where exactly: We have obj->pin_count as a first check with no > false negatives and only negligible false positives. And then we can > just walk the modeset objects and figure out where exactly a buffer is > used as scanout. > > Except that we can't due to locking order: If we already hold > dev->struct_mutex we can't acquire any modeset locks, so could > potential chase freed pointers and other evil stuff. > > So we need something else. For that introduce a new set of bits > obj->frontbuffer_bits to track where a buffer object is used. That we > can then chase without grabbing any modeset locks. > > Of course the consumers of this (DRRS, PSR, FBC, ...) still need to be > able to do their magic both when called from modeset and from gem > code. But that can be easily achieved by adding locks for these > specific subsystems which always nest within either kms or gem > locking. > > This patch just adds the relevant update code to all places. > > Note that if we ever support multi-planar scanout targets then we need > one frontbuffer tracking bit per attachment point that we expose to > userspace. > > v2: > - Fix more oopsen. Oops. > - WARN if we leak obj->frontbuffer_bits when freeing a gem buffer. Fix > the bugs this brought to light. > - s/update_frontbuffer_bits/update_fb_bits/. More consistent with the > fb tracking functions (fb for gem object, frontbuffer for raw bits). > And the function name was way too long. > > v3: Size obj->frontbuffer_bits correctly so that all pipes fit in. > > v4: Don't update fb bits in set_base on failure. Noticed by Chris. > > v5: s/i915_gem_update_fb_bits/i915_gem_track_fb/ Also remove a few > local enum pipe variables which are now no longer needed to make the > function arguments no drop over the 80 char limit. Now that you mention it, there are other places in this patch that could do with a whitespace cleanup. ;) > Cc: Rodrigo Vivi <rodrigo.vivi@xxxxxxxxx> > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
