Re: [Intel-gfx] [PATCH 08/17] drm/i915: Always prefer CPU relocations with LLC

2013-08-29 Thread Ben Widawsky
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 
> > > 
> > > 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 
> > > ---
> > >  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.

-- 
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 08/17] drm/i915: Always prefer CPU relocations with LLC

2013-08-29 Thread Daniel Vetter
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 
> > 
> > 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 
> > ---
> >  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


Re: [Intel-gfx] [PATCH 08/17] drm/i915: Always prefer CPU relocations with LLC

2013-08-29 Thread Ben Widawsky
On Mon, Aug 26, 2013 at 07:51:00PM -0300, Rodrigo Vivi wrote:
> From: Chris Wilson 
> 
> 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 
> ---
>  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

-- 
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 08/17] drm/i915: Always prefer CPU relocations with LLC

2013-08-27 Thread Daniel Vetter
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 
> > 
> > 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 
> 
> Makes sense.
> 
> Reviewed-by: Ville Syrjälä 

Queued for -next, thanks for the patch.
-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


Re: [Intel-gfx] [PATCH 08/17] drm/i915: Always prefer CPU relocations with LLC

2013-08-27 Thread Ville Syrjälä
On Mon, Aug 26, 2013 at 07:51:00PM -0300, Rodrigo Vivi wrote:
> From: Chris Wilson 
> 
> 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 

Makes sense.

Reviewed-by: Ville Syrjälä 

> ---
>  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

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 08/17] drm/i915: Always prefer CPU relocations with LLC

2013-08-26 Thread Rodrigo Vivi
From: Chris Wilson 

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 
---
 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