[Intel-xe] [18/21] drm/xe/uapi: More OA uapi fixes/additions

Lionel Landwerlin lionel.g.landwerlin at intel.com
Mon Oct 30 10:06:23 UTC 2023


On 27/10/2023 23:28, Dixit, Ashutosh wrote:
> On Fri, 20 Oct 2023 00:28:01 -0700, Lionel Landwerlin wrote:
>>>      struct drm_xe_oa_open_param {
>>> +	/** @extensions: Pointer to the first extension struct, if any */
>>> +	__u64 extensions;
>>> +
>>> +	/**
>>> +	 * @config_syncobj: (Output) handle to configuration syncobj
>>> +	 *
>>> +	 * Handle to a syncobj which the kernel will signal after stream
>>> +	 * configuration or re-configuration is complete (after return from
>>> +	 * the ioctl). This handle can be provided as a dependency to the
>>> +	 * next XE exec ioctl.
>>> +	 */
>>> +	__u32 config_syncobj;
>> So you're adding this, but there is no implementation for it?
> Not yet, but there will be. Actually the plan is to do this:
>
> struct drm_xe_oa_open_param {
> 	/** @extensions: Pointer to the first extension struct, if any */
> 	__u64 extensions;
>
> 	/** @num_syncs: Amount of struct drm_xe_sync in array. */
> 	__u32 num_syncs;
>
> 	/** @syncs: Pointer to struct drm_xe_sync array. */
> 	__u64 syncs;
>
> Which is exactly the same as what we see in drm_xe_vm_bind or
> drm_xe_exec. So the plan is to make perf_open behave exactly like an
> xe_exec which can be pipelined with other operations.

I don't think this is going to work because it means we have to close 
and reopen the stream every time we want to change the configuration.

It would need to be a separate ioctl on the perf file descriptor to be 
usable.

Otherwise we can't really pipeline anything since we have to drain the 
buffer until we can close it and reopen a new file descriptor.


-Lionel



More information about the Intel-xe mailing list