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@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