[Intel-gfx] [PATCH] drm/i915: Introduce accurate frontbuffer tracking

[Chris Wilson]

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 at intel.com>
> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre