On Tue, Nov 08, 2016 at 01:33:41PM +0200, Ville Syrjälä wrote: > On Sun, Nov 06, 2016 at 01:00:00PM +0000, Chris Wilson wrote: > > - i915_gem_object_flush_cpu_write_domain(obj); > > + if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU) > > + i915_gem_clflush_object(obj, true); > > + intel_fb_obj_flush(obj, false, ORIGIN_CPU); > > So one slight change in behaviour is that we won't clear the write domain > here, but that's fine since we'll clear it below anyway. > > The other is that we now call intel_fb_obj_flush() unconditionally, > whereas before we only called if when the bo was in the CPU write > domain. Hmm. Should we keep it conditional? I was thinking that we should call it in the case we deferred clflush, and I was wanting to make the preflip path closer to dirtyfb. Since to me they both demark the frame boundary and the preparatory flushing should be more or less the same. > > old_write_domain = obj->base.write_domain; > > old_read_domains = obj->base.read_domains; > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > > index 92ab01f33208..47233b242c99 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -15698,6 +15698,8 @@ static int intel_user_framebuffer_dirty(struct drm_framebuffer *fb, > > struct drm_i915_gem_object *obj = intel_fb->obj; > > > > mutex_lock(&dev->struct_mutex); > > + if (obj->pin_display && obj->cache_dirty) > > + i915_gem_clflush_object(obj, true); > > intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB); > > mutex_unlock(&dev->struct_mutex); -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
