From: "Ghimiray, Himal Prasad" <himal.prasad.ghimiray@intel.com>
To: Matthew Brost <matthew.brost@intel.com>,
Francois Dugast <francois.dugast@intel.com>
Cc: <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 22:06:13 +0530 [thread overview]
Message-ID: <f1708bfa-3648-4a56-b549-0a4561ced93e@intel.com> (raw)
In-Reply-To: <ac0vyICB0GIsteSi@gsse-cloud1.jf.intel.com>
On 01-04-2026 20:16, Matthew Brost wrote:
> 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
Hi Francois and Matt,
Thanks for pointing it out. Will add a proper documentation explaining
the use case and all the details in future revisions.
>
>>
>> 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 16:36 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
2026-04-01 16:36 ` Ghimiray, Himal Prasad [this message]
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=f1708bfa-3648-4a56-b549-0a4561ced93e@intel.com \
--to=himal.prasad.ghimiray@intel.com \
--cc=arvind.yadav@intel.com \
--cc=francois.dugast@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--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