[PATCH 07/17] drm/xe/oa: OA stream initialization (OAG)

[Lionel Landwerlin]

On 28/05/2024 08:27, Dixit, Ashutosh wrote:
> On Mon, 27 May 2024 00:04:21 -0700, Lionel Landwerlin wrote:
> Hi Lionel,
>
>>> +static int xe_oa_stream_init(struct xe_oa_stream *stream,
>>> +			     struct xe_oa_open_param *param)
>>> +{
> /snip/
>
>>> +	stream->k_exec_q = xe_exec_queue_create(stream->oa->xe, NULL,
>>> +						BIT(stream->hwe->logical_instance), 1,
>>> +						stream->hwe, EXEC_QUEUE_FLAG_KERNEL, 0);
>>
>> Hi Ashutosh,
>>
>> On i915 the changes of configuration were pipelined in the application's
>> execution just like any other submission.
>>
>> Creating another queue completely unsynchronized from the application's
>> submissions makes this non usable in my opinion.
> As we discussed previously, the plan here is to provide a drm_xe_sync array,
> through stream properties, which can use to synchronize OA programming with
> workload submisson.
>
> Would that not work? If not, we can do what was done in i915. But note that
> i915 still has unresolved hangs, which I believe are due to the spinner
> running on the application engine (iirc repeatedly opening/closing an OA
> stream will hang in i915, though it could be due to other i915
> complexity). That is why thought using drm_xe_sync array is both safer and
> more standard way of doing what we want to achieve.
>
> Basically the output sync object will be signalled after registers are
> programmed and also any additional OA programming delay (which is
> implemented in i915 using the spinner).
>
> This would be done both for OA stream open and changing OA stream
> configuration.


Thanks for the details.

But it's not what is implemented here.

Just letting you know, because we cannot use the current ioctl because 
it doesn't behave as we expect


-Lionel


>
> Thanks.
> --
> Ashutosh