On Wed, Dec 02, 2015 at 01:37:44PM +0530, akash.goel@xxxxxxxxx wrote: > From: Akash Goel <akash.goel@xxxxxxxxx> > > When the object is moved out of CPU read domain, the cachelines > are not invalidated immediately. The invalidation is deferred till > next time the object is brought back into CPU read domain. > But the invalidation is done unconditionally, i.e. even for the case > where the cachelines were flushed previously, when the object moved out > of CPU write domain. This is avoidable and would lead to some optimization. > Though this is not a hypothetical case, but is unlikely to occur often. > The aim is to detect changes to the backing storage whilst the > data is potentially in the CPU cache, and only clflush in those case. > > v2: Made the comment more verbose (Ville/Chris) > Added doc for 'cache_clean' field (Daniel) > > v3: Updated the comment to assuage an apprehension regarding the > speculative-prefetching behavior of HW (Ville/Chris) > > v4: Renamed 'cache_clean' to 'cache_flushed' as its more appropriate (Ville) > Made minor update in the comments for more clarity (Chris) Ah, spotted one nuisance we have in i915_gem_obj_prepare_shmem_read() that needs to clear the cache_flushed flag as after that call we will pollute the CPU cache (whilst pretending the object is not in the CPU cache domain). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
