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
next prev 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: linkBe 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.