On Thu, Aug 29, 2013 at 10:20:06AM -0700, Ben Widawsky wrote:
> On Mon, Aug 26, 2013 at 07:51:00PM -0300, Rodrigo Vivi wrote:
> > From: Chris Wilson <ch...@chris-wilson.co.uk>
> >
> > A follow-on to the update of the LLC coherency logic is that we can rely
> > on the LLC being coherent with the CS for rewriting batchbuffers
> > irrespective of their cache domain. (This should have no effect
> > currently as all the batch buffers are expected to be I915_CACHE_LLC and
> > so using the cpu relocation path anyway.)
> >
> > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> > ---
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 792c52a..3b64b9f 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -166,7 +166,8 @@ eb_destroy(struct eb_objects *eb)
> >
> > static inline int use_cpu_reloc(struct drm_i915_gem_object *obj)
> > {
> > - return (obj->base.write_domain == I915_GEM_DOMAIN_CPU ||
> > + return (HAS_LLC(obj->base.dev) ||
> > + obj->base.write_domain == I915_GEM_DOMAIN_CPU ||
> > !obj->map_and_fenceable ||
> > obj->cache_level != I915_CACHE_NONE);
>
> Assuming the commit message is factually correct... the obj->cache_level
> shouldn't factor into the equation at all.
We stil need to take the cache level into account on non-llc machines ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
