[Intel-xe] [PATCH 01/10] drm/xe/oa: Introduce OA uapi

[Umesh Nerlige Ramappa]

On Tue, Aug 15, 2023 at 08:43:55PM -0700, Dixit, Ashutosh wrote:
>On Tue, 15 Aug 2023 19:21:23 -0700, Umesh Nerlige Ramappa wrote:
>>
>> On Tue, Aug 15, 2023 at 06:30:12PM -0700, Dixit, Ashutosh wrote:
>> > On Tue, 15 Aug 2023 18:11:55 -0700, Umesh Nerlige Ramappa wrote:
>> >>
>> >> >> +	/**
>> >> >> +	 * Multiple engines may be mapped to the same OA unit. The OA unit is
>> >> >> +	 * identified by class:instance of any engine mapped to it.
>> >> >> +	 *
>> >> >> +	 * This parameter specifies the engine class and must be passed along
>> >> >> +	 * with DRM_XE_OA_PROP_OA_ENGINE_INSTANCE.
>> >> >> +	 */
>> >> >> +	DRM_XE_OA_PROP_OA_ENGINE_CLASS,
>> >> >> +
>> >> >> +	/**
>> >> >> +	 * This parameter specifies the engine instance and must be passed along
>> >> >> +	 * with DRM_XE_OA_PROP_OA_ENGINE_CLASS.
>> >> >> +	 */
>> >> >> +	DRM_XE_OA_PROP_OA_ENGINE_INSTANCE,
>> >> >
>> >> > Because oa_unit_id has been introduced above in
>> >> > drm_xe_engine_class_instance, should we remove these engine class/instance
>> >> > properties? Since it seems OA streams can be opened directly against the oa
>> >> > unit identified by oa_unit_id. And the driver can itself figure out the
>> >> > engine class/instance from the oa_unit_id?
>> >>
>> >> Agree for the OA buffer use case.
>> >>
>> >> For query, we have used the class:instance to enable query support for
>> >> specific engine instance. If we can work around that somehow, then we can
>> >> do away with these 2 params. More like enable query for all engines that
>> >> belong to the OAG unit. For render, it is straight forward since we have
>> >> one render per OAG unit. For compute, multiple compute instances can map to
>> >> one OAG unit and only one instance can support the query. So user may want
>> >> to choose which instance that is. Although, I would just simplify it and
>> >> support only instance 0 of compute. If UMD is okay with it, then we should
>> >> be good.
>> >
>> > Can we enable the query (I guess "query" is MI_RPC) on all attached compute
>> > engines and have the UMD execute the query on any of the attached engines?
>> > Or is this mode of operation never been tried out before so risky?
>>
>> We cannot, since that is gated by a global configuration in HW that selects
>> a specific instance to enable the query for compute (ccs_select to be
>> specific). I think the limitation is that HW has only one OAC unit and only
>> one ccs can use it.
>
>OK. But iiuc there is also a context (or, in Xe, an exec_queue). So we
>should be able to turn on the query on the context/exec_queue hw_engine, no?
>Assuming more than one hw_engine in the context/exec_queue is an error?

The global config (ccs_select) needs to be applied at the context switch 
granularity which the KMD is unaware of. If the ccs_select configuration 
were a part of the context image, it would have been simpler. If we were 
to do this, it would have to be in the WA batch buffer in the context.  
The WA batch would run every context switch and would do an LRI on the 
global register. Possible, but hacky and architecturally incorrect since 
we would be modifying a global state from the context.

Regards,
Umesh


>
>Ashutosh
>
>> >>
>> >> Media engines do not support query, so we should be good for OAM.
>> >>
>> >> >
>> >> > Separately, there is also the question of whether we want to share the Xe
>> >> > OA IGT code with i915 as was done for this series. Since duplicating the
>> >> > IGT code as well as all the perf tools seems a bit much.
>> >> >
>> >> > Thanks.
>> >> > --
>> >> > Ashutosh