[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