On Friday, May 6th, 2022 at 20:02, Jason Ekstrand <jason@xxxxxxxxxxxxxx> wrote:
> diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h
> index 46f1e3e98b02..70e213a0d7d9 100644
> --- a/include/uapi/linux/dma-buf.h
> +++ b/include/uapi/linux/dma-buf.h
> @@ -96,6 +96,24 @@ struct dma_buf_sync {
> * dma-buf for waiting later instead of waiting immediately. This is
> * useful for modern graphics APIs such as Vulkan which assume an explicit
> * synchronization model but still need to inter-operate with dma-buf.
> + *
> + * The intended usage pattern is the following:
> + *
> + * 1. Export a sync_file with flags corresponding to the expected GPU usage
> + * via DMA_BUF_IOCTL_EXPORT_SYNC_FILE.
> + *
> + * 2. Submit rendering work which uses the dma-buf. The work should wait on
> + * the exported sync file before rendering and produce another sync_file
> + * when complete.
> + *
> + * 3. Import the rendering-complete sync_file into the dma-buf with flags
> + * corresponding to the GPU usage via DMA_BUF_IOCTL_EXPORT_SYNC_FILE.
This should read DMA_BUF_IOCTL_IMPORT_SYNC_FILE I think?
> + * Unlike doing implicit synchronization via a GPU kernel driver's exec ioctl,
> + * the above is not a single atomic operation. If userspace wants to ensure
> + * ordering via these fences, it is the respnosibility of userspace to use
> + * locks or other mechanisms to ensure that no other context adds fences or
> + * submits work between steps 1 and 3 above.
> */
> struct dma_buf_export_sync_file {
> /**
