On Mon, Jun 20, 2022 at 07:42:25AM -0700, Zeng, Oak wrote:
Thanks, Oak
-----Original Message----- From: Vishwanathapura, Niranjana niranjana.vishwanathapura@intel.com Sent: June 17, 2022 1:15 AM To: intel-gfx@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Vetter, Daniel daniel.vetter@intel.com Cc: Hellstrom, Thomas thomas.hellstrom@intel.com; Wilson, Chris P chris.p.wilson@intel.com; jason@jlekstrand.net; christian.koenig@amd.com; Brost, Matthew matthew.brost@intel.com; Ursulin, Tvrtko tvrtko.ursulin@intel.com; Auld, Matthew matthew.auld@intel.com; Landwerlin, Lionel G lionel.g.landwerlin@intel.com; Zanoni, Paulo R paulo.r.zanoni@intel.com; Zeng, Oak oak.zeng@intel.com Subject: [PATCH v2 3/3] drm/doc/rfc: VM_BIND uapi definition
VM_BIND and related uapi definitions
v2: Reduce the scope to simple Mesa use case.
Signed-off-by: Niranjana Vishwanathapura
niranjana.vishwanathapura@intel.com
Documentation/gpu/rfc/i915_vm_bind.h | 226 +++++++++++++++++++++++++++ 1 file changed, 226 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h b/Documentation/gpu/rfc/i915_vm_bind.h new file mode 100644 index 000000000000..b7540ddb526d --- /dev/null +++ b/Documentation/gpu/rfc/i915_vm_bind.h @@ -0,0 +1,226 @@ +/* SPDX-License-Identifier: MIT */ +/*
- Copyright © 2022 Intel Corporation
- */
+/**
- DOC: I915_PARAM_HAS_VM_BIND
- VM_BIND feature availability.
- See typedef drm_i915_getparam_t param.
- */
+#define I915_PARAM_HAS_VM_BIND 57
+/**
- DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
- Flag to opt-in for VM_BIND mode of binding during VM creation.
- See struct drm_i915_gem_vm_control flags.
- The older execbuf2 ioctl will not support VM_BIND mode of operation.
- For VM_BIND mode, we have new execbuf3 ioctl which will not accept
any
- execlist (See struct drm_i915_gem_execbuffer3 for more details).
- */
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+/* VM_BIND related ioctls */ +#define DRM_I915_GEM_VM_BIND 0x3d +#define DRM_I915_GEM_VM_UNBIND 0x3e +#define DRM_I915_GEM_EXECBUFFER3 0x3f
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind) +#define DRM_IOCTL_I915_GEM_VM_UNBIND DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_VM_UNBIND, struct drm_i915_gem_vm_bind) +#define DRM_IOCTL_I915_GEM_EXECBUFFER3 DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_EXECBUFFER3, struct drm_i915_gem_execbuffer3)
+/**
- struct drm_i915_gem_vm_bind_fence - Bind/unbind completion
notification.
- A timeline out fence for vm_bind/unbind completion notification.
- */
+struct drm_i915_gem_vm_bind_fence {
/** @handle: User's handle for a drm_syncobj to signal. */__u32 handle;/** @rsvd: Reserved, MBZ */__u32 rsvd;/*** @value: A point in the timeline.* Value must be 0 for a binary drm_syncobj. A Value of 0 for a* timeline drm_syncobj is invalid as it turns a drm_syncobj into a* binary one.*/__u64 value;+};
+/**
- struct drm_i915_gem_vm_bind - VA to object mapping to bind.
- This structure is passed to VM_BIND ioctl and specifies the mapping of
GPU
- virtual address (VA) range to the section of an object that should be
bound
- in the device page table of the specified address space (VM).
- The VA range specified must be unique (ie., not currently bound) and can
- be mapped to whole object or a section of the object (partial binding).
- Multiple VA mappings can be created to the same section of the object
- (aliasing).
- The @start, @offset and @length should be 4K page aligned. However
the DG2
- and XEHPSDV has 64K page size for device local-memory and has compact
page
- table. On those platforms, for binding device local-memory objects, the
- @start should be 2M aligned, @offset and @length should be 64K aligned.
- Also, on those platforms, it is not allowed to bind an device local-memory
- object and a system memory object in a single 2M section of VA range.
- */
+struct drm_i915_gem_vm_bind {
/** @vm_id: VM (address space) id to bind */__u32 vm_id;/** @handle: Object handle */__u32 handle;/** @start: Virtual Address start to bind */__u64 start;/** @offset: Offset in object to bind */__u64 offset;/** @length: Length of mapping to bind */__u64 length;/*** @flags: Supported flags are:** I915_GEM_VM_BIND_READONLY:* Mapping is read-only.** I915_GEM_VM_BIND_CAPTURE:* Capture this mapping in the dump upon GPU error.*/__u64 flags;+#define I915_GEM_VM_BIND_READONLY (1 << 0)
Should we define another flag for DEVICE_ATOMIC? Without this flag, do you imply all the mapping support device atomic operation? HW platform also has an implication to device atomic, i.e., some platform don't support device atomics to system memory.
Thanks Oak, we can always add required flags later when we want to add the support.
Niranjana
Regards, Oak
+#define I915_GEM_VM_BIND_CAPTURE (1 << 1)
/** @fence: Timeline fence for bind completion signaling */struct drm_i915_gem_vm_bind_fence fence;/** @extensions: 0-terminated chain of extensions */__u64 extensions;+};
+/**
- struct drm_i915_gem_vm_unbind - VA to object mapping to unbind.
- This structure is passed to VM_UNBIND ioctl and specifies the GPU virtual
- address (VA) range that should be unbound from the device page table
of the
- specified address space (VM). The specified VA range must match one of
the
- mappings created with the VM_BIND ioctl. TLB is flushed upon unbind
- completion.
- The @start and @length musy specify a unique mapping bound with
VM_BIND
- ioctl.
- */
+struct drm_i915_gem_vm_unbind {
/** @vm_id: VM (address space) id to bind */__u32 vm_id;/** @rsvd: Reserved, MBZ */__u32 rsvd;/** @start: Virtual Address start to unbind */__u64 start;/** @length: Length of mapping to unbind */__u64 length;/** @flags: Reserved for future usage, currently MBZ */__u64 flags;/** @fence: Timeline fence for unbind completion signaling */struct drm_i915_gem_vm_bind_fence fence;/** @extensions: 0-terminated chain of extensions */__u64 extensions;+};
+/**
- struct drm_i915_gem_execbuffer3 - Structure for
DRM_I915_GEM_EXECBUFFER3
- ioctl.
- DRM_I915_GEM_EXECBUFFER3 ioctl only works in VM_BIND mode and
VM_BIND mode
- only works with this ioctl for submission.
- See I915_VM_CREATE_FLAGS_USE_VM_BIND.
- */
+struct drm_i915_gem_execbuffer3 {
/*** @ctx_id: Context id** Only contexts with user engine map are allowed.*/__u32 ctx_id;/*** @engine_idx: Engine index** An index in the user engine map of the context specified by@ctx_id.
*/__u32 engine_idx;/** @rsvd1: Reserved, MBZ */__u32 rsvd1;/*** @batch_count: Number of batches in @batch_address array.** 0 is invalid. For parallel submission, it should be equal to the* number of (parallel) engines involved in that submission.*/__u32 batch_count;/*** @batch_address: Array of batch gpu virtual addresses.** If @batch_count is 1, then it is the gpu virtual address of the* batch buffer. If @batch_count > 1, then it is a pointer to an array* of batch buffer gpu virtual addresses.*/__u64 batch_address;/*** @flags: Supported flags are:** I915_EXEC3_SECURE:* Request a privileged ("secure") batch buffer/s.* It is only available for DRM_ROOT_ONLY | DRM_MASTERprocesses.
*/__u64 flags;+#define I915_EXEC3_SECURE (1<<0)
/** @rsvd2: Reserved, MBZ */__u64 rsvd2;/*** @extensions: Zero-terminated chain of extensions.** DRM_I915_GEM_EXECBUFFER3_EXT_TIMELINE_FENCES:* It has same format asDRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES.
* See struct drm_i915_gem_execbuffer_ext_timeline_fences.*/__u64 extensions;+#define DRM_I915_GEM_EXECBUFFER3_EXT_TIMELINE_FENCES 0 +};
+/**
- struct drm_i915_gem_create_ext_vm_private - Extension to make the
object
- private to the specified VM.
- See struct drm_i915_gem_create_ext.
- */
+struct drm_i915_gem_create_ext_vm_private { +#define I915_GEM_CREATE_EXT_VM_PRIVATE 2
/** @base: Extension link. See struct i915_user_extension. */struct i915_user_extension base;/** @vm_id: Id of the VM to which the object is private */__u32 vm_id;+};
2.21.0.rc0.32.g243a4c7e27