On Thu, Aug 08, 2013 at 06:51:26PM +0300, Ville Syrjälä wrote:
> On Thu, Aug 08, 2013 at 04:36:35PM +0100, Chris Wilson wrote:
> > On Thu, Aug 08, 2013 at 06:27:12PM +0300, Ville Syrjälä wrote:
> > > On Thu, Aug 08, 2013 at 02:41:05PM +0100, Chris Wilson wrote:
> > > > if (!needs_clflush_after &&
> > > > obj->base.write_domain != I915_GEM_DOMAIN_CPU) {
> > > > - i915_gem_clflush_object(obj);
> > > > + i915_gem_clflush_object(obj, false);
> > >
> > > Shouldn't that be i915_gem_clflush_object(obj, obj->pin_display) ?
> >
> > !needs_clflush_after implies that we cache-coherent and not writing to a
> > scanout, so obj->pin_display must be false here.
>
> But we dropped the lock in the slow path, so couldn't it have changed?
Que sera, sera. The contents after userspace races with itself are going
to be fairly arbitrary. Doing the flush is likely to be better than
not...
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
