From: Matthew Auld <matthew.auld@intel.com>
To: igt-dev@lists.freedesktop.org
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH i-g-t 1/6] lib/i915_drm_local: Add I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS
Date: Mon, 21 Feb 2022 14:10:31 +0000 [thread overview]
Message-ID: <20220221141036.2490380-1-matthew.auld@intel.com> (raw)
For now dump into i915_drm_local.h. Once the uapi on the kernel side is
merged, and is part of drm-next, we can sync the kernel headers and
remove this.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
lib/i915/i915_drm_local.h | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/lib/i915/i915_drm_local.h b/lib/i915/i915_drm_local.h
index 9e82c968..7b5285f3 100644
--- a/lib/i915/i915_drm_local.h
+++ b/lib/i915/i915_drm_local.h
@@ -21,6 +21,33 @@ extern "C" {
*/
#define I915_ENGINE_CLASS_COMPUTE 4
+/*
+ * Signal to the kernel that the object will need to be accessed via
+ * the CPU.
+ *
+ * Only valid when placing objects in I915_MEMORY_CLASS_DEVICE, and only
+ * strictly required on platforms where only some of the device memory
+ * is directly visible or mappable through the CPU, like on DG2+.
+ *
+ * One of the placements MUST also be I915_MEMORY_CLASS_SYSTEM, to
+ * ensure we can always spill the allocation to system memory, if we
+ * can't place the object in the mappable part of
+ * I915_MEMORY_CLASS_DEVICE.
+ *
+ * Note that buffers that need to be captured with EXEC_OBJECT_CAPTURE,
+ * will need to enable this hint, if the object can also be placed in
+ * I915_MEMORY_CLASS_DEVICE, starting from DG2+. The execbuf call will
+ * throw an error otherwise. This also means that such objects will need
+ * I915_MEMORY_CLASS_SYSTEM set as a possible placement.
+ *
+ * Without this hint, the kernel will assume that non-mappable
+ * I915_MEMORY_CLASS_DEVICE is preferred for this object. Note that the
+ * kernel can still migrate the object to the mappable part, as a last
+ * resort, if userspace ever CPU faults this object, but this might be
+ * expensive, and so ideally should be avoided.
+ */
+#define I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS (1 << 0)
+
#if defined(__cplusplus)
}
#endif
--
2.34.1
next reply other threads:[~2022-02-21 14:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-21 14:10 Matthew Auld [this message]
2022-02-21 14:10 ` [Intel-gfx] [PATCH i-g-t 2/6] lib/i915: wire up optional flags for gem_create_ext Matthew Auld
2022-02-21 14:10 ` [Intel-gfx] [PATCH i-g-t 3/6] tests/i915/gem_create: test NEEDS_CPU_ACCESS Matthew Auld
2022-02-21 14:10 ` [Intel-gfx] [PATCH i-g-t 4/6] lib/i915: add gem_create_with_cpu_access_in_memory_regions Matthew Auld
2022-02-21 14:10 ` [Intel-gfx] [PATCH i-g-t 5/6] i915/tests/capture: add a negative test for NEEDS_CPU_ACCESS Matthew Auld
2022-02-21 14:10 ` [Intel-gfx] [PATCH i-g-t 6/6] lib/i915: request CPU_ACCESS for fb objects Matthew Auld
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=20220221141036.2490380-1-matthew.auld@intel.com \
--to=matthew.auld@intel.com \
--cc=igt-dev@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=thomas.hellstrom@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox