From: Matthew Brost <matthew.brost@intel.com>
To: Francois Dugast <francois.dugast@intel.com>
Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>,
<intel-xe@lists.freedesktop.org>,
<thomas.hellstrom@linux.intel.com>, <stuart.summers@intel.com>,
<arvind.yadav@intel.com>, <tejas.upadhyay@intel.com>
Subject: Re: [RFC 12/15] drm/xe/uapi: Add access counter parameter extension for exec queue
Date: Wed, 1 Apr 2026 07:46:32 -0700 [thread overview]
Message-ID: <ac0vyICB0GIsteSi@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <acKevKB0mEbwGLqH@fdugast-desk>
On Tue, Mar 24, 2026 at 03:25:09PM +0100, Francois Dugast wrote:
> Hi Himal,
>
> On Wed, Mar 18, 2026 at 01:14:53PM +0530, Himal Prasad Ghimiray wrote:
> > Introduce DRM_XE_EXEC_QUEUE_EXTENSION_SET_ACC_PARAM extension to allow
> > userspace to configure access counter notifications per exec queue.
> >
> > The extension provides:
> > - trigger: Access counter trigger threshold
> > - notify: Access counter notify threshold
> > - granularity: Access counter granularity level
> >
> > These parameters control hardware access counter behavior for memory
> > access pattern tracking and optimization hints. Userspace can configure
> > different thresholds per exec queue based on workload characteristics.
> >
> > UAPI changes:
> > - Add drm_xe_exec_queue_set_acc_param structure
> > - Add DRM_XE_EXEC_QUEUE_EXTENSION_SET_ACC_PARAM extension ID
> >
> > KMD changes:
> > - Add exec_queue_user_ext_set_acc_param() handler
> > - Store parameters in xe_exec_queue.acc structure
> > - Register handler in extension function table
> >
> > Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
> > ---
> > drivers/gpu/drm/xe/xe_exec_queue.c | 27 ++++++++++++++++
> > drivers/gpu/drm/xe/xe_exec_queue_types.h | 9 ++++++
> > include/uapi/drm/xe_drm.h | 39 ++++++++++++++++++++++++
> > 3 files changed, 75 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_exec_queue.c b/drivers/gpu/drm/xe/xe_exec_queue.c
> > index b287d0e0e60a..815e82011c6d 100644
> > --- a/drivers/gpu/drm/xe/xe_exec_queue.c
> > +++ b/drivers/gpu/drm/xe/xe_exec_queue.c
> > @@ -1080,6 +1080,32 @@ static int exec_queue_user_ext_check_final(struct xe_exec_queue *q, u64 properti
> > return 0;
> > }
> >
> > +static int exec_queue_user_ext_set_acc_param(struct xe_device *xe,
> > + struct xe_exec_queue *q,
> > + u64 extension, u64 *properties)
> > +{
> > + u64 __user *address = u64_to_user_ptr(extension);
> > + struct drm_xe_exec_queue_set_acc_param ext;
> > + int err;
> > +
> > + if (!xe->info.has_access_counter)
> > + return -EINVAL;
> > +
> > + err = copy_from_user(&ext, address, sizeof(ext));
> > + if (XE_IOCTL_DBG(xe, err))
> > + return -EFAULT;
> > +
> > + if (XE_IOCTL_DBG(xe, ext.pad1 || ext.pad2))
> > + return -EINVAL;
> > +
> > + /* Store access counter parameters in exec queue */
> > + q->acc.trigger = ext.trigger;
> > + q->acc.notify = ext.notify;
> > + q->acc.granularity = ext.granularity;
> > +
> > + return 0;
> > +}
> > +
> > static int exec_queue_user_ext_set_property(struct xe_device *xe,
> > struct xe_exec_queue *q,
> > u64 extension, u64 *properties)
> > @@ -1123,6 +1149,7 @@ typedef int (*xe_exec_queue_user_extension_fn)(struct xe_device *xe,
> >
> > static const xe_exec_queue_user_extension_fn exec_queue_user_extension_funcs[] = {
> > [DRM_XE_EXEC_QUEUE_EXTENSION_SET_PROPERTY] = exec_queue_user_ext_set_property,
> > + [DRM_XE_EXEC_QUEUE_EXTENSION_SET_ACC_PARAM] = exec_queue_user_ext_set_acc_param,
> > };
> >
> > #define MAX_USER_EXTENSIONS 16
> > diff --git a/drivers/gpu/drm/xe/xe_exec_queue_types.h b/drivers/gpu/drm/xe/xe_exec_queue_types.h
> > index 8ce78e0b1d50..3f10e3371e5a 100644
> > --- a/drivers/gpu/drm/xe/xe_exec_queue_types.h
> > +++ b/drivers/gpu/drm/xe/xe_exec_queue_types.h
> > @@ -239,6 +239,15 @@ struct xe_exec_queue {
> >
> > /** @replay_state: GPU hang replay state */
> > void *replay_state;
> > + /** @acc: Access counter parameters */
> > + struct {
> > + /** @acc.trigger: Access counter trigger threshold */
> > + u16 trigger;
> > + /** @acc.notify: Access counter notify threshold */
> > + u16 notify;
> > + /** @acc.granularity: Access counter granularity */
> > + u8 granularity;
> > + } acc;
> >
> > /** @ops: submission backend exec queue operations */
> > const struct xe_exec_queue_ops *ops;
> > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> > index f8b2afb20540..19447ba10b1d 100644
> > --- a/include/uapi/drm/xe_drm.h
> > +++ b/include/uapi/drm/xe_drm.h
> > @@ -1337,6 +1337,7 @@ struct drm_xe_vm_bind {
> > */
> > struct drm_xe_exec_queue_create {
> > #define DRM_XE_EXEC_QUEUE_EXTENSION_SET_PROPERTY 0
> > +#define DRM_XE_EXEC_QUEUE_EXTENSION_SET_ACC_PARAM 1
> > #define DRM_XE_EXEC_QUEUE_SET_PROPERTY_PRIORITY 0
> > #define DRM_XE_EXEC_QUEUE_SET_PROPERTY_TIMESLICE 1
> > #define DRM_XE_EXEC_QUEUE_SET_PROPERTY_PXP_TYPE 2
> > @@ -1377,6 +1378,44 @@ struct drm_xe_exec_queue_create {
> > __u64 reserved[2];
> > };
> >
> > +/** enum drm_xe_access_counter_granularity - Xe access counter granularity */
> > +enum drm_xe_access_counter_granularity {
> > + /** @DRM_XE_ACCESS_COUNTER_GRANULARITY_128K: 128K granularity */
> > + DRM_XE_ACCESS_COUNTER_GRANULARITY_128K,
> > + /** @DRM_XE_ACCESS_COUNTER_GRANULARITY_2M: 2M granularity */
> > + DRM_XE_ACCESS_COUNTER_GRANULARITY_2M,
> > + /** @DRM_XE_ACCESS_COUNTER_GRANULARITY_16M: 16M granularity */
> > + DRM_XE_ACCESS_COUNTER_GRANULARITY_16M,
> > + /** @DRM_XE_ACCESS_COUNTER_GRANULARITY_64M: 64M granularity */
> > + DRM_XE_ACCESS_COUNTER_GRANULARITY_64M,
> > +};
> > +
> > +/**
> > + * struct drm_xe_exec_queue_set_acc_param - Access counter parameters extension
> > + *
> > + * Extension to configure access counter notifications for an exec queue.
> > + * Used with DRM_XE_EXEC_QUEUE_EXTENSION_SET_ACC_PARAM.
> > + */
>
> Sorry if this is already documented elsewhere but I think we would need more
> details about access counters from a user perspective:
>
> - why using them?
> - what is different when using an exec queue after setting access counters?
> - what is the typical flow, maybe with pseudo code?
> - how is @trigger used, what is triggered, on what condition?
> - how is @notify used, what is notified, on what condition?
> - are notifications going to user space or only to internal and trace?
> - what happens if access counters are not supported?
> - can access counters be reset? removed?
+1 to Francois comments. I never really understood the i915 access
counter interfaces on exec queues and without an explaination like
Francois is suggesting, I don't unerstand Xe's uAPI without reverse
engineering the code.
Matt
>
> Thanks,
> Francois
>
> > +struct drm_xe_exec_queue_set_acc_param {
> > + /** @base: base user extension */
> > + struct drm_xe_user_extension base;
> > +
> > + /** @trigger: Access counter trigger threshold */
> > + __u16 trigger;
> > +
> > + /** @notify: Access counter notify threshold */
> > + __u16 notify;
> > +
> > + /** @granularity: granularity, enum @drm_xe_access_counter_granularity */
> > + __u8 granularity;
> > +
> > + /** @pad1: MBZ */
> > + __u8 pad1;
> > +
> > + /** @pad2: MBZ */
> > + __u16 pad2;
> > +};
> > +
> > /**
> > * struct drm_xe_exec_queue_destroy - Input of &DRM_IOCTL_XE_EXEC_QUEUE_DESTROY
> > */
> > --
> > 2.34.1
> >
next prev parent reply other threads:[~2026-04-01 14:46 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-18 7:44 [RFC 00/15] drm/xe: Access counter consumer layer Himal Prasad Ghimiray
2026-03-18 7:34 ` ✗ CI.checkpatch: warning for " Patchwork
2026-03-18 7:35 ` ✗ CI.KUnit: failure " Patchwork
2026-03-18 7:44 ` [RFC 01/15] drm/xe: Add xe_usm_queue generic USM circular buffer Himal Prasad Ghimiray
2026-04-01 21:28 ` Matthew Brost
2026-04-06 4:46 ` Ghimiray, Himal Prasad
2026-03-18 7:44 ` [RFC 02/15] drm/xe/pagefault: Use xe_usm_queue helpers Himal Prasad Ghimiray
2026-03-18 7:44 ` [RFC 03/15] drm/xe: Stub out new access_counter layer Himal Prasad Ghimiray
2026-04-02 21:46 ` Matthew Brost
2026-04-06 5:28 ` Ghimiray, Himal Prasad
2026-03-18 7:44 ` [RFC 04/15] drm/xe: Implement xe_access_counter_init Himal Prasad Ghimiray
2026-03-18 7:44 ` [RFC 05/15] drm/xe: Implement xe_access_counter_handler Himal Prasad Ghimiray
2026-04-03 2:06 ` Matthew Brost
2026-03-18 7:44 ` [RFC 06/15] drm/xe: Extract xe_vma_lock_and_validate helper Himal Prasad Ghimiray
2026-04-01 22:03 ` Matthew Brost
2026-03-18 7:44 ` [RFC 07/15] drm/xe: Move ASID to FAULT VM lookup to xe_device Himal Prasad Ghimiray
2026-04-02 21:50 ` Matthew Brost
2026-04-07 6:41 ` Ghimiray, Himal Prasad
2026-03-18 7:44 ` [RFC 08/15] drm/xe: Implement xe_access_counter_queue_work Himal Prasad Ghimiray
2026-04-01 21:10 ` Matthew Brost
2026-04-01 22:01 ` Matthew Brost
2026-04-01 22:11 ` Matthew Brost
2026-04-02 22:06 ` Matthew Brost
2026-03-18 7:44 ` [RFC 09/15] drm/xe/trace: Add xe_vma_acc trace event for access counter notifications Himal Prasad Ghimiray
2026-04-03 1:01 ` Matthew Brost
2026-03-18 7:44 ` [RFC 10/15] drm/xe/svm: Handle svm ranges on access ctr trigger Himal Prasad Ghimiray
2026-04-03 0:25 ` Matthew Brost
2026-03-18 7:44 ` [RFC 11/15] drm/xe: Add xe_guc_access_counter layer Himal Prasad Ghimiray
2026-04-02 21:27 ` Matthew Brost
2026-03-18 7:44 ` [RFC 12/15] drm/xe/uapi: Add access counter parameter extension for exec queue Himal Prasad Ghimiray
2026-03-24 14:25 ` Francois Dugast
2026-04-01 14:46 ` Matthew Brost [this message]
2026-04-01 16:36 ` Ghimiray, Himal Prasad
2026-03-18 7:44 ` [RFC 13/15] drm/xe/lrc: Pass exec_queue to xe_lrc_create for access counter params Himal Prasad Ghimiray
2026-03-18 7:44 ` [RFC 14/15] drm/xe/vm: Add xe_vma_supports_access_ctr() helper Himal Prasad Ghimiray
2026-03-18 7:44 ` [RFC 15/15] drm/xe/pt: Set NC PTE bit for VMAs ineligible for access counting Himal Prasad Ghimiray
2026-04-03 0:09 ` Matthew Brost
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=ac0vyICB0GIsteSi@gsse-cloud1.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=arvind.yadav@intel.com \
--cc=francois.dugast@intel.com \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=stuart.summers@intel.com \
--cc=tejas.upadhyay@intel.com \
--cc=thomas.hellstrom@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox