On Mon, Nov 25, 2013 at 04:54:48PM +0200, ville.syrjala@xxxxxxxxxxxxxxx wrote: > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > FBC host modification tracking only works through GTT mmaps, so any > direct CPU access needs to manually nuke the compressed framebuffer > on modifications. Do the nuking from the SW_FINISH ioctl. > > v2: nuke from SW_FINISH insted of DIRTYFB ioctl > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > --- > drivers/gpu/drm/i915/i915_gem.c | 2 ++ > drivers/gpu/drm/i915/intel_drv.h | 1 + > drivers/gpu/drm/i915/intel_pm.c | 30 ++++++++++++++++++++++++++++++ > 3 files changed, 33 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 40d9dcf..fdd7279 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -1309,6 +1309,8 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void *data, > if (obj->pin_display) > i915_gem_object_flush_cpu_write_domain(obj, true); > > + intel_fbc_nuke(obj); All though it doesn't matter (since intel_fbc_nuke does sufficient checks itself), it would seem clear to me to put this in the same if(obj->pin_display) block as the cpu flush. Notwithstanding that, Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Do we have any i-g-t to make sure that this path remains correct? -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
