The scratch page is directly visible in the users address space, and while this is forced as CACHE_LLC, by the kernel, we still have to contend with things like "Bypass-LLC" MOCS. So just flush no matter what.
v2(Thomas): - Make sure we use drm_clflush_virt_range here, in case clflush support is missing.
Signed-off-by: Matthew Auld matthew.auld@intel.com Cc: Thomas Hellström thomas.hellstrom@linux.intel.com Cc: Chris Wilson chris@chris-wilson.co.uk Cc: Ramalingam C ramalingam.c@intel.com Reviewed-by: Thomas Hellström thomas.hellstrom@linux.intel.com --- drivers/gpu/drm/i915/gt/intel_gtt.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c b/drivers/gpu/drm/i915/gt/intel_gtt.c index 67d14afa6623..efb51e881c5a 100644 --- a/drivers/gpu/drm/i915/gt/intel_gtt.c +++ b/drivers/gpu/drm/i915/gt/intel_gtt.c @@ -273,6 +273,7 @@ static void poison_scratch_page(struct drm_i915_gem_object *scratch) val = POISON_FREE;
memset(vaddr, val, scratch->base.size); + drm_clflush_virt_range(vaddr, scratch->base.size); }
int setup_scratch_page(struct i915_address_space *vm)
Normal users shouldn't be hitting this, likely this would indicate a userspace bug. So don't bother caching, which should be safe now that we manually flush the page.
Suggested-by: Chris Wilson chris@chris-wilson.co.uk Signed-off-by: Matthew Auld matthew.auld@intel.com Cc: Thomas Hellström thomas.hellstrom@linux.intel.com Cc: Chris Wilson chris@chris-wilson.co.uk Cc: Ramalingam C ramalingam.c@intel.com Reviewed-by: Thomas Hellström thomas.hellstrom@linux.intel.com --- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c index 8af2f709571c..9966e9dc5218 100644 --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c @@ -651,7 +651,7 @@ static int gen8_init_scratch(struct i915_address_space *vm)
vm->scratch[0]->encode = gen8_pte_encode(px_dma(vm->scratch[0]), - I915_CACHE_LLC, pte_flags); + I915_CACHE_NONE, pte_flags);
for (i = 1; i <= vm->top; i++) { struct drm_i915_gem_object *obj; @@ -667,7 +667,7 @@ static int gen8_init_scratch(struct i915_address_space *vm) }
fill_px(obj, vm->scratch[i - 1]->encode); - obj->encode = gen8_pde_encode(px_dma(obj), I915_CACHE_LLC); + obj->encode = gen8_pde_encode(px_dma(obj), I915_CACHE_NONE);
vm->scratch[i] = obj; }
On 28/10/2021 10:26, Matthew Auld wrote:
Normal users shouldn't be hitting this, likely this would indicate a userspace bug. So don't bother caching, which should be safe now that we manually flush the page.
Could this have a performance impact if "things" overfetch often enough in normal operation?
Regards,
Tvrtko
Suggested-by: Chris Wilson chris@chris-wilson.co.uk Signed-off-by: Matthew Auld matthew.auld@intel.com Cc: Thomas Hellström thomas.hellstrom@linux.intel.com Cc: Chris Wilson chris@chris-wilson.co.uk Cc: Ramalingam C ramalingam.c@intel.com Reviewed-by: Thomas Hellström thomas.hellstrom@linux.intel.com
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c index 8af2f709571c..9966e9dc5218 100644 --- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c +++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c @@ -651,7 +651,7 @@ static int gen8_init_scratch(struct i915_address_space *vm)
vm->scratch[0]->encode = gen8_pte_encode(px_dma(vm->scratch[0]),
I915_CACHE_LLC, pte_flags);
I915_CACHE_NONE, pte_flags);for (i = 1; i <= vm->top; i++) { struct drm_i915_gem_object *obj;
@@ -667,7 +667,7 @@ static int gen8_init_scratch(struct i915_address_space *vm) }
fill_px(obj, vm->scratch[i - 1]->encode);
obj->encode = gen8_pde_encode(px_dma(obj), I915_CACHE_LLC);
obj->encode = gen8_pde_encode(px_dma(obj), I915_CACHE_NONE);vm->scratch[i] = obj; }
dri-devel@lists.freedesktop.org
-
Matthew Auld -
Tvrtko Ursulin