[Intel-xe] [PATCH 00/10] Add OA functionality to Xe

Lionel Landwerlin lionel.g.landwerlin at intel.com
Fri Sep 1 07:55:58 UTC 2023


Hi Ashutosh,

I just noticed this change in the uAPI :

@@ -298,6 +305,7 @@  struct drm_xe_query_gts {
  		__u64 native_mem_regions;	/* bit mask of instances from drm_xe_query_mem_usage */
  		__u64 slow_mem_regions;		/* bit mask of instances from drm_xe_query_mem_usage */
  		__u64 inaccessible_mem_regions;	/* bit mask of instances from drm_xe_query_mem_usage */
+ __u64 oa_timestamp_freq;
  		__u64 reserved[8];
  	} gts[];
  };


I think you need to remove one item from the reserved field so that the 
structure size doesn't change.

-Lionel

On 08/08/2023 05:41, Dixit, Ashutosh wrote:
> On Mon, 07 Aug 2023 18:31:49 -0700, Ashutosh Dixit wrote:
> Hi Umesh/Lionel,
>
>> This patchset is the initial port of i915 perf/OA functionality to the Xe
>> driver. It has been tested against the following IGT patch:
>>
>> https://patchwork.freedesktop.org/series/121082/
>>
>> The following features in i915 have not been ported and will be added (as
>> new patches) if/as they are needed:
>>
>> * Inline batch submission on stream exec_queue/hw_engine
>> * NOA wait
> About these two in the "not-yet-ported" feature list for Xe: In
> i915 when a stream engine is specified, requests are submitted "inline" to
> that engine whenever the OA stream is opened or reconfigured. This feature
> is at present not ported to Xe (see xe_oa_submit_bb()).
>
> I have a couple of questions about this "inline submission":
>
> * Is inline submission a hard requirement? That is, in Xe can UMD's say
>    (completely outside OA uapi) fence till a segment of the workload
>    completes, then open/reconfigure the OA stream and then continue? If
>    UMD's are able to do this we don't need inline submission in Xe. If UMD's
>    cannot do this please explain why not.
>
> * If inline submission is indeed required, can we do away with NOA wait (as
>    implemented in daed3e44396d ("drm/i915/perf: implement active wait for
>    noa configurations")) or implement NOA wait differently in Xe? E.g. can
>    we expose a fence in the OA uapi and UMD's would be required to wait on
>    this fence/sync-object before continuing workload submissions after any
>    OA stream open/reconfiguration.
>
> The reason I am brining this up is because in i915 there are a couple of
> scary bugs around this which are still unresolved. E.g.:
>
> 	https://gitlab.freedesktop.org/drm/intel/-/issues/8746
> 	https://gitlab.freedesktop.org/drm/intel/-/issues/8190
>
> There is therefore reason to think if this functionality can be done
> differently in Xe (not to say these bugs will be carried over to Xe).
>
> Thanks.
> --
> Ashutosh
>
>> * GuC ctx id (guc_sw_ctx_id)
>> * CTX_R_PWR_CLK_STATE/GEN8_R_PWR_CLK_STATE
>> * hold_preemption (DRM_XE_OA_PROP_HOLD_PREEMPTION)
>> * sseu_config (DRM_XE_OA_PROP_GLOBAL_SSEU)
>> * Override gucrc (override_gucrc_mode)
>> * MTL bios_c6_setup
>> * ratelimits
>> * compat ioctl
>>
>> I am providing the following additional HAX patch (not part of this series)
>> to help review these patches:
>>
>> https://patchwork.freedesktop.org/patch/551683/?series=120100&rev=4
>>
>> The commit message in the above patch explains how it can be useful for
>> reviewing this series.
>>
>> Test-with:20230808010017.37819-1-ashutosh.dixit at intel.com
>>
>> v2: Fix build
>> v3: Rebase, due to s/xe_engine/xe_exec_queue/
>>
>> Ashutosh Dixit (10):
>>    drm/xe/oa: Introduce OA uapi
>>    drm/xe/oa: Add OA types
>>    drm/xe/oa: Add registers and GPU commands used by OA
>>    drm/xe/oa: Module init/exit and probe/remove
>>    drm/xe/oa: Add/remove config ioctl's
>>    drm/xe/oa: Start implementing OA stream open ioctl
>>    drm/xe/oa: OA stream initialization
>>    drm/xe/oa: Expose OA stream fd
>>    drm/xe/oa: Read file_operation
>>    drm/xe/oa: Implement queries
>>
>>   drivers/gpu/drm/xe/Makefile               |    1 +
>>   drivers/gpu/drm/xe/regs/xe_engine_regs.h  |    5 +
>>   drivers/gpu/drm/xe/regs/xe_gpu_commands.h |   27 +
>>   drivers/gpu/drm/xe/regs/xe_oa_regs.h      |  173 ++
>>   drivers/gpu/drm/xe/xe_device.c            |   16 +
>>   drivers/gpu/drm/xe/xe_device_types.h      |    4 +
>>   drivers/gpu/drm/xe/xe_gt_types.h          |    4 +
>>   drivers/gpu/drm/xe/xe_hw_engine_types.h   |    2 +
>>   drivers/gpu/drm/xe/xe_module.c            |    5 +
>>   drivers/gpu/drm/xe/xe_oa.c                | 2356 +++++++++++++++++++++
>>   drivers/gpu/drm/xe/xe_oa.h                |   28 +
>>   drivers/gpu/drm/xe/xe_oa_types.h          |  295 +++
>>   drivers/gpu/drm/xe/xe_query.c             |    5 +-
>>   include/uapi/drm/xe_drm.h                 |  257 ++-
>>   14 files changed, 3176 insertions(+), 2 deletions(-)
>>   create mode 100644 drivers/gpu/drm/xe/regs/xe_oa_regs.h
>>   create mode 100644 drivers/gpu/drm/xe/xe_oa.c
>>   create mode 100644 drivers/gpu/drm/xe/xe_oa.h
>>   create mode 100644 drivers/gpu/drm/xe/xe_oa_types.h
>>
>> --
>> 2.41.0
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-xe/attachments/20230901/3d1fbe21/attachment-0001.htm>


More information about the Intel-xe mailing list