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.
> }
> @@ -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
