[Intel-gfx] [PATCH v2 3/3] drm/doc/rfc: VM_BIND uapi definition
Niranjana Vishwanathapura
niranjana.vishwanathapura at intel.com
Mon Jun 20 15:58:47 UTC 2022
On Mon, Jun 20, 2022 at 07:42:25AM -0700, Zeng, Oak wrote:
>
>
>Thanks,
>Oak
>
>> -----Original Message-----
>> From: Vishwanathapura, Niranjana <niranjana.vishwanathapura at intel.com>
>> Sent: June 17, 2022 1:15 AM
>> To: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; Vetter,
>> Daniel <daniel.vetter at intel.com>
>> Cc: Hellstrom, Thomas <thomas.hellstrom at intel.com>; Wilson, Chris P
>> <chris.p.wilson at intel.com>; jason at jlekstrand.net;
>> christian.koenig at amd.com; Brost, Matthew <matthew.brost at intel.com>;
>> Ursulin, Tvrtko <tvrtko.ursulin at intel.com>; Auld, Matthew
>> <matthew.auld at intel.com>; Landwerlin, Lionel G
>> <lionel.g.landwerlin at intel.com>; Zanoni, Paulo R
>> <paulo.r.zanoni at intel.com>; Zeng, Oak <oak.zeng at 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 at 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_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.
>> + */
>> + __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