All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: intel-gfx@lists.freedesktop.org
Subject: [PATCH 2/3] drm/i915: Drop inspection of execbuf flags during evict
Date: Wed,  6 Nov 2019 15:48:09 +0000	[thread overview]
Message-ID: <20191106154810.5843-2-chris@chris-wilson.co.uk> (raw)
In-Reply-To: <20191106154810.5843-1-chris@chris-wilson.co.uk>

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@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Chris Wilson <chris@chris-wilson.co.uk>
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 2/3] drm/i915: Drop inspection of execbuf flags during evict
Date: Wed,  6 Nov 2019 15:48:09 +0000	[thread overview]
Message-ID: <20191106154810.5843-2-chris@chris-wilson.co.uk> (raw)
Message-ID: <20191106154809.m2k0brEDq24CkpWrKuzp9lDgWwVzqPZtvmiD_2T8lJE@z> (raw)
In-Reply-To: <20191106154810.5843-1-chris@chris-wilson.co.uk>

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@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2019-11-06 15:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-06 15:48 [PATCH 1/3] drm/i915: Handle i915_active_fence_set() with the same fence Chris Wilson
2019-11-06 15:48 ` [Intel-gfx] " Chris Wilson
2019-11-06 15:48 ` Chris Wilson [this message]
2019-11-06 15:48   ` [Intel-gfx] [PATCH 2/3] drm/i915: Drop inspection of execbuf flags during evict Chris Wilson
2019-11-08  9:54   ` Daniel Vetter
2019-11-08  9:54     ` [Intel-gfx] " Daniel Vetter
2019-11-08 10:11     ` Chris Wilson
2019-11-08 10:11       ` [Intel-gfx] " Chris Wilson
2019-11-08 10:20       ` Daniel Vetter
2019-11-08 10:20         ` [Intel-gfx] " Daniel Vetter
2019-11-08 10:40         ` Chris Wilson
2019-11-08 10:40           ` [Intel-gfx] " Chris Wilson
2019-11-08 16:06           ` Daniel Vetter
2019-11-08 16:06             ` [Intel-gfx] " Daniel Vetter
2019-11-06 15:48 ` [PATCH 3/3] drm/i915/gem: Extract transient execbuf flags from i915_vma Chris Wilson
2019-11-06 15:48   ` [Intel-gfx] " Chris Wilson
2019-11-08  9:53   ` Daniel Vetter
2019-11-08  9:53     ` [Intel-gfx] " Daniel Vetter
2019-11-08 10:05     ` Chris Wilson
2019-11-08 10:05       ` [Intel-gfx] " Chris Wilson
2019-11-08 16:13       ` Daniel Vetter
2019-11-08 16:13         ` [Intel-gfx] " Daniel Vetter
2019-11-06 19:22 ` ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Handle i915_active_fence_set() with the same fence Patchwork
2019-11-06 19:22   ` [Intel-gfx] " Patchwork
2019-11-08 10:37 ` [PATCH 1/3] " Tvrtko Ursulin
2019-11-08 10:37   ` [Intel-gfx] " Tvrtko Ursulin
2019-11-08 10:42   ` Chris Wilson
2019-11-08 10:42     ` [Intel-gfx] " Chris Wilson
2019-11-08 12:00 ` ✗ Fi.CI.IGT: failure for series starting with [1/3] " Patchwork
2019-11-08 12:00   ` [Intel-gfx] " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191106154810.5843-2-chris@chris-wilson.co.uk \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.