Re: [RFC 4/8] drm/i915: Refactor PAT/object cache handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[snip]
> @@ -41,14 +42,17 @@ static bool gpu_write_needs_clflush(struct drm_i915_gem_object *obj)
>               return false;
>
>       /*
> -      * For objects created by userspace through GEM_CREATE with pat_index
> -      * set by set_pat extension, i915_gem_object_has_cache_level() will
> -      * always return true, because the coherency of such object is managed

i915_gem_object_has_cache_level() always return true means this function
always return false.

> -      * by userspace. Othereise the call here would fall back to checking
> -      * whether the object is un-cached or write-through.
> +      * Always flush cache for UMD objects with PAT index set.

(obj->pat_set_by_user == true) indicates UMD knows how to handle the coherency,
forcing clflush in KMD would be redundant.

>        */
> -     return !(i915_gem_object_has_cache_level(obj, I915_CACHE_NONE) ||
> -              i915_gem_object_has_cache_level(obj, I915_CACHE_WT));
> +     if (obj->pat_set_by_user)
> +             return true;

return false;

> +
> +     /*
> +      * Fully coherent cached access may end up with data in the CPU cache
> +      * which hasn't hit memory yet.
> +      */
> +     return i915_gem_object_has_cache_mode(obj, I915_CACHE_MODE_WB) &&
> +            i915_gem_object_has_cache_flag(obj, I915_CACHE_FLAG_COH2W);

Why checking COH2W here? The logic was, if UC or WT return false, otherwise
return true. So, as long as cache_mode is WB, it's sufficient to say true
here, right?

>  }




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux