[Intel-gfx] [PATCH v5 3/3] drm/doc/rfc: VM_BIND uapi definition

Niranjana Vishwanathapura niranjana.vishwanathapura at intel.com
Fri Jun 24 05:45:11 UTC 2022


On Thu, Jun 23, 2022 at 10:32:08PM -0700, Niranjana Vishwanathapura wrote:
>VM_BIND and related uapi definitions
>
>v2: Reduce the scope to simple Mesa use case.
>v3: Expand VM_UNBIND documentation and add
>    I915_GEM_VM_BIND/UNBIND_FENCE_VALID
>    and I915_GEM_VM_BIND_TLB_FLUSH flags.
>v4: Remove I915_GEM_VM_BIND_TLB_FLUSH flag and add additional
>    documentation for vm_bind/unbind.
>v5: Remove TLB flush requirement on VM_UNBIND.
>    Add version support to stage implementation.
>
>Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura at intel.com>
>---
> Documentation/gpu/rfc/i915_vm_bind.h | 256 +++++++++++++++++++++++++++
> 1 file changed, 256 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..8af6c035ccf4
>--- /dev/null
>+++ b/Documentation/gpu/rfc/i915_vm_bind.h
>@@ -0,0 +1,256 @@
>+/* 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.
>+ * bit[0]: If set, VM_BIND is supported, otherwise not.
>+ * bits[8-15]: VM_BIND implementation version.
>+ * Version 0 requires in VM_UNBIND call, UMDs to specify the exact mapping
>+ * created previously with the VM_BIND call. i.e., i915 will not support
>+ * splitting/merging of the mappings created with VM_BIND call (See
>+ * struct drm_i915_gem_vm_bind and struct drm_i915_gem_vm_unbind).
>+ */
>+#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, error -ENOSPC will be returned if user tries to
>+ * bind a device local-memory object and a system memory object in a single 2M
>+ * section of VA range.
>+ *
>+ * Error code -EINVAL will be returned if @start, @offset and @length are not
>+ * properly aligned. Error code of -ENOSPC will be returned if the VA range
>+ * specified can't be reserved.
>+ *
>+ * The bind operation can get completed asynchronously and out of submission
>+ * order. When I915_GEM_VM_BIND_FENCE_VALID flag is set, the @fence will be
>+ * signaled upon completion of bind operation.
>+ */
>+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_FENCE_VALID:
>+	 * @fence is valid, needs bind completion notification.
>+	 *
>+	 * 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_FENCE_VALID	(1 << 0)
>+#define I915_GEM_VM_BIND_READONLY	(1 << 1)
>+#define I915_GEM_VM_BIND_CAPTURE	(1 << 2)
>+
>+	/** @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). VM_UNBIND will force unbind the specified
>+ * range from device page table without waiting for any GPU job to complete.
>+ * It is UMDs responsibility to ensure the mapping is no longer in use before
>+ * calling VM_UNBIND.
>+ *
>+ * If the specified mapping is not found, the ioctl will simply return without
>+ * any error.
>+ *
>+ * The unbind operation can get completed asynchronously and out of submission
>+ * order. When I915_GEM_VM_UNBIND_FENCE_VALID flag is set, the @fence will be
>+ * signaled upon completion of unbind operation.
>+ */
>+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: Supported flags are:
>+	 *
>+	 * I915_GEM_VM_UNBIND_FENCE_VALID:
>+	 * @fence is valid, needs unbind completion notification.
>+	 */
>+	__u64 flags;
>+#define I915_GEM_VM_UNBIND_FENCE_VALID	(1 << 0)
>+
>+	/** @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_MASTER processes.
>+	 */
>+	__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 as DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES.
>+	 * See struct drm_i915_gem_execbuffer_ext_timeline_fences.

Here we are using drm_i915_gem_execbuffer_ext_timeline_fences (same as
execbuf2), which has separate handles_ptr and values_ptr arrays. This is
probably because this extension uses the same drm_i915_gem_exec_fence
which is defined for older fence_array (cliprects_ptr) support.

For execbuf3, we can get rid of separate values_ptr array and include it
in the same structure as handle (similar to drm_i915_gem_vm_bind_fence).
In fact, we can use drm_i915_gem_vm_bind_fence as execbuf3 timeline fence
array element as well (convert to rsvd to flags for FENCE_WAIT/FENCE_SIGNAL).
I think this is better option here.

But this means, for execbuf3 we can't share the timeline fence array handling
code with execbuf2.

What do you guys suggest?

Niranjana

>+	 */
>+	__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
>


More information about the Intel-gfx mailing list