2016-07-12 6:59 GMT+09:00 Chris Wilson chris@chris-wilson.co.uk:
When dealing with user interfaces that utilize explicit fences, it is convenient to sometimes create those fences after the fact, i.e. to query the dma-buf for the current set of implicit fences, encapsulate those into a sync_file and hand that fd back to userspace. Correspondingly, being able to add an explicit fence back into the mix of fences being tracked by the dma-buf allows that userspace fence to be included in any implicit tracking.
Regarding import fence, explicit fence can be corresponded to one of sub-allocated blocks of a DMA buffer. What if user-space requested import fence with a fence corresponding to a sub-allocated block? As you know, implicit fence is always corresponded to one DMA buffer not sub block of it. I guess there may be other things you should consider for import fence interface.
Signed-off-by: Chris Wilson chris@chris-wilson.co.uk Cc: Gustavo Padovan gustavo.padovan@collabora.co.uk Cc: Rob Clark robdclark@gmail.com Cc: Sumit Semwal sumit.semwal@linaro.org Cc: Daniel Vetter daniel.vetter@ffwll.ch Cc: dri-devel@lists.freedesktop.org
Gustavo, could you look at the sync-file/fence-array handling? There's definitely room for a cleaner sync_file_create() API.
I was thinking about this for the "why not sync-file" question Gustavo posed for the vgem_fences. I wanted to add an ioctl to the vgem to allow exporting and creating fences from sync-file for testing passing explicit userspaces around between drivers, and realised that I was just writing a generic mechanism that only required dma-buf.
Whilst this interface could be used for lazily creating explicit fences, drivers will also likely want to support specific ioctl to skip the dmabuf creation, I think this interfaces will be useful with the vgem fences for testing sync_file handling in drivers (on i915 at the moment, my tests for sync_file involve sleeping and a few white lies). So fulfilling a similar role in driver testing to debugfs/sw_sync? (sw_sync is still more apt for testing timelines etc, vgem feels more apt for ease of testing rendering.) -Chris
drivers/dma-buf/dma-buf.c | 100 +++++++++++++++++++++++++++++++++++++++++++ include/uapi/linux/dma-buf.h | 9 ++++ 2 files changed, 109 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 41fbce0c273a..6f066a8affd7 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -26,11 +26,13 @@ #include <linux/slab.h> #include <linux/dma-buf.h> #include <linux/fence.h> +#include <linux/fence-array.h> #include <linux/anon_inodes.h> #include <linux/export.h> #include <linux/debugfs.h> #include <linux/module.h> #include <linux/seq_file.h> +#include <linux/sync_file.h> #include <linux/poll.h> #include <linux/reservation.h> #include <linux/mm.h> @@ -254,6 +256,97 @@ out: return events; }
+static long dma_buf_import_fence_ioctl(struct dma_buf *dmabuf,
struct dma_buf_fence __user *arg)+{
struct reservation_object *resv = dmabuf->resv;struct dma_buf_fence cmd;struct fence *fence;int ret;if (copy_from_user(&cmd, arg, sizeof(cmd)))return -EFAULT;fence = NULL;//fence = sync_file_get_fence(cmd.fd);
Your mistake?
Thanks, Inki Dae
if (!fence)return -EINVAL;