| Message ID | 1377557469-4078-9-git-send-email-rodrigo.vivi@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Aug 26, 2013 at 07:51:00PM -0300, Rodrigo Vivi wrote: > From: Chris Wilson <chris@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 <chris@chris-wilson.co.uk> Makes sense. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > --- > 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); > } > @@ -179,7 +180,7 @@ relocate_entry_cpu(struct drm_i915_gem_object *obj, > char *vaddr; > int ret = -EINVAL; > > - ret = i915_gem_object_set_to_cpu_domain(obj, 1); > + ret = i915_gem_object_set_to_cpu_domain(obj, true); > if (ret) > return ret; > > -- > 1.8.1.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Tue, Aug 27, 2013 at 05:49:24PM +0300, Ville Syrjälä wrote: > On Mon, Aug 26, 2013 at 07:51:00PM -0300, Rodrigo Vivi wrote: > > From: Chris Wilson <chris@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 <chris@chris-wilson.co.uk> > > Makes sense. > > Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Queued for -next, thanks for the patch. -Daniel
On Mon, Aug 26, 2013 at 07:51:00PM -0300, Rodrigo Vivi wrote: > From: Chris Wilson <chris@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 <chris@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. > } > @@ -179,7 +180,7 @@ relocate_entry_cpu(struct drm_i915_gem_object *obj, > char *vaddr; > int ret = -EINVAL; > > - ret = i915_gem_object_set_to_cpu_domain(obj, 1); > + ret = i915_gem_object_set_to_cpu_domain(obj, true); > if (ret) > return ret; > > -- > 1.8.1.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 <chris@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 <chris@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
On Thu, Aug 29, 2013 at 09:11:16PM +0200, Daniel Vetter wrote: > 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 <chris@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 <chris@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 I always forget I915_CACHE_LLC is overloaded to mean snoopable.
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); } @@ -179,7 +180,7 @@ relocate_entry_cpu(struct drm_i915_gem_object *obj, char *vaddr; int ret = -EINVAL; - ret = i915_gem_object_set_to_cpu_domain(obj, 1); + ret = i915_gem_object_set_to_cpu_domain(obj, true); if (ret) return ret;