I feel this is slightly better than LOW_LATENCY as low latency is a result
Of applying some frequency policy designed for compute task.
A related question is, does this new policy affect power consumption? Usually
Higher frequency implies higher power.
Do we only want to keep such frequency policy during submission time, or
Same policy is intended for whole execution time?
The answer of above question would lead to some interface design such as
Whether we need to introduce interface to disable the compute frequency policy.
> +
> __guc_exec_queue_policy_start_klv(&policy, q->guc->id);
> __guc_exec_queue_policy_add_priority(&policy,
> xe_exec_queue_prio_to_guc[prio]);
>
> __guc_exec_queue_policy_add_execution_quantum(&polic
> y, timeslice_us);
>
> __guc_exec_queue_policy_add_preemption_timeout(&polic
> y, preempt_timeout_us);
> + __guc_exec_queue_policy_add_slpc_ctx_freq_req(&policy,
> slpc_ctx_freq_req);
>
> xe_guc_ct_send(&guc->ct, (u32 *)&policy.h2g,
> __guc_exec_queue_policy_action_size(&policy),
> 0, 0);
> diff --git a/include/uapi/drm/xe_drm.h
> b/include/uapi/drm/xe_drm.h
> index f62689ca861a..bd0150d2200c 100644
> --- a/include/uapi/drm/xe_drm.h
> +++ b/include/uapi/drm/xe_drm.h
> @@ -1097,6 +1097,7 @@ struct drm_xe_vm_bind {
> * .engine_class = DRM_XE_ENGINE_CLASS_RENDER,
> * };
> * struct drm_xe_exec_queue_create exec_queue_create = {
> + * .flags = DRM_XE_EXEC_QUEUE_LOW_LATENCY_HINT or 0
> * .extensions = 0,
> * .vm_id = vm,
> * .num_bb_per_exec = 1,
> @@ -1110,7 +1111,6 @@ struct drm_xe_exec_queue_create {
> #define DRM_XE_EXEC_QUEUE_EXTENSION_SET_PROPERTY
> 0
> #define DRM_XE_EXEC_QUEUE_SET_PROPERTY_PRIORITY
> 0
> #define DRM_XE_EXEC_QUEUE_SET_PROPERTY_TIMESLICE
> 1
> -
> /** @extensions: Pointer to the first extension struct, if any
> */
> __u64 extensions;
>
> @@ -1123,6 +1123,7 @@ struct drm_xe_exec_queue_create {
> /** @vm_id: VM to use for this exec queue */
> __u32 vm_id;
>
> +#define DRM_XE_EXEC_QUEUE_LOW_LATENCY_HINT (0x1
> << 1)
I wonder why flag can't start from (0x1 << 0) here.
Yes I did see the v2 comment of below:
- DRM_XE_EXEC_QUEUE_LOW_LATENCY_HINT 1 is already planned
for other hint(Szymon)
but this is regarding the definition of a flag used in exec_queue_create, and this
is the first time we use this flag in *this* uAPI. It shouldn't conflict with UMD's usage of hint flags
in *other* uAPI
> /** @flags: MBZ */
Remove this MBZ comment
Oak
> __u32 flags;
>
> --
> 2.34.1
