From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: intel-xe@lists.freedesktop.org
Cc: Francois Dugast <francois.dugast@intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: [Intel-xe] [PATCH 2/2] drm/xe/uapi: Use LR abbrev for long-running vms
Date: Fri, 24 Nov 2023 16:23:20 +0100 [thread overview]
Message-ID: <20231124152320.97115-3-thomas.hellstrom@linux.intel.com> (raw)
In-Reply-To: <20231124152320.97115-1-thomas.hellstrom@linux.intel.com>
Currently we're using "compute mode" for long running VMs using
using preempt-fences for memory management, and "fault mode" for long
running VMs using page faults.
Change this to use the terminology "long-running" abbreviated as LR for
long-running VMs. These VMs can then either be in preempt-fence mode or
fault mode. The user can force fault mode at creation time, but otherwise
the driver can choose to use fault- or preempt-fence mode for long-running
vms depending on the device capabilities. Initially unless fault-mode is
specified, the driver uses preempt-fence mode.
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Francois Dugast <francois.dugast@intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
---
drivers/gpu/drm/xe/xe_vm.c | 8 ++++----
include/uapi/drm/xe_drm.h | 20 +++++++++++++++++++-
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
index 5a4483bb00b1..e2e1fbe7f7d1 100644
--- a/drivers/gpu/drm/xe/xe_vm.c
+++ b/drivers/gpu/drm/xe/xe_vm.c
@@ -1919,7 +1919,7 @@ static int xe_vm_unbind(struct xe_vm *vm, struct xe_vma *vma,
}
#define ALL_DRM_XE_VM_CREATE_FLAGS (DRM_XE_VM_CREATE_FLAG_SCRATCH_PAGE | \
- DRM_XE_VM_CREATE_FLAG_COMPUTE_MODE | \
+ DRM_XE_VM_CREATE_FLAG_LR_MODE | \
DRM_XE_VM_CREATE_FLAG_ASYNC_DEFAULT | \
DRM_XE_VM_CREATE_FLAG_FAULT_MODE)
@@ -1955,7 +1955,7 @@ int xe_vm_create_ioctl(struct drm_device *dev, void *data,
args->flags & DRM_XE_VM_CREATE_FLAG_FAULT_MODE))
return -EINVAL;
- if (XE_IOCTL_DBG(xe, args->flags & DRM_XE_VM_CREATE_FLAG_COMPUTE_MODE &&
+ if (XE_IOCTL_DBG(xe, !(args->flags & DRM_XE_VM_CREATE_FLAG_LR_MODE) &&
args->flags & DRM_XE_VM_CREATE_FLAG_FAULT_MODE))
return -EINVAL;
@@ -1972,12 +1972,12 @@ int xe_vm_create_ioctl(struct drm_device *dev, void *data,
if (args->flags & DRM_XE_VM_CREATE_FLAG_SCRATCH_PAGE)
flags |= XE_VM_FLAG_SCRATCH_PAGE;
- if (args->flags & DRM_XE_VM_CREATE_FLAG_COMPUTE_MODE)
+ if (args->flags & DRM_XE_VM_CREATE_FLAG_LR_MODE)
flags |= XE_VM_FLAG_LR_MODE;
if (args->flags & DRM_XE_VM_CREATE_FLAG_ASYNC_DEFAULT)
flags |= XE_VM_FLAG_ASYNC_DEFAULT;
if (args->flags & DRM_XE_VM_CREATE_FLAG_FAULT_MODE)
- flags |= XE_VM_FLAG_LR_MODE | XE_VM_FLAG_FAULT_MODE;
+ flags |= XE_VM_FLAG_FAULT_MODE;
vm = xe_vm_create(xe, flags);
if (IS_ERR(vm))
diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
index 88f3aca02b08..4e9688c85db6 100644
--- a/include/uapi/drm/xe_drm.h
+++ b/include/uapi/drm/xe_drm.h
@@ -589,8 +589,26 @@ struct drm_xe_vm_create {
__u64 extensions;
#define DRM_XE_VM_CREATE_FLAG_SCRATCH_PAGE (1 << 0)
-#define DRM_XE_VM_CREATE_FLAG_COMPUTE_MODE (1 << 1)
+ /*
+ * An LR, or Long Running VM accepts exec submissions
+ * to its exec_queues that don't have an upper time limit on
+ * the job execution time. But exec submissions to these
+ * don't allow any of the flags DRM_XE_SYNC_FLAG_SYNCOBJ,
+ * DRM_XE_SYNC_FLAG_TIMELINE_SYNCOBJ, DRM_XE_SYNC_FLAG_DMA_BUF,
+ * used as out-syncobjs, that is, together with DRM_XE_SYNC_FLAG_SIGNAL.
+ * LR VMs can be forced to recoverable page-fault mode using
+ * DRM_XE_VM_CREATE_FLAG_FAULT_MODE, but the xe kernel driver is also
+ * allowed to silently enable DRM_XE_VM_CREATE_FLAG_FAULT_MODE.
+ */
+#define DRM_XE_VM_CREATE_FLAG_LR_MODE (1 << 1)
#define DRM_XE_VM_CREATE_FLAG_ASYNC_DEFAULT (1 << 2)
+ /*
+ * DRM_XE_VM_CREATE_FLAG_FAULT_MODE requires also
+ * DRM_XE_VM_CREATE_FLAG_LR_MODE. It allows memory to be allocated
+ * on demand when accessed, and also allows per-VM overcommit of memory.
+ * The xe driver does internally use recoverable pagefaults
+ * to implement this.
+ */
#define DRM_XE_VM_CREATE_FLAG_FAULT_MODE (1 << 3)
/** @flags: Flags */
__u32 flags;
--
2.41.0
next prev parent reply other threads:[~2023-11-24 15:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-24 15:23 [Intel-xe] [PATCH 0/2] drm/xe, drm_xe_uapi: VM mode renaming and uapi update Thomas Hellström
2023-11-24 15:23 ` [Intel-xe] [PATCH 1/2] drm/xe: Internally change the compute_mode and no_dma_fence mode naming Thomas Hellström
2023-11-24 17:04 ` Zeng, Oak
2023-11-24 17:44 ` Zeng, Oak
2023-11-27 11:55 ` Thomas Hellström
2023-11-24 15:23 ` Thomas Hellström [this message]
2023-11-24 17:07 ` [Intel-xe] [PATCH 2/2] drm/xe/uapi: Use LR abbrev for long-running vms Zeng, Oak
2023-11-24 17:33 ` [Intel-xe] ✓ CI.Patch_applied: success for drm/xe, drm_xe_uapi: VM mode renaming and uapi update Patchwork
2023-11-24 17:33 ` [Intel-xe] ✓ CI.checkpatch: " Patchwork
2023-11-24 17:34 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-11-24 17:42 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-11-24 17:42 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-11-24 17:43 ` [Intel-xe] ✓ CI.checksparse: " Patchwork
2023-11-24 18:18 ` [Intel-xe] ✗ CI.BAT: failure " Patchwork
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=20231124152320.97115-3-thomas.hellstrom@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=francois.dugast@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=rodrigo.vivi@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.