[Intel-gfx] [PATCH 4/6] drm/i915: Add an interface to dynamically change the cache level

Eric Anholt eric at anholt.net
Wed Mar 30 18:59:55 CEST 2011


On Wed, 30 Mar 2011 08:09:47 +0100, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> The series looks really good, only one quibble below.
> 
> On Tue, 29 Mar 2011 16:59:53 -0700, Eric Anholt <eric at anholt.net> wrote:
> > +int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj,
> > +				    enum i915_cache_level cache_level)
> > +	if (cache_level == I915_CACHE_NONE) {
> > +		/* If we're coming frm LLC cached, then we haven't
> > +		 * actually been tracking whether the data is in the
> > +		 * CPU cache or not, since we only allow one bit set
> > +		 * in obj->write_domain.  Just set it to the CPU cache
> > +		 * for now.
> > +		 */
> > +		BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS);
> > +		obj->base.write_domain = I915_GEM_DOMAIN_CPU;
> > +	}
> 
> [We can rearrange the code to convert the BUG_ON into a
>  if (WARN_ON()) return -EBUSY;.]
> 
> I think this is overkill, at least by my interpretation of the old BLT
> docs which imply that cache line invalidation (both CPU and GPU) is done
> for snooped PTEs on MI_FLUSH.

And what about a CPU write through the GTT?  Or the CPU writes to the
pages before we turned them into a BO and cleared their CPU write domain
flag without actually clflushing them?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20110330/5b6e6bd0/attachment.sig>


More information about the Intel-gfx mailing list