[Intel-gfx] [PATCH 2/3] drm/i915: Drop inspection of execbuf flags during evict

[Daniel Vetter]

On Wed, Nov 6, 2019 at 4:49 PM Chris Wilson <chris at chris-wilson.co.uk> wrote:
>
> With the goal of removing the serialisation from around execbuf, we will
> no longer have the privilege of there being a single execbuf in flight
> at any time and so will only be able to inspect the user's flags within
> the carefully controlled execbuf context. i915_gem_evict_for_node() is
> the only user outside of execbuf that currently peeks at the flag to
> convert an overlapping softpinned request from ENOSPC to EINVAL. Retract
> this nicety and only report ENOSPC if the location is in current use,
> either due to this execbuf or another.
>
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>

Same reasons as for patch 3, I don't think we have to do this at all.
-Daniel

> ---
>  drivers/gpu/drm/i915/i915_gem_evict.c | 15 ++++++---------
>  1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c b/drivers/gpu/drm/i915/i915_gem_evict.c
> index 7e62c310290f..1395018c657a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_evict.c
> +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> @@ -292,7 +292,8 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
>                 GEM_BUG_ON(!drm_mm_node_allocated(node));
>                 vma = container_of(node, typeof(*vma), node);
>
> -               /* If we are using coloring to insert guard pages between
> +               /*
> +                * If we are using coloring to insert guard pages between
>                  * different cache domains within the address space, we have
>                  * to check whether the objects on either side of our range
>                  * abutt and conflict. If they are in conflict, then we evict
> @@ -309,22 +310,18 @@ int i915_gem_evict_for_node(struct i915_address_space *vm,
>                         }
>                 }
>
> -               if (flags & PIN_NONBLOCK &&
> -                   (i915_vma_is_pinned(vma) || i915_vma_is_active(vma))) {
> +               if (i915_vma_is_pinned(vma)) {
>                         ret = -ENOSPC;
>                         break;
>                 }
>
> -               /* Overlap of objects in the same batch? */
> -               if (i915_vma_is_pinned(vma)) {
> +               if (flags & PIN_NONBLOCK && i915_vma_is_active(vma)) {
>                         ret = -ENOSPC;
> -                       if (vma->exec_flags &&
> -                           *vma->exec_flags & EXEC_OBJECT_PINNED)
> -                               ret = -EINVAL;
>                         break;
>                 }
>
> -               /* Never show fear in the face of dragons!
> +               /*
> +                * Never show fear in the face of dragons!
>                  *
>                  * We cannot directly remove this node from within this
>                  * iterator and as with i915_gem_evict_something() we employ
> --
> 2.24.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch