All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Auld <matthew.auld@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Tvrtko Ursulin" <tvrtko.ursulin@linux.intel.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Lionel Landwerlin" <lionel.g.landwerlin@intel.com>,
	"Kenneth Graunke" <kenneth@whitecape.org>,
	"Jon Bloomfield" <jon.bloomfield@intel.com>,
	dri-devel@lists.freedesktop.org,
	"Jordan Justen" <jordan.l.justen@intel.com>,
	"Akeem G Abodunrin" <akeem.g.abodunrin@intel.com>
Subject: [PATCH v3 05/13] drm/i915/uapi: apply ALLOC_GPU_ONLY by default
Date: Wed, 29 Jun 2022 13:14:19 +0100	[thread overview]
Message-ID: <20220629121427.353800-6-matthew.auld@intel.com> (raw)
In-Reply-To: <20220629121427.353800-1-matthew.auld@intel.com>

On small BAR configurations, when dealing with I915_MEMORY_CLASS_DEVICE
allocations, we assume that by default, all userspace allocations should
be placed in the non-CPU visible portion.  Note that dumb buffers are
not included here, since these are not "GPU accelerated" and likely need
CPU access. We choose to just always set GPU_ONLY, and let the backend
figure out if that should be ignored or not, for example on full BAR
systems.

In a later patch userspace will be able to provide a hint if CPU access
to the buffer is needed.

v2(Thomas)
 - Apply GPU_ONLY on all discrete devices, but only if the BO can be
   placed in LMEM. Down in the depths this should be turned into a noop,
   where required, and as an annotation it still make some sense. If we
   apply it regardless of the placements then we end up needing to check
   the placements during exec capture. Also it's slightly inconsistent
   since the NEEDS_CPU_ACCESS can only be applied on objects that can be
   placed in LMEM. The other annoyance would be gem_create_ext vs plain
   gem_create, if we were to always apply GPU_ONLY.

Testcase: igt@gem-create@create-ext-cpu-access-sanity-check
Testcase: igt@gem-create@create-ext-cpu-access-big
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 5802692ea604..d094cae0ddf1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -427,6 +427,14 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void *data,
 		ext_data.n_placements = 1;
 	}
 
+	/*
+	 * TODO: add a userspace hint to force CPU_ACCESS for the object, which
+	 * can override this.
+	 */
+	if (ext_data.n_placements > 1 ||
+	    ext_data.placements[0]->type != INTEL_MEMORY_SYSTEM)
+		ext_data.flags |= I915_BO_ALLOC_GPU_ONLY;
+
 	obj = __i915_gem_object_create_user_ext(i915, args->size,
 						ext_data.placements,
 						ext_data.n_placements,
-- 
2.36.1


WARNING: multiple messages have this Message-ID (diff)
From: Matthew Auld <matthew.auld@intel.com>
To: intel-gfx@lists.freedesktop.org
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Kenneth Graunke" <kenneth@whitecape.org>,
	dri-devel@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v3 05/13] drm/i915/uapi: apply ALLOC_GPU_ONLY by default
Date: Wed, 29 Jun 2022 13:14:19 +0100	[thread overview]
Message-ID: <20220629121427.353800-6-matthew.auld@intel.com> (raw)
In-Reply-To: <20220629121427.353800-1-matthew.auld@intel.com>

On small BAR configurations, when dealing with I915_MEMORY_CLASS_DEVICE
allocations, we assume that by default, all userspace allocations should
be placed in the non-CPU visible portion.  Note that dumb buffers are
not included here, since these are not "GPU accelerated" and likely need
CPU access. We choose to just always set GPU_ONLY, and let the backend
figure out if that should be ignored or not, for example on full BAR
systems.

In a later patch userspace will be able to provide a hint if CPU access
to the buffer is needed.

v2(Thomas)
 - Apply GPU_ONLY on all discrete devices, but only if the BO can be
   placed in LMEM. Down in the depths this should be turned into a noop,
   where required, and as an annotation it still make some sense. If we
   apply it regardless of the placements then we end up needing to check
   the placements during exec capture. Also it's slightly inconsistent
   since the NEEDS_CPU_ACCESS can only be applied on objects that can be
   placed in LMEM. The other annoyance would be gem_create_ext vs plain
   gem_create, if we were to always apply GPU_ONLY.

Testcase: igt@gem-create@create-ext-cpu-access-sanity-check
Testcase: igt@gem-create@create-ext-cpu-access-big
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 5802692ea604..d094cae0ddf1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -427,6 +427,14 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void *data,
 		ext_data.n_placements = 1;
 	}
 
+	/*
+	 * TODO: add a userspace hint to force CPU_ACCESS for the object, which
+	 * can override this.
+	 */
+	if (ext_data.n_placements > 1 ||
+	    ext_data.placements[0]->type != INTEL_MEMORY_SYSTEM)
+		ext_data.flags |= I915_BO_ALLOC_GPU_ONLY;
+
 	obj = __i915_gem_object_create_user_ext(i915, args->size,
 						ext_data.placements,
 						ext_data.n_placements,
-- 
2.36.1


  parent reply	other threads:[~2022-06-29 12:15 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-29 12:14 [PATCH v3 00/13] small BAR uapi bits Matthew Auld
2022-06-29 12:14 ` [Intel-gfx] " Matthew Auld
2022-06-29 12:14 ` [PATCH v3 01/13] drm/doc: add rfc section for small BAR uapi Matthew Auld
2022-06-29 12:14   ` [Intel-gfx] " Matthew Auld
2022-06-29 12:14 ` [PATCH v3 02/13] drm/i915/uapi: add probed_cpu_visible_size Matthew Auld
2022-06-29 12:14   ` [Intel-gfx] " Matthew Auld
2022-06-29 12:14 ` [PATCH v3 03/13] drm/i915/uapi: expose the avail tracking Matthew Auld
2022-06-29 12:14   ` [Intel-gfx] " Matthew Auld
2022-06-29 12:14 ` [PATCH v3 04/13] drm/i915: remove intel_memory_region avail Matthew Auld
2022-06-29 12:14   ` [Intel-gfx] " Matthew Auld
2022-06-29 12:14 ` Matthew Auld [this message]
2022-06-29 12:14   ` [Intel-gfx] [PATCH v3 05/13] drm/i915/uapi: apply ALLOC_GPU_ONLY by default Matthew Auld
2022-06-29 12:14 ` [PATCH v3 06/13] drm/i915/uapi: add NEEDS_CPU_ACCESS hint Matthew Auld
2022-06-29 12:14   ` [Intel-gfx] " Matthew Auld
2022-06-29 12:14 ` [PATCH v3 07/13] drm/i915/error: skip non-mappable pages Matthew Auld
2022-06-29 12:14   ` [Intel-gfx] " Matthew Auld
2022-06-29 12:14 ` [Intel-gfx] [PATCH v3 08/13] drm/i915/uapi: tweak error capture on recoverable contexts Matthew Auld
2022-06-29 12:14   ` Matthew Auld
2022-06-29 12:14 ` [PATCH v3 09/13] drm/i915/selftests: skip the mman tests for stolen Matthew Auld
2022-06-29 12:14   ` [Intel-gfx] " Matthew Auld
2022-06-29 16:22   ` Thomas Hellström
2022-06-29 16:22     ` [Intel-gfx] " Thomas Hellström
2022-06-29 16:42     ` Matthew Auld
2022-06-29 16:42       ` [Intel-gfx] " Matthew Auld
2022-06-29 12:14 ` [PATCH v3 10/13] drm/i915/selftests: ensure we reserve a fence slot Matthew Auld
2022-06-29 12:14   ` [Intel-gfx] " Matthew Auld
2022-06-29 12:14 ` [PATCH v3 11/13] drm/i915/ttm: handle blitter failure on DG2 Matthew Auld
2022-06-29 12:14   ` [Intel-gfx] " Matthew Auld
2022-06-29 16:11   ` Thomas Hellström
2022-06-29 16:11     ` [Intel-gfx] " Thomas Hellström
2022-06-29 16:28     ` Matthew Auld
2022-06-29 16:28       ` [Intel-gfx] " Matthew Auld
2022-06-29 16:47       ` Thomas Hellström
2022-06-29 16:47         ` [Intel-gfx] " Thomas Hellström
2022-06-29 12:14 ` [PATCH v3 12/13] drm/i915/ttm: disallow CPU fallback mode for ccs pages Matthew Auld
2022-06-29 12:14   ` [Intel-gfx] " Matthew Auld
2022-06-29 12:43   ` Ramalingam C
2022-06-29 12:43     ` [Intel-gfx] " Ramalingam C
2022-06-29 12:14 ` [PATCH v3 13/13] drm/i915: turn on small BAR support Matthew Auld
2022-06-29 12:14   ` [Intel-gfx] " Matthew Auld
2022-06-29 16:16   ` Thomas Hellström
2022-06-29 16:16     ` [Intel-gfx] " Thomas Hellström
2022-06-29 13:00 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for small BAR uapi bits (rev4) Patchwork
2022-06-29 13:00 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-06-29 13:22 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-06-29 14:40 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for small BAR uapi bits (rev5) Patchwork
2022-06-29 14:40 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-06-29 15:05 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " 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=20220629121427.353800-6-matthew.auld@intel.com \
    --to=matthew.auld@intel.com \
    --cc=akeem.g.abodunrin@intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jon.bloomfield@intel.com \
    --cc=jordan.l.justen@intel.com \
    --cc=kenneth@whitecape.org \
    --cc=lionel.g.landwerlin@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    /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.