On Wed, Nov 27, 2013 at 05:22:55PM +0200, ville.syrjala@xxxxxxxxxxxxxxx wrote: > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
