[Intel-gfx] [PATCH v5 06/10] drm/i915: Implement LRI based FBC tracking

[Chris Wilson]

On Wed, Nov 27, 2013 at 05:22:55PM +0200, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> 
> As per the SNB and HSW PM guides, we should enable FBC render/blitter
> tracking only during batches targetting the front buffer.
> 
> On SNB we must also update the FBC render tracking address whenever it
> changes. And since the register in question is stored in the context,
> we need to make sure we reload it with correct data after context
> switches.
> 
> On IVB/HSW we use the render nuke mechanism, so no render tracking
> address updates are needed. Hoever on the blitter side we need to
> enable the blitter tracking like on SNB, and in addition we need
> to issue the cache clean messages, which we already did.
> 
> v2: Introduce intel_fb_obj_has_fbc()
>     Fix crtc locking around crtc->fb access
>     Drop a hunk that was included by accident in v1
>     Set fbc_address_dirty=false not true after emitting the LRI
> v3: Now that fbc hangs on to the fb intel_fb_obj_has_fbc() doesn't
>     need to upset lockdep anymore
> v4: Use |= instead of = to update fbc_address_dirty
> v5: |= for fbc_dirty too, kill fbc_obj variable, pack the
>     intel_ringbuffer dirty bits using bitfields, skip ILK_FBC_RT_BASE
>     write on SNB+, kill sandybridge_blit_fbc_update(), reorganize
>     code to make future ILK FBC RT LRI support easier
> 
> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>

I'm content with the patch itself. I'd like to know what impact it has,
but I can live with my belief that it has to better than what we have
right now.

Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre