[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