Re: [Mesa-dev] [PATCH 3/3] dma-buf: Add an API for exporting sync files (v8)

2021-03-23 Thread Jason Ekstrand
On Tue, Mar 23, 2021 at 2:06 PM Simon Ser  wrote:
>
> From a user-space point-of-view, this looks super useful! The uAPI sounds
> good to me.
>
> Acked-by: Simon Ser 
>
> Would be nice to have some short docs as well. Here's an example of a
> patch adding some docs for an ioctl [1], if you aren't familiar with
> that. I think just some basic stuff (description, which parameters are
> in/out, what the flags are) would be great.

Good call.  v9 will have docs.

--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/3] dma-buf: Add an API for exporting sync files (v8)

2021-03-23 Thread Simon Ser
>From a user-space point-of-view, this looks super useful! The uAPI sounds
good to me.

Acked-by: Simon Ser 

Would be nice to have some short docs as well. Here's an example of a
patch adding some docs for an ioctl [1], if you aren't familiar with
that. I think just some basic stuff (description, which parameters are
in/out, what the flags are) would be great.

[1]: https://patchwork.freedesktop.org/patch/401951/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


Re: [Mesa-dev] [PATCH 3/3] dma-buf: Add an API for exporting sync files (v8)

2021-03-23 Thread Jason Ekstrand
Adding mesa-dev and wayland-devel for broader circulation.

On Wed, Mar 17, 2021 at 5:19 PM Jason Ekstrand  wrote:
>
> Modern userspace APIs like Vulkan are built on an explicit
> synchronization model.  This doesn't always play nicely with the
> implicit synchronization used in the kernel and assumed by X11 and
> Wayland.  The client -> compositor half of the synchronization isn't too
> bad, at least on intel, because we can control whether or not i915
> synchronizes on the buffer and whether or not it's considered written.
>
> The harder part is the compositor -> client synchronization when we get
> the buffer back from the compositor.  We're required to be able to
> provide the client with a VkSemaphore and VkFence representing the point
> in time where the window system (compositor and/or display) finished
> using the buffer.  With current APIs, it's very hard to do this in such
> a way that we don't get confused by the Vulkan driver's access of the
> buffer.  In particular, once we tell the kernel that we're rendering to
> the buffer again, any CPU waits on the buffer or GPU dependencies will
> wait on some of the client rendering and not just the compositor.
>
> This new IOCTL solves this problem by allowing us to get a snapshot of
> the implicit synchronization state of a given dma-buf in the form of a
> sync file.  It's effectively the same as a poll() or I915_GEM_WAIT only,
> instead of CPU waiting directly, it encapsulates the wait operation, at
> the current moment in time, in a sync_file so we can check/wait on it
> later.  As long as the Vulkan driver does the sync_file export from the
> dma-buf before we re-introduce it for rendering, it will only contain
> fences from the compositor or display.  This allows to accurately turn
> it into a VkFence or VkSemaphore without any over- synchronization.
>
> v2 (Jason Ekstrand):
>  - Use a wrapper dma_fence_array of all fences including the new one
>when importing an exclusive fence.
>
> v3 (Jason Ekstrand):
>  - Lock around setting shared fences as well as exclusive
>  - Mark SIGNAL_SYNC_FILE as a read-write ioctl.
>  - Initialize ret to 0 in dma_buf_wait_sync_file
>
> v4 (Jason Ekstrand):
>  - Use the new dma_resv_get_singleton helper
>
> v5 (Jason Ekstrand):
>  - Rename the IOCTLs to import/export rather than wait/signal
>  - Drop the WRITE flag and always get/set the exclusive fence
>
> v6 (Jason Ekstrand):
>  - Drop the sync_file import as it was all-around sketchy and not nearly
>as useful as import.
>  - Re-introduce READ/WRITE flag support for export
>  - Rework the commit message
>
> v7 (Jason Ekstrand):
>  - Require at least one sync flag
>  - Fix a refcounting bug: dma_resv_get_excl() doesn't take a reference
>  - Use _rcu helpers since we're accessing the dma_resv read-only
>
> v8 (Jason Ekstrand):
>  - Return -ENOMEM if the sync_file_create fails
>  - Predicate support on IS_ENABLED(CONFIG_SYNC_FILE)
>
> Signed-off-by: Jason Ekstrand 
> ---
>  drivers/dma-buf/dma-buf.c| 62 
>  include/uapi/linux/dma-buf.h |  6 
>  2 files changed, 68 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index f264b70c383eb..a5e4b0b6a049c 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -362,6 +363,62 @@ static long dma_buf_set_name(struct dma_buf *dmabuf, 
> const char __user *buf)
> return ret;
>  }
>
> +#if IS_ENABLED(CONFIG_SYNC_FILE)
> +static long dma_buf_export_sync_file(struct dma_buf *dmabuf,
> +void __user *user_data)
> +{
> +   struct dma_buf_sync_file arg;
> +   struct dma_fence *fence = NULL;
> +   struct sync_file *sync_file;
> +   int fd, ret;
> +
> +   if (copy_from_user(, user_data, sizeof(arg)))
> +   return -EFAULT;
> +
> +   if (arg.flags & ~DMA_BUF_SYNC_RW)
> +   return -EINVAL;
> +
> +   if ((arg.flags & DMA_BUF_SYNC_RW) == 0)
> +   return -EINVAL;
> +
> +   fd = get_unused_fd_flags(O_CLOEXEC);
> +   if (fd < 0)
> +   return fd;
> +
> +   if (arg.flags & DMA_BUF_SYNC_WRITE) {
> +   ret = dma_resv_get_singleton_rcu(dmabuf->resv, );
> +   if (ret)
> +   goto err_put_fd;
> +   } else if (arg.flags & DMA_BUF_SYNC_READ) {
> +   fence = dma_resv_get_excl_rcu(dmabuf->resv);
> +   }
> +
> +   if (!fence)
> +   fence = dma_fence_get_stub();
> +
> +   sync_file = sync_file_create(fence);
> +
> +   dma_fence_put(fence);
> +
> +   if (!sync_file) {
> +   ret = -ENOMEM;
> +   goto err_put_fd;
> +   }
> +
> +   fd_install(fd, sync_file->file);
> +
> +   arg.fd = fd;
> +   if (copy_to_user(user_data, , sizeof(arg)))
> +   return -EFAULT;
> +
> +