[Intel-gfx] [PATCH] drm/i915: Do not set cache_dirty for DGFX
Andi Shyti
andi.shyti at linux.intel.com
Wed Nov 2 21:59:52 UTC 2022
Hi Niranjana,
On Tue, Nov 01, 2022 at 10:14:16PM -0700, Niranjana Vishwanathapura wrote:
> Currently on DG1, which do not have LLC, we hit the below
> warning while rebinding an userptr invalidated object.
>
> WARNING: CPU: 4 PID: 13008 at drivers/gpu/drm/i915/gem/i915_gem_pages.c:34 __i915_gem_object_set_pages+0x296/0x2d0 [i915]
> ...
> RIP: 0010:__i915_gem_object_set_pages+0x296/0x2d0 [i915]
> ...
> Call Trace:
> <TASK>
> i915_gem_userptr_get_pages+0x175/0x1a0 [i915]
> ____i915_gem_object_get_pages+0x32/0xb0 [i915]
> i915_gem_object_userptr_submit_init+0x286/0x470 [i915]
> eb_lookup_vmas+0x2ff/0xcf0 [i915]
> ? __intel_wakeref_get_first+0x55/0xb0 [i915]
> i915_gem_do_execbuffer+0x785/0x21d0 [i915]
> i915_gem_execbuffer2_ioctl+0xe7/0x3d0 [i915]
>
> We shouldn't be setting the obj->cache_dirty for DGFX,
> fix it.
>
> Suggested-by: Matthew Auld <matthew.auld at intel.com>
> Reported-by: Niranjana Vishwanathapura <niranjana.vishwanathapura at intel.com>
> Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura at intel.com>
The BAT failure doesn't look related to this patch, to me.
Reviewed-by: Andi Shyti <andi.shyti at linux.intel.com>
Thanks,
Andi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> index 11125c32dd35..2f7804492cd5 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
> @@ -369,14 +369,14 @@ __i915_gem_object_release_shmem(struct drm_i915_gem_object *obj,
>
> __start_cpu_write(obj);
> /*
> - * On non-LLC platforms, force the flush-on-acquire if this is ever
> + * On non-LLC igfx platforms, force the flush-on-acquire if this is ever
> * swapped-in. Our async flush path is not trust worthy enough yet(and
> * happens in the wrong order), and with some tricks it's conceivable
> * for userspace to change the cache-level to I915_CACHE_NONE after the
> * pages are swapped-in, and since execbuf binds the object before doing
> * the async flush, we have a race window.
> */
> - if (!HAS_LLC(i915))
> + if (!HAS_LLC(i915) && !IS_DGFX(i915))
> obj->cache_dirty = true;
> }
>
> --
> 2.21.0.rc0.32.g243a4c7e27
More information about the Intel-gfx
mailing list