[RFC 4/8] drm/i915: Refactor PAT/object cache handling
Yang, Fei
fei.yang at intel.com
Fri Jul 28 07:14:27 UTC 2023
[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?
> }
More information about the dri-devel
mailing list