drm sync objects cleaned up
Subsystems (6)
This set of sync object patches should address most of the issues raised in review.
The major changes:
Race on destroy should be gone,
Documentation fixups
amdgpu internal use p instead of adev fixups
My plans are to write some igt tests this week, and try to get some more review on what the API should allow (should I lock it down to drm syncobj is just semaphores for now).
Dave.
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Dave Airlie
maintainerPATCH 1/8 sync_file: add type/flags to sync file object creation.
From: Dave Airlie <[email protected]>
This allows us to create sync files with different semantics, and clearly define the interoperation between them it also provides flags to allow for tweaks on those semantics.
This provides a validation interface for drivers that accept types from userspace so they can return EINVAL instead of ENOMEM.
This provides an ioctl for userspace to retrieve the type/flags of an object it may recieve from somewhere else.
--- Documentation/driver-api/dma-buf.rst | 6 ++++ drivers/dma-buf/sw_sync.c | 2 +- drivers/dma-buf/sync_file.c | 64 +++++++++++++++++++++++++++++++++--- drivers/gpu/drm/drm_atomic.c | 2 +- include/linux/sync_file.h | 9 ++++- include/uapi/linux/sync_file.h | 27 +++++++++++++++ 6 files changed, 103 insertions(+), 7 deletions(-)
Documentation/driver-api/dma-buf.rst +6 -0
@@ -163,3 +163,9 @@ DMA Fence uABI/Sync File .. kernel-doc:: include/linux/sync_file.h :internal: + +Sync File IOCTL Definitions +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: include/uapi/linux/sync_file.h + :internal:
drivers/dma-buf/sw_sync.c +1 -1
@@ -315,7 +315,7 @@ static long sw_sync_ioctl_create_fence(struct sync_timeline *obj, goto err; } - sync_file =sync_file_create (&pt->base); + sync_file =sync_file_create (&pt->base,SYNC_FILE_TYPE_FENCE ,0 );dma_fence_put (&pt->base);if (!sync_file) { err = -ENOMEM ;
drivers/dma-buf/sync_file.c +60 -4
111 lines not on this page · raw message
drivers/gpu/drm/drm_atomic.c +1 -1
@@ -1917,7 +1917,7 @@ static int setup_out_fence(struct drm_out_fence_state *fence_state,if (put_user (fence_state->fd, fence_state->out_fence_ptr))return -EFAULT ; - fence_state->sync_file =sync_file_create (fence); + fence_state->sync_file =sync_file_create (fence,SYNC_FILE_TYPE_FENCE ,0 );if (!fence_state->sync_file)return -ENOMEM ;
include/linux/sync_file.h +8 -1
@@ -20,6 +20,8 @@#include <linux/spinlock.h> #include <linux/dma-fence.h> #include <linux/dma-fence-array.h> +#include <uapi/linux/sync_file.h> +/** * struct sync_file - sync file to export to the userspace
@@ -30,6 +32,8 @@* @wq: wait queue for fence signaling * @fence: fence with the fences in the sync_file * @cb: fence callback information +* @type: sync file type +* @flags: flags used to create sync file */ struct sync_file {struct file *file;
@@ -43,11 +47,14 @@ struct sync_file {struct dma_fence *fence;struct dma_fence_cb cb; +uint32_t type; + uint32_t flags; };#define POLL_ENABLED DMA_FENCE_FLAG_USER_BITS -struct sync_file *sync_file_create (struct dma_fence *fence); +int sync_file_validate_type_flags (uint32_t type,uint32_t flags); +struct sync_file *sync_file_create (struct dma_fence *fence,uint32_t type,uint32_t flags);struct dma_fence *sync_file_get_fence (int fd);#endif /* _LINUX_SYNC_H */
include/uapi/linux/sync_file.h +27 -0
@@ -69,6 +69,26 @@ struct sync_file_info {#define SYNC_IOC_MAGIC '>'/** +* DOC: SYNC_FILE_TYPE_FENCE - fence sync file object +* +* This sync file is a wrapper around a dma fence or a dma fence array. +* It can be merged with another fence sync file object to create a new +* merged object. +* The fence backing this object cannot be replaced. +* This is useful for shared fences. +*/ +#define SYNC_FILE_TYPE_FENCE 0 + +/** +* struct sync_file_type - data returned from sync file type ioctl +* @type: sync_file type +* @flags: sync_file creation flags +*/ +struct sync_file_type { +__u32 type; +__u32 flags; +}; +/** * Opcodes 0, 1 and 2 were burned during a API change to avoid users of the * old API to get weird errors when trying to handling sync_files. The API * change happened during the de-stage of the Sync Framework when there was
@@ -94,4 +114,11 @@ struct sync_file_info {*/ #define SYNC_IOC_FILE_INFO _IOWR(SYNC_IOC_MAGIC, 4, struct sync_file_info) +/** +* DOC: SYNC_IOC_TYPE - get creation type and flags of sync_file. +* +* Takes a struct sync_file_type. Returns the created values of type and flags. +*/ +#define SYNC_IOC_TYPE _IOWR(SYNC_IOC_MAGIC, 5, struct sync_file_type) +#endif /* _UAPI_LINUX_SYNC_H */
Signature · 6 lines
2.9.3 _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
A message that is not in the archive (sent off-list or not yet received): 20170411032220.21101-1-airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
PATCH 2/8 sync_file: export some interfaces needed by drm sync objects.
From: Dave Airlie <[email protected]>
These are just alloc and fdget interfaces needed by the drm sync objects code.
--- drivers/dma-buf/sync_file.c | 21 +++++++++++++++++++-- include/linux/sync_file.h | 3 ++- 2 files changed, 21 insertions(+), 3 deletions(-)
drivers/dma-buf/sync_file.c +19 -2
@@ -46,7 +46,16 @@ int sync_file_validate_type_flags(uint32_t type, uint32_t flags) }EXPORT_SYMBOL (sync_file_validate_type_flags); -static struct sync_file *sync_file_alloc (uint32_t type,uint32_t flags) +/** +* sync_file_alloc() - allocate an unfenced sync file +* @type: type of sync file object +* @flags: creation flags for sync file object +* +* Creates a sync_file. +* The sync_file can be released with fput(sync_file->file). +* Returns the sync_file or NULL in case of error. +*/ +struct sync_file *sync_file_alloc (uint32_t type,uint32_t flags) {struct sync_file *sync_file;int ret;
@@ -78,6 +87,7 @@ static struct sync_file *sync_file_alloc(uint32_t type, uint32_t flags)kfree (sync_file);return NULL ; } +EXPORT_SYMBOL (sync_file_alloc);static void fence_check_cb_func (struct dma_fence *f,struct dma_fence_cb *cb) {
@@ -120,7 +130,13 @@ struct sync_file *sync_file_create(struct dma_fence *fence, }EXPORT_SYMBOL (sync_file_create); -static struct sync_file *sync_file_fdget (int fd) +/** +* sync_file_fdget - get a reference to the file and return sync_file. +* @fd: file descriptor pointing at a sync_file. +* +* Returns the corresponding sync_file object. +*/ +struct sync_file *sync_file_fdget (int fd) {struct file *file =fget (fd);
@@ -136,6 +152,7 @@ static struct sync_file *sync_file_fdget(int fd)fput (file);return NULL ; } +EXPORT_SYMBOL (sync_file_fdget);/** * sync_file_get_fence - get the fence related to the sync_file fd
include/linux/sync_file.h +2 -1
@@ -54,7 +54,8 @@ struct sync_file {#define POLL_ENABLED DMA_FENCE_FLAG_USER_BITSint sync_file_validate_type_flags (uint32_t type,uint32_t flags); +struct sync_file *sync_file_alloc (uint32_t type,uint32_t flags);struct sync_file *sync_file_create (struct dma_fence *fence,uint32_t type,uint32_t flags);struct dma_fence *sync_file_get_fence (int fd); - +struct sync_file *sync_file_fdget (int fd);#endif /* _LINUX_SYNC_H */
Signature · 6 lines
2.9.3 _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
PATCH 4/8 sync_file: add a mutex to protect fence and callback members. (v4)
In reply to a message not in the archiveFrom: Dave Airlie <[email protected]>
This patch allows the underlying fence in a sync_file to be changed or set to NULL. This isn't currently required but for Vulkan semaphores we need to be able to swap and reset the fence.
In order to faciliate this, it uses rcu to protect the fence, along with a new mutex. The mutex also protects the callback. It also checks for NULL when retrieving the rcu protected fence in case it has been reset.
v1.1: fix the locking (Julia Lawall).
v2: use rcu try one
v3: fix poll to use proper rcu, fixup merge/fill ioctls to not crash on NULL fence cases.
v4: use rcu in even more places, add missing fput
--- drivers/dma-buf/sync_file.c | 135 +++++++++++++++++++++++++++++++++++--------- include/linux/sync_file.h | 6 +- 2 files changed, 112 insertions(+), 29 deletions(-)
drivers/dma-buf/sync_file.c +107 -28
@@ -28,6 +28,10 @@static const struct file_operations sync_file_fops; +#define sync_file_held (obj) lockdep_is_held(&(obj)->lock) +#define sync_file_assert_held (obj) \ + lockdep_assert_held(&(obj)->lock) +/** * sync_file_validate_type_flags - validate type/flags for support * @type: type of sync file object
@@ -81,6 +85,10 @@ struct sync_file *sync_file_alloc(uint32_t type, uint32_t flags) sync_file->type = type; sync_file->flags = flags; + +RCU_INIT_POINTER (sync_file->fence,NULL ); + +mutex_init (&sync_file->lock);return sync_file; err:
@@ -119,7 +127,9 @@ struct sync_file *sync_file_create(struct dma_fence *fence,if (!sync_file)return NULL ; - sync_file->fence =dma_fence_get (fence); +dma_fence_get (fence); + +RCU_INIT_POINTER (sync_file->fence, fence); snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d", fence->ops->get_driver_name(fence),
@@ -170,13 +180,28 @@ struct dma_fence *sync_file_get_fence(int fd)if (!sync_file)return NULL ; - fence =dma_fence_get (sync_file->fence); +if (!rcu_access_pointer (sync_file->fence)) { +fput (sync_file->file); +return NULL ; + } + +rcu_read_lock (); + fence =dma_fence_get_rcu_safe (&sync_file->fence); +rcu_read_unlock (); +fput (sync_file->file);return fence; }EXPORT_SYMBOL (sync_file_get_fence); +static inline struct dma_fence * +sync_file_get_fence_locked (struct sync_file *sync_file) +{ +return rcu_dereference_protected (sync_file->fence, +sync_file_held (sync_file)); +} +static int sync_file_set_fence (struct sync_file *sync_file,struct dma_fence **fences,int num_fences) {
@@ -189,7 +214,7 @@ static int sync_file_set_fence(struct sync_file *sync_file,* we own the reference of the dma_fence_array creation. */ if (num_fences ==1 ) { - sync_file->fence = fences[0 ]; +RCU_INIT_POINTER (sync_file->fence, fences[0 ]);kfree (fences); }else { array = dma_fence_array_create(num_fences, fences,
@@ -198,24 +223,30 @@ static int sync_file_set_fence(struct sync_file *sync_file,if (!array)return -ENOMEM ; - sync_file->fence = &array->base; +RCU_INIT_POINTER (sync_file->fence, &array->base); }return 0 ; } -static struct dma_fence **get_fences (struct sync_file *sync_file, +/* must be called with rcu read lock taken */ +static struct dma_fence **get_fences (struct dma_fence **fence,int *num_fences) { -if (dma_fence_is_array (sync_file->fence)) { -struct dma_fence_array *array =to_dma_fence_array (sync_file->fence); +if (!*fence) { + *num_fences =0 ; +return NULL ; + } + +if (dma_fence_is_array (*fence)) { +struct dma_fence_array *array =to_dma_fence_array (*fence); *num_fences = array->num_fences;return array->fences; } *num_fences =1 ; -return &sync_file->fence; +return fence; } static void add_fence(struct dma_fence **fences,
@@ -245,18 +276,31 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a,struct sync_file *sync_file;struct dma_fence **fences, **nfences, **a_fences, **b_fences;int i, i_a, i_b, num_fences, a_num_fences, b_num_fences; +struct dma_fence *a_fence, *b_fence;if (a->type != b->type)return NULL ; - sync_file =sync_file_alloc (a->type, a->flags); -if (!sync_file) +if (!rcu_access_pointer (a->fence) || + !rcu_access_pointer (b->fence))return NULL ; - a_fences =get_fences (a, &a_num_fences); - b_fences =get_fences (b, &b_num_fences); +rcu_read_lock (); + a_fence =dma_fence_get_rcu_safe (&a->fence); + b_fence =dma_fence_get_rcu_safe (&b->fence); +rcu_read_unlock (); + + a_fences =get_fences (&a_fence, &a_num_fences); + b_fences =get_fences (&b_fence, &b_num_fences); +if (!a_num_fences || !b_num_fences) + goto put_src_fences; +if (a_num_fences >INT_MAX - b_num_fences) -return NULL ; + goto put_src_fences; + + sync_file =sync_file_alloc (a->type, a->flags); +if (!sync_file) + goto put_src_fences; num_fences = a_num_fences + b_num_fences;
@@ -317,11 +361,16 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a, goto err; } +dma_fence_put (a_fence); +dma_fence_put (b_fence);strlcpy (sync_file->name, name,sizeof (sync_file->name));return sync_file; err:fput (sync_file->file); +put_src_fences: +dma_fence_put (a_fence); +dma_fence_put (b_fence);return NULL ; }
@@ -330,10 +379,15 @@ static void sync_file_free(struct kref *kref) { struct sync_file *sync_file = container_of(kref, struct sync_file, kref); +struct dma_fence *fence; + + fence =rcu_dereference_protected (sync_file->fence,1 ); +if (fence) { +if (test_bit (POLL_ENABLED , &fence->flags)) +dma_fence_remove_callback (fence, &sync_file->cb); +dma_fence_put (fence); + } -if (test_bit (POLL_ENABLED , &sync_file->fence->flags)) -dma_fence_remove_callback (sync_file->fence, &sync_file->cb); -dma_fence_put (sync_file->fence);kfree (sync_file); }
@@ -348,16 +402,25 @@ static int sync_file_release(struct inode *inode, struct file *file)static unsigned int sync_file_poll (struct file *file,poll_table *wait) {struct sync_file *sync_file = file->private_data; +unsigned int ret_val =0 ; +struct dma_fence *fence;poll_wait (file, &sync_file->wq, wait); -if (!test_and_set_bit (POLL_ENABLED , &sync_file->fence->flags)) { -if (dma_fence_add_callback (sync_file->fence, &sync_file->cb, - fence_check_cb_func) <0 ) -wake_up_all (&sync_file->wq); +mutex_lock (&sync_file->lock); + + fence =sync_file_get_fence_locked (sync_file); +if (fence) { +if (!test_and_set_bit (POLL_ENABLED , &fence->flags)) { +if (dma_fence_add_callback (fence, &sync_file->cb, + fence_check_cb_func) <0 ) +wake_up_all (&sync_file->wq); + } + ret_val =dma_fence_is_signaled (fence) ?POLLIN :0 ; } +mutex_unlock (&sync_file->lock); -return dma_fence_is_signaled (sync_file->fence) ?POLLIN :0 ; +return ret_val; } static long sync_file_ioctl_merge(struct sync_file *sync_file,
@@ -433,6 +496,7 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,struct sync_file_info info;struct sync_fence_info *fence_info =NULL ;struct dma_fence **fences; +struct dma_fence *fence;__u32 size;int num_fences, ret, i;
@@ -442,7 +506,15 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,if (info.flags || info.pad)return -EINVAL ; - fences =get_fences (sync_file, &num_fences); +rcu_read_lock (); + fence =dma_fence_get_rcu_safe (&sync_file->fence); +rcu_read_unlock (); + + fences =get_fences (&fence, &num_fences); + +/* if there are no fences in the sync_file just return */ +if (!num_fences) + goto no_fences;/* * Passing num_fences = 0 means that userspace doesn't want to
@@ -453,13 +525,17 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file,if (!info.num_fences) goto no_fences; -if (info.num_fences < num_fences) -return -EINVAL ; +if (info.num_fences < num_fences) { + ret = -EINVAL ; + goto out; + } size = num_fences *sizeof (*fence_info); fence_info =kzalloc (size,GFP_KERNEL ); -if (!fence_info) -return -ENOMEM ; +if (!fence_info) { + ret = -ENOMEM ; + goto out; + }for (i =0 ; i < num_fences; i++)sync_fill_fence_info (fences[i], &fence_info[i]);
@@ -472,7 +548,10 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, no_fences:strlcpy (info.name, sync_file->name,sizeof (info.name)); - info.status =dma_fence_is_signaled (sync_file->fence); +if (num_fences) + info.status =dma_fence_is_signaled (sync_file->fence); +else + info.status = -ENOENT ; info.num_fences = num_fences;if (copy_to_user ((void __user *)arg, &info,sizeof (info)))
@@ -482,7 +561,7 @@ static long sync_file_ioctl_fence_info(struct sync_file *sync_file, out:kfree (fence_info); - +dma_fence_put (fence);return ret; }
include/linux/sync_file.h +5 -1
@@ -34,6 +34,7 @@* @cb: fence callback information * @type: sync file type * @flags: flags used to create sync file +* @lock: mutex to protect fence/cb - used for semaphores */ struct sync_file {struct file *file;
@@ -45,10 +46,13 @@ struct sync_file {wait_queue_head_t wq; -struct dma_fence *fence; +struct dma_fence __rcu *fence;struct dma_fence_cb cb;uint32_t type;uint32_t flags; + +/* protects the fence pointer and cb */ +struct mutex lock; };#define POLL_ENABLED DMA_FENCE_FLAG_USER_BITS
Signature · 6 lines
2.9.3 _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
PATCH 6/8 drm/syncobj: add semaphore support helpers.
In reply to a message not in the archiveFrom: Dave Airlie <[email protected]>
This just adds two helper interfaces to bridge the gap from drivers to sync_file for the semaphore objects.
These will be used by the amdgpu driver.
--- drivers/gpu/drm/drm_syncobj.c | 77 +++++++++++++++++++++++++++++++++++++++++++ include/drm/drm_syncobj.h | 37 +++++++++++++++++++++ 2 files changed, 114 insertions(+) create mode 100644 include/drm/drm_syncobj.h
drivers/gpu/drm/drm_syncobj.c +77 -0
@@ -39,6 +39,7 @@#include <drm/drmP.h> #include <linux/sync_file.h> #include "drm_internal.h" +#include <drm/drm_syncobj.h> static struct sync_file *drm_syncobj_get (struct drm_file *file_private,u32 handle)
@@ -57,6 +58,82 @@ static struct sync_file *drm_syncobj_get(struct drm_file *file_private,return sync_file; } +static int drm_syncobj_swap_fences_nocheck (struct drm_file *file_private, +uint32_t handle, +struct dma_fence *fence, +struct dma_fence **old_fence) +{ +struct sync_file *sync_file =drm_syncobj_get (file_private, handle); + +if (!sync_file) +return -EINVAL ; + + *old_fence =sync_file_replace_fence (sync_file, fence); +fput (sync_file->file); +return 0 ; +} + +/** +* drm_syncobj_swap_fences - lookup and replace fence in a sync object. +* @file_private - drm file private pointer. +* @handle - sync object handle +* @fence - new fence (or NULL) to back sync object. +* @old_fence - old fence backing sync object. +* Returns: +* 0 on success, or -EINVAL when the handle doesn't point at a valid +* sync_file with %SYNC_FILE_TYPE_SEMAPHORE. +* +* This function is used to swap the fence backing the sync object +* with a new one, it returns the old fence in old_fence; +*/ +int drm_syncobj_swap_fences (struct drm_file *file_private, +uint32_t handle, +struct dma_fence *fence, +struct dma_fence **old_fence) +{ +int r; + + r =drm_syncobj_swap_fences_nocheck (file_private, + handle, + fence, + old_fence); +if (r) +return r; + + +if (!*old_fence) +return -EINVAL ; +return 0 ; +} +EXPORT_SYMBOL (drm_syncobj_swap_fences); + +/** +* drm_syncobj_replace_fence - lookup and replace fence in a sync object. +* @file_private - drm file private pointer. +* @handle - syncobj handle to lookup +* @fence - fence to install in sync file. +* Returns: +* 0 on success, or -EINVAL when the handle doesn't point at a valid +* sync_file with %SYNC_FILE_TYPE_SEMAPHORE. +* +* This looks up a sync object and replaces the fence on it, freeing +* the old one. +*/ +int drm_syncobj_replace_fence (struct drm_file *file_private, +u32 handle, +struct dma_fence *fence) +{ +struct dma_fence *old_fence; +int r; + + r =drm_syncobj_swap_fences_nocheck (file_private, handle, fence, &old_fence); +if (r) +return r; +dma_fence_put (old_fence); +return 0 ; +} +EXPORT_SYMBOL (drm_syncobj_replace_fence); +static int drm_syncobj_create (struct drm_file *file_private,unsigned type,unsigned flags,u32 *handle)
include/drm/drm_syncobj.h new file +37 -0
@@ -0,0 +1,37 @@ +/* +* Copyright © 2017 Red Hat +* +* Permission is hereby granted, free of charge, to any person obtaining a +* copy of this software and associated documentation files (the "Software"), +* to deal in the Software without restriction, including without limitation +* the rights to use, copy, modify, merge, publish, distribute, sublicense, +* and/or sell copies of the Software, and to permit persons to whom the +* Software is furnished to do so, subject to the following conditions: +* +* The above copyright notice and this permission notice (including the next +* paragraph) shall be included in all copies or substantial portions of the +* Software. +* +* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS +* IN THE SOFTWARE. +* +* Authors: +* +*/ +#ifndef __DRM_SYNCOBJ_H__ +#define __DRM_SYNCOBJ_H__ + +int drm_syncobj_swap_fences (struct drm_file *file_private, +uint32_t handle, +struct dma_fence *fence, +struct dma_fence **old_fence); +int drm_syncobj_replace_fence (struct drm_file *file_private, +u32 handle, +struct dma_fence *fence); + +#endif
Signature · 6 lines
2.9.3 _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
PATCH 7/8 amdgpu/cs: split out fence dependency checking
In reply to a message not in the archiveFrom: Dave Airlie <[email protected]>
This just splits out the fence depenency checking into it's own function to make it easier to add semaphore dependencies.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 85 +++++++++++++++++++--------------- 1 file changed, 47 insertions(+), 38 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +47 -38
@@ -963,56 +963,65 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device *adev,return 0 ; } -static int amdgpu_cs_dependencies (struct amdgpu_device *adev, -struct amdgpu_cs_parser *p) +static int amdgpu_process_fence_dep (struct amdgpu_cs_parser *p, +struct amdgpu_cs_chunk *chunk) {struct amdgpu_fpriv *fpriv = p->filp->driver_priv; -int i, j, r; - -for (i =0 ; i < p->nchunks; ++i) { -struct drm_amdgpu_cs_chunk_dep *deps; -struct amdgpu_cs_chunk *chunk; -unsigned num_deps; +unsigned num_deps; +int i, r; +struct drm_amdgpu_cs_chunk_dep *deps; - chunk = &p->chunks[i]; + deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata; + num_deps = chunk->length_dw *4 / +sizeof (struct drm_amdgpu_cs_chunk_dep ); -if (chunk->chunk_id !=AMDGPU_CHUNK_ID_DEPENDENCIES ) -continue ; +for (i =0 ; i < num_deps; ++i) { +struct amdgpu_ring *ring; +struct amdgpu_ctx *ctx; +struct dma_fence *fence; - deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata; - num_deps = chunk->length_dw *4 / -sizeof (struct drm_amdgpu_cs_chunk_dep ); + r =amdgpu_cs_get_ring (p->adev, deps[i].ip_type, + deps[i].ip_instance, + deps[i].ring, &ring); +if (r) +return r; -for (j =0 ; j < num_deps; ++j) { -struct amdgpu_ring *ring; -struct amdgpu_ctx *ctx; -struct dma_fence *fence; + ctx =amdgpu_ctx_get (fpriv, deps[i].ctx_id); +if (ctx ==NULL ) +return -EINVAL ; - r =amdgpu_cs_get_ring (adev, deps[j].ip_type, - deps[j].ip_instance, - deps[j].ring, &ring); + fence =amdgpu_ctx_get_fence (ctx, ring, + deps[i].handle); +if (IS_ERR (fence)) { + r =PTR_ERR (fence); +amdgpu_ctx_put (ctx); +return r; + }else if (fence) { + r =amdgpu_sync_fence (p->adev, &p->job->sync, + fence); +dma_fence_put (fence); +amdgpu_ctx_put (ctx);if (r)return r; + } + } +return 0 ; +} - ctx =amdgpu_ctx_get (fpriv, deps[j].ctx_id); -if (ctx ==NULL ) -return -EINVAL ; +static int amdgpu_cs_dependencies (struct amdgpu_device *adev, +struct amdgpu_cs_parser *p) +{ +int i, r; - fence =amdgpu_ctx_get_fence (ctx, ring, - deps[j].handle); -if (IS_ERR (fence)) { - r =PTR_ERR (fence); -amdgpu_ctx_put (ctx); -return r; +for (i =0 ; i < p->nchunks; ++i) { +struct amdgpu_cs_chunk *chunk; - }else if (fence) { - r =amdgpu_sync_fence (adev, &p->job->sync, - fence); -dma_fence_put (fence); -amdgpu_ctx_put (ctx); -if (r) -return r; - } + chunk = &p->chunks[i]; + +if (chunk->chunk_id ==AMDGPU_CHUNK_ID_DEPENDENCIES ) { + r =amdgpu_process_fence_dep (p, chunk); +if (r) +return r; } }
Signature · 6 lines
2.9.3 _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
PATCH 8/8 amdgpu: use sync file for shared semaphores (v2.1)
In reply to a message not in the archiveFrom: Dave Airlie <[email protected]>
This creates a new command submission chunk for amdgpu to add wait and signal sync objects around the submission.
Sync objects are managed via the drm syncobj ioctls.
The command submission interface is enhanced with two new chunks, one for semaphore waiting, one for semaphore signalling and just takes a list of handles for each.
This is based on work originally done by David Zhou at AMD, with input from Christian Konig on what things should look like.
NOTE: this interface addition needs a version bump to expose it to userspace.
v1.1: keep file reference on import.
v2: move to using syncobjs
v2.1: change some APIs to just use p pointer.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 82 ++++++++++++++++++++++++++++++++- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- include/uapi/drm/amdgpu_drm.h | 6 +++ 3 files changed, 88 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +81 -1
@@ -27,6 +27,7 @@#include <linux/pagemap.h> #include <drm/drmP.h> #include <drm/amdgpu_drm.h> +#include <drm/drm_syncobj.h> #include "amdgpu.h" #include "amdgpu_trace.h"
@@ -217,6 +218,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void *data)break ;case AMDGPU_CHUNK_ID_DEPENDENCIES : +case AMDGPU_CHUNK_ID_SEM_WAIT : +case AMDGPU_CHUNK_ID_SEM_SIGNAL :break ;default :
@@ -1008,6 +1011,41 @@ static int amdgpu_process_fence_dep(struct amdgpu_cs_parser *p,return 0 ; } +static int amdgpu_sem_lookup_and_sync (struct amdgpu_cs_parser *p, +uint32_t handle) +{ +int r; +struct dma_fence *old_fence; + + r =drm_syncobj_swap_fences (p->filp, handle,NULL , &old_fence); +if (r) +return r; + + r =amdgpu_sync_fence (p->adev, &p->job->sync, old_fence); +dma_fence_put (old_fence); + +return r; +} + +static int amdgpu_process_sem_wait_dep (struct amdgpu_cs_parser *p, +struct amdgpu_cs_chunk *chunk) +{ +unsigned num_deps; +int i, r; +struct drm_amdgpu_cs_chunk_sem *deps; + + deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata; + num_deps = chunk->length_dw *4 / +sizeof (struct drm_amdgpu_cs_chunk_sem ); + +for (i =0 ; i < num_deps; ++i) { + r =amdgpu_sem_lookup_and_sync (p, deps[i].handle); +if (r) +return r; + } +return 0 ; +} +static int amdgpu_cs_dependencies (struct amdgpu_device *adev,struct amdgpu_cs_parser *p) {
@@ -1022,12 +1060,54 @@ static int amdgpu_cs_dependencies(struct amdgpu_device *adev, r =amdgpu_process_fence_dep (p, chunk);if (r)return r; + }else if (chunk->chunk_id ==AMDGPU_CHUNK_ID_SEM_WAIT ) { + r =amdgpu_process_sem_wait_dep (p, chunk); +if (r) +return r; } }return 0 ; } +static int amdgpu_process_sem_signal_dep (struct amdgpu_cs_parser *p, +struct amdgpu_cs_chunk *chunk) +{ +unsigned num_deps; +int i, r; +struct drm_amdgpu_cs_chunk_sem *deps; + + deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata; + num_deps = chunk->length_dw *4 / +sizeof (struct drm_amdgpu_cs_chunk_sem ); + +for (i =0 ; i < num_deps; ++i) { + r =drm_syncobj_replace_fence (p->filp, deps[i].handle, + p->fence); +if (r) +return r; + } +return 0 ; +} + +static int amdgpu_cs_post_dependencies (struct amdgpu_cs_parser *p) +{ +int i, r; + +for (i =0 ; i < p->nchunks; ++i) { +struct amdgpu_cs_chunk *chunk; + + chunk = &p->chunks[i]; + +if (chunk->chunk_id ==AMDGPU_CHUNK_ID_SEM_SIGNAL ) { + r =amdgpu_process_sem_signal_dep (p, chunk); +if (r) +return r; + } + } +return 0 ; +} +static int amdgpu_cs_submit (struct amdgpu_cs_parser *p,union drm_amdgpu_cs *cs) {
@@ -1055,7 +1135,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,trace_amdgpu_cs_ioctl (job);amd_sched_entity_push_job (&job->base); -return 0 ; +return amdgpu_cs_post_dependencies (p); }int amdgpu_cs_ioctl (struct drm_device *dev,void *data,struct drm_file *filp)
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +1 -1
@@ -683,7 +683,7 @@ static struct drm_driver kms_driver = { .driver_features =DRIVER_USE_AGP |DRIVER_HAVE_IRQ |DRIVER_IRQ_SHARED |DRIVER_GEM | - DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET, + DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ, .load = amdgpu_driver_load_kms, .open = amdgpu_driver_open_kms, .preclose = amdgpu_driver_preclose_kms,
include/uapi/drm/amdgpu_drm.h +6 -0
@@ -390,6 +390,8 @@ struct drm_amdgpu_gem_va {#define AMDGPU_CHUNK_ID_IB 0x01#define AMDGPU_CHUNK_ID_FENCE 0x02#define AMDGPU_CHUNK_ID_DEPENDENCIES 0x03 +#define AMDGPU_CHUNK_ID_SEM_WAIT 0x04 +#define AMDGPU_CHUNK_ID_SEM_SIGNAL 0x05struct drm_amdgpu_cs_chunk {__u32 chunk_id;
@@ -454,6 +456,10 @@ struct drm_amdgpu_cs_chunk_fence {__u32 offset; }; +struct drm_amdgpu_cs_chunk_sem { +__u32 handle; +}; +struct drm_amdgpu_cs_chunk_data {union {struct drm_amdgpu_cs_chunk_ib ib_data;
Signature · 6 lines
2.9.3 _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): 20170411032220.21101-9-airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c static int amdgpu_process_fence_dep(struct amdgpu_cs_parser *p, · line 1022
Quoted 9 lines · Dave Airlie
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +9
-0+static int amdgpu_sem_lookup_and_sync (struct amdgpu_cs_parser *p, +uint32_t handle) +{ +int r; +struct dma_fence *old_fence; + + r =drm_syncobj_swap_fences (p->filp, handle,NULL , &old_fence); +if (r) +return r;
I'm a bit puzzled over this interface as this means that all in-semaphores are not reusable. That seems a bit odd as it means userspace can't use the results from one engine on two+ parallel engines. Searching kronos for VkSemaphore
https://www.khronos.org/registry/vulkan/specs/1.0/man/html/VkSemaphore.html
isn't enlightening...
-Chris
Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): 20170411124217.GC7895-aII6DKEyn0pWYbfKqPwjAkR8Iwp7RQ6xAL8bYrjMMd8@public.gmane.org
Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)
Quoted 17 lines · Chris Wilson
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c static int amdgpu_process_fence_dep(struct amdgpu_cs_parser *p, · line 1022
Quoted 9 lines · Dave Airlie
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +9
-0+static int amdgpu_sem_lookup_and_sync (struct amdgpu_cs_parser *p, +uint32_t handle) +{ +int r; +struct dma_fence *old_fence; + + r =drm_syncobj_swap_fences (p->filp, handle,NULL , &old_fence); +if (r) +return r;I'm a bit puzzled over this interface as this means that all in-semaphores are not reusable. That seems a bit odd as it means userspace can't use the results from one engine on two+ parallel engines. Searching kronos for VkSemaphore
https://www.khronos.org/registry/vulkan/specs/1.0/man/html/VkSemaphore.html
isn't enlightening...
You need to look in the vulkan spec itself.
But yes this is the semantics, vulkan semaphores are explicitly 1:1 objects.
One wait must have one signal. It's a semaphore not a fence, so you can't have multiple engines getting the results from one semaphore.
Dave.
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)
In reply to a message not in the archiveDoes it means we have to submit command to trigger the semaphore wait/signal?
Best Regards,
David
-----Original Message-----
From: amd-gfx [mailto:[email protected]] On Behalf Of Dave Airlie
Sent: Tuesday, April 11, 2017 11:22 AM
To: [email protected]; [email protected]
Subject: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)
From: Dave Airlie <[email protected]>
This creates a new command submission chunk for amdgpu to add wait and signal sync objects around the submission.
Sync objects are managed via the drm syncobj ioctls.
The command submission interface is enhanced with two new chunks, one for semaphore waiting, one for semaphore signalling and just takes a list of handles for each.
This is based on work originally done by David Zhou at AMD, with input from Christian Konig on what things should look like.
NOTE: this interface addition needs a version bump to expose it to userspace.
v1.1: keep file reference on import.
v2: move to using syncobjs
v2.1: change some APIs to just use p pointer.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 82 ++++++++++++++++++++++++++++++++- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- include/uapi/drm/amdgpu_drm.h | 6 +++ 3 files changed, 88 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +79 -1
@@ -27,6 +27,7 @@#include <linux/pagemap.h> #include <drm/drmP.h> #include <drm/amdgpu_drm.h> +#include <drm/drm_syncobj.h> #include "amdgpu.h" #include "amdgpu_trace.h"
@@ -217,6 +218,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void *data)break ;case AMDGPU_CHUNK_ID_DEPENDENCIES : +case AMDGPU_CHUNK_ID_SEM_WAIT : +case AMDGPU_CHUNK_ID_SEM_SIGNAL :break ;default :
@@ -1008,6 +1011,41 @@ static int amdgpu_process_fence_dep(struct amdgpu_cs_parser *p,return 0 ; } +static int amdgpu_sem_lookup_and_sync (struct amdgpu_cs_parser *p, +uint32_t handle) +{ +int r; +struct dma_fence *old_fence; + + r =drm_syncobj_swap_fences (p->filp, handle,NULL , &old_fence); +if (r) +return r; + + r =amdgpu_sync_fence (p->adev, &p->job->sync, old_fence); +dma_fence_put (old_fence); + +return r; +} + +static int amdgpu_process_sem_wait_dep (struct amdgpu_cs_parser *p, +struct amdgpu_cs_chunk *chunk) { +unsigned num_deps; +int i, r; +struct drm_amdgpu_cs_chunk_sem *deps; + + deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata; + num_deps = chunk->length_dw *4 / +sizeof (struct drm_amdgpu_cs_chunk_sem ); + +for (i =0 ; i < num_deps; ++i) { + r =amdgpu_sem_lookup_and_sync (p, deps[i].handle); +if (r) +return r; + } +return 0 ; +} +static int amdgpu_cs_dependencies (struct amdgpu_device *adev,struct amdgpu_cs_parser *p) {
@@ -1022,12 +1060,54 @@ static int amdgpu_cs_dependencies(struct amdgpu_device *adev, r =amdgpu_process_fence_dep (p, chunk);if (r)return r; + }else if (chunk->chunk_id ==AMDGPU_CHUNK_ID_SEM_WAIT ) { + r =amdgpu_process_sem_wait_dep (p, chunk); +if (r) +return r; } }return 0 ; } +static int amdgpu_process_sem_signal_dep (struct amdgpu_cs_parser *p, +struct amdgpu_cs_chunk *chunk) +{ +unsigned num_deps; +int i, r; +struct drm_amdgpu_cs_chunk_sem *deps; + + deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata; + num_deps = chunk->length_dw *4 / +sizeof (struct drm_amdgpu_cs_chunk_sem ); + +for (i =0 ; i < num_deps; ++i) { + r =drm_syncobj_replace_fence (p->filp, deps[i].handle, + p->fence); +if (r) +return r; + } +return 0 ; +} + +static int amdgpu_cs_post_dependencies (struct amdgpu_cs_parser *p) { +int i, r; + +for (i =0 ; i < p->nchunks; ++i) { +struct amdgpu_cs_chunk *chunk; + + chunk = &p->chunks[i]; + +if (chunk->chunk_id ==AMDGPU_CHUNK_ID_SEM_SIGNAL ) { + r =amdgpu_process_sem_signal_dep (p, chunk); +if (r) +return r; + } + } +return 0 ; +} +static int amdgpu_cs_submit (struct amdgpu_cs_parser *p,union drm_amdgpu_cs *cs) {
@@ -1055,7 +1135,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,trace_amdgpu_cs_ioctl (job);amd_sched_entity_push_job (&job->base); -return 0 ; +return amdgpu_cs_post_dependencies (p); } int amdgpu_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index b76cd69..e95951e 100644
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +1 -1
@@ -683,7 +683,7 @@ static struct drm_driver kms_driver = { .driver_features =DRIVER_USE_AGP |DRIVER_HAVE_IRQ |DRIVER_IRQ_SHARED |DRIVER_GEM | -DRIVER_PRIME |DRIVER_RENDER |DRIVER_MODESET , +DRIVER_PRIME |DRIVER_RENDER |DRIVER_MODESET |DRIVER_SYNCOBJ , .load = amdgpu_driver_load_kms, .open = amdgpu_driver_open_kms, .preclose = amdgpu_driver_preclose_kms, diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h index 5797283..647c520 100644
include/uapi/drm/amdgpu_drm.h +6 -0
@@ -390,6 +390,8 @@ struct drm_amdgpu_gem_va {#define AMDGPU_CHUNK_ID_IB 0x01#define AMDGPU_CHUNK_ID_FENCE 0x02#define AMDGPU_CHUNK_ID_DEPENDENCIES 0x03 +#define AMDGPU_CHUNK_ID_SEM_WAIT 0x04 +#define AMDGPU_CHUNK_ID_SEM_SIGNAL 0x05struct drm_amdgpu_cs_chunk {__u32 chunk_id;
@@ -454,6 +456,10 @@ struct drm_amdgpu_cs_chunk_fence {__u32 offset; }; +struct drm_amdgpu_cs_chunk_sem { +__u32 handle; +}; +struct drm_amdgpu_cs_chunk_data {union {struct drm_amdgpu_cs_chunk_ib ib_data;
--
2.9.3
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): BN4PR12MB0787C6D1CD93D0FCB6F2069DEE030-aH9FTdWx9BancvD3hK8fMAdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org
Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)
Quoted 1 line · David
Does it means we have to submit command to trigger the semaphore wait/signal?
Yes, but I think that should be fine, we need to submit a job to the scheduler to
get the waits to happen or to have a fence to fill into the signals.
Dave.
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): CAPM=9txg84JzHVOpA7mfp4774gT_TLcEiya5fXu9cMTSFdWYWg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
RE: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)
But how to handle the semaphore wait in the vkQueuePresentkHR?
Thanks.
Best Regards,
David
-----Original Message-----
From: Dave Airlie [mailto:[email protected]]
Sent: Wednesday, April 12, 2017 10:44 AM
To: Mao, David <[email protected]>
Cc: [email protected]; [email protected]
Subject: Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)
Quoted 1 line · David
Does it means we have to submit command to trigger the semaphore wait/signal?
Yes, but I think that should be fine, we need to submit a job to the scheduler to get the waits to happen or to have a fence to fill into the signals.
Dave.
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Dave Airlie
maintainerRe: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)
Quoted 1 line · David
But how to handle the semaphore wait in the vkQueuePresentkHR?
The problem here is that really we'd want the presenting process to do the signal once it submits the work for actual presentations (be that the X server DDX or whatever).
However that is going to be a bit tricky, for radv I've just been submitting an empty command stream submit, once the X server lets us know we've presented.
I looked how the codebase before I started working on it worked, and I can't see if it dealt with this properly either, the impression I get is that it might submit the wait sems via the sem ioctl onto a ctx, but the X server might be using a different ctx, so would never execute the wait, and we'd execute the wait the next time we did a command submission.
I suppose we could just queue up the vkQueuePresentKHR wait sems in userspace instead of a NULL cs if this solution was acceptable.
Dave.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)
My point is it is reasonable to split the semaphore signal/wait with the command submission.
For the signal ioctl, we could just pick the last fence in the same schedule context, and we don't need to ask for a explicit flush or a dummy submission trick. The spec guarantee the signal always comes before the wait, which means, we could always get the valid fence. For the kernel sem object.
Thanks.
Best Regards,
David
-----Original Message-----
From: Dave Airlie [mailto:[email protected]]
Sent: Wednesday, April 12, 2017 11:18 AM
To: Mao, David <[email protected]>
Cc: [email protected]; [email protected]
Subject: Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)
Quoted 1 line · David
But how to handle the semaphore wait in the vkQueuePresentkHR?
The problem here is that really we'd want the presenting process to do the signal once it submits the work for actual presentations (be that the X server DDX or whatever).
However that is going to be a bit tricky, for radv I've just been submitting an empty command stream submit, once the X server lets us know we've presented.
I looked how the codebase before I started working on it worked, and I can't see if it dealt with this properly either, the impression I get is that it might submit the wait sems via the sem ioctl onto a ctx, but the X server might be using a different ctx, so would never execute the wait, and we'd execute the wait the next time we did a command submission.
I suppose we could just queue up the vkQueuePresentKHR wait sems in userspace instead of a NULL cs if this solution was acceptable.
Dave.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
A message that is not in the archive (sent off-list or not yet received): BN4PR12MB07879A581F0E3C7AE9FDA20CEE030-aH9FTdWx9BancvD3hK8fMAdYzm3356FpvxpqHgZTriW3zl9H0oFU5g@public.gmane.org
Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)
Quoted 3 lines · David
My point is it is reasonable to split the semaphore signal/wait with the command submission.
For the signal ioctl, we could just pick the last fence in the same schedule context, and we don't need to ask for a explicit flush or a dummy submission trick. The spec guarantee the signal always comes before the wait, which means, we could always get the valid fence. For the kernel sem object.
I'm a bit vague on the schedule contexts stuff, but does anything guarantee the X server present operation be in the same schedule context?
This might be something for Christian to chime in on, we could I suppose add ioctls to avoid the dummy CS submission, we could also make dummy
CS submission simpler, if we submit no IBs then we could just have it deal with the semaphores for those cases and avoid any explicit flushes,
which saves reproducing the logic to wait and sync.
But at least for the wait case, we need to send something to the scheduler to wait on, and that looks like the CS ioctl we have now pretty much,
For the signal case there might be a better argument that an explicit signal with last fence on this ctx could be used, however at least with the way
radv works now, we definitely know the X server is finished with the present buffer as it tells us via its own sync logic, at that point radv submits
an empty CS with the signal semaphores, we'd really want to pass a semaphore between the X server and client to do this perfectly.
Dave.
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): CAPM=9twr+ZNJDe-uCQNUxTavr_W8+AEGygc1V8ei6Q0PaLRhtw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
RE: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)
=> we'd really want to pass a semaphore between the X server and client to do this perfectly.
Do you means that you want X to signal the semaphore that waited by client, through special version of xsync?
We use pretty complex tricks to build synchronization logic upon the event and shm fence.
But it would be better if we could use unified way to signal/wait the xsync fence and the semaphore object.
I can see the benefit for combining the semaphores' wait/signal into the submit routine, but how about extend the interface to allow null ib submission? In this case, it will always return the last seq_no for null ib list, and the semaphore in signal list will be associated with last fence as well. IIRC, the semaphore wait is applied to schedule entity as the dependency, which means it don't need to be associated with schedule job as well.
Thanks.
Best Regards,
David
-----Original Message-----
From: Dave Airlie [mailto:[email protected]]
Sent: Wednesday, April 12, 2017 11:58 AM
To: Mao, David <[email protected]>
Cc: [email protected]; [email protected]
Subject: Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)
Quoted 3 lines · David
My point is it is reasonable to split the semaphore signal/wait with the command submission.
For the signal ioctl, we could just pick the last fence in the same schedule context, and we don't need to ask for a explicit flush or a dummy submission trick. The spec guarantee the signal always comes before the wait, which means, we could always get the valid fence. For the kernel sem object.
I'm a bit vague on the schedule contexts stuff, but does anything guarantee the X server present operation be in the same schedule context?
This might be something for Christian to chime in on, we could I suppose add ioctls to avoid the dummy CS submission, we could also make dummy CS submission simpler, if we submit no IBs then we could just have it deal with the semaphores for those cases and avoid any explicit flushes, which saves reproducing the logic to wait and sync.
But at least for the wait case, we need to send something to the scheduler to wait on, and that looks like the CS ioctl we have now pretty much, For the signal case there might be a better argument that an explicit signal with last fence on this ctx could be used, however at least with the way radv works now, we definitely know the X server is finished with the present buffer as it tells us via its own sync logic, at that point radv submits an empty CS with the signal semaphores, we'd really want to pass a semaphore between the X server and client to do this perfectly.
Dave.
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)
In reply to a message not in the archiveAm 12.04.2017 um 05:58 schrieb Dave Airlie:
Quoted 7 lines · David
Quoted 3 lines
My point is it is reasonable to split the semaphore signal/wait with the command submission.
For the signal ioctl, we could just pick the last fence in the same schedule context, and we don't need to ask for a explicit flush or a dummy submission trick. The spec guarantee the signal always comes before the wait, which means, we could always get the valid fence. For the kernel sem object.I'm a bit vague on the schedule contexts stuff, but does anything guarantee the X server present operation be in the same schedule context?
Not even remotely. Since X and the application are separate processes they can't access each others schedule contexts.
Quoted 7 lines
This might be something for Christian to chime in on, we could I suppose add ioctls to avoid the dummy CS submission, we could also make dummy
CS submission simpler, if we submit no IBs then we could just have it deal with the semaphores for those cases and avoid any explicit flushes,
which saves reproducing the logic to wait and sync.
Sorry, I'm not following the whole discussion. Why do we want a dummy submission in the first place? Just to have the semaphore in the signaled state?
Quoted 11 lines
But at least for the wait case, we need to send something to the scheduler to wait on, and that looks like the CS ioctl we have now pretty much,
For the signal case there might be a better argument that an explicit signal with last fence on this ctx could be used, however at least with the way
radv works now, we definitely know the X server is finished with the present buffer as it tells us via its own sync logic, at that point radv submits
an empty CS with the signal semaphores, we'd really want to pass a semaphore between the X server and client to do this perfectly.
Yes, agree. We should fix this on the user space level, not add any kernel workarounds.
Regards,
Christian.
Quoted 6 lines
Dave.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Quoted 11 lines · Dave Airlie
This set of sync object patches should address most of the issues raised in review.
The major changes:
Race on destroy should be gone,
Documentation fixups
amdgpu internal use p instead of adev fixupsMy plans are to write some igt tests this week, and try to get some more review on what the API should allow (should I lock it down to drm syncobj is just semaphores for now).
Having an idr of handles is much, much nicer than fd and I want the same for fences :)
-Chris
Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): 20170414094520.GB12532-aII6DKEyn0pWYbfKqPwjAkR8Iwp7RQ6xAL8bYrjMMd8@public.gmane.org
Quoted 9 lines · Chris Wilson
Quoted 8 lines · Dave Airlie
This set of sync object patches should address most of the issues raised in review.
The major changes:
Race on destroy should be gone,
Documentation fixups
amdgpu internal use p instead of adev fixups
Quoted 6 lines
Quoted 3 lines
My plans are to write some igt tests this week, and try to get some more review on what the API should allow (should I lock it down to drm syncobj is just semaphores for now).
Having an idr of handles is much, much nicer than fd and I want the same for fences :)
Okay, but what form do you want the API to take for fences?
because I've just ported all this to using sem_file as the backend, instead of sync_file which seems to oppose the goal of using it for fences.
For fences do you want upfront creation, then passing created fences object into command submission that attach the internal fence?
Or do you want command submission to have out fence handles that it creates, so we don't have any explicit syncobj create for fences?
Do you want those fences to be shareable across processes using sync_file semantics?
I kinda feel like I'm going around in circles here and I'm going to just merge something instead.
Dave.
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): CAPM=9twmJPkzEL7sFOSAURAVKd7yhKn3dEk=C=vJMQT11sAQQA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 17 lines · Dave Airlie
Quoted 9 lines · Chris Wilson
Quoted 8 lines · Dave Airlie
This set of sync object patches should address most of the issues raised in review.
The major changes:
Race on destroy should be gone,
Documentation fixups
amdgpu internal use p instead of adev fixupsQuoted 6 lines
Quoted 3 lines
My plans are to write some igt tests this week, and try to get some more review on what the API should allow (should I lock it down to drm syncobj is just semaphores for now).
Having an idr of handles is much, much nicer than fd and I want the same for fences :)
Quoted 7 lines
Okay, but what form do you want the API to take for fences?
because I've just ported all this to using
sem_fileas the backend, instead ofsync_filewhich seems to oppose the goal of using it for fences.For fences do you want upfront creation, then passing created fences object into command submission that attach the internal fence?
Yes. My understanding is that fences differ from semaphores by allowing use prior to execution. And that userspace (Vk) wants to be able to create a fence, pass it to a listener (maybe different process) and then attach it to an out-fence from a CS.
I looked at using a shared idr for fences/semaphores and the issue I hit first was having to create a proxy dma-fence to initialise the syncobj with, so that I could attach listeners before I was able to hook the fence upto an execbuf.
Quoted 5 lines
Or do you want command submission to have out fence handles that it creates, so we don't have any explicit syncobj create for fences?
Do you want those fences to be shareable across processes using
sync_filesemantics?
Yes. In the same vein as the semaphore syncobjs, an idr for cheap creation/reuse within a process and export/import via sync_file fds. Where these fd differ from sema is that they do support host CPU access (these will work just like regular sync_files in that regard).
Quoted 2 lines
I kinda feel like I'm going around in circles here and I'm going to just merge something instead.
Sure. It was just from the perspective of extending the i915 execbuffer2 that adding an array for semaphore in/out could be neatly generalised to cover fences as well (and that the api for syncobj is a substantial improvement over sync_merge and passing one fence in/out). -Chris
Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): 20170418203037.GB9029-aII6DKEyn0pWYbfKqPwjAkR8Iwp7RQ6xAL8bYrjMMd8@public.gmane.org
A few thoughts (from the anv perspective) that I put on IRC but may be better in a mail. In no particular order:
1. Having the fd exported from a syncobj be a valid sync_file seems like a
fairly pointless feature to me. If we can make things more sane by throwing that out, I'm all for it.
2. As far as sync_file interactions go, I think the far more useful thing
would be for you to be able to export a sync_file from a syncobj which would create a sync_file that waits on the last submitted signal operation on the syncobj and then have a way of creating a temporary syncobj that has the fence from a sync_file. Not sure how this would interact with future fences. If we can't figure it out, let's just forget it and not have any defined interaction.
3. I'd like to also be able to use syncobj for implementing VkFence
sharing. Really, all this means is a drm_syncobj_wait ioctl. Yes, with the current sync_file stuff, you could turn it into a sync_file and poll but I'd rather not burn the file descriptors.
4. It would be a neat trick if drm_syncobj_wait could take a list of
syncobjs and wait on one or all of them as requested by the user. That said, this would be an optimization at best and I'm fine with waiting on them one at a time.
5. I'd like to better define what happens when someone tries to wait
twice. I'm a big fan of the semantics of dma-buf dependencies: Each wait operation waits on the most recently queued signal operation. That seems better to me than waiting causing an implicit reset and waiting twice being invalid. Among other things, it means that we don't have to worry bout the semantics of exactly how execbuf fails if you ask it to wait on the same sync file twice. That said, it can be anything we want, I just want it to be well-defined.
--Jason
Quoted 62 lines · Chris Wilson
Quoted 1 line · Dave Airlie
On 14 April 2017 at 19:45, Chris Wilson <[email protected]>
Quoted 9 lines · wrote:
Quoted 9 lines · Dave Airlie
Quoted 8 lines
This set of sync object patches should address most of the issues raised in review.
The major changes:
Race on destroy should be gone,
Documentation fixups
amdgpu internal use p instead of adev fixupsQuoted 5 lines
Quoted 5 lines
Quoted 3 lines
My plans are to write some igt tests this week, and try to get some more review on what the API should allow (should I lock it down to drm syncobj is just semaphores for now).
Having an idr of handles is much, much nicer than fd and I want the
same
Quoted 5 lines
Quoted 1 line
for fences :)
Okay, but what form do you want the API to take for fences?
because I've just ported all this to using
sem_fileas the backend,instead
Quoted 3 lines
of
sync_filewhich seems to oppose the goal of using it for fences.For fences do you want upfront creation, then passing created fences
object
Quoted 1 line
into command submission that attach the internal fence?
Yes. My understanding is that fences differ from semaphores by allowing use prior to execution. And that userspace (Vk) wants to be able to create a fence, pass it to a listener (maybe different process) and then attach it to an out-fence from a CS.
I looked at using a shared idr for fences/semaphores and the issue I hit first was having to create a proxy dma-fence to initialise the syncobj with, so that I could attach listeners before I was able to hook the fence upto an execbuf.
Quoted 1 line
Or do you want command submission to have out fence handles that it
creates,
Quoted 4 lines
so we don't have any explicit syncobj create for fences?
Do you want those fences to be shareable across processes using
sync_filesemantics?Yes. In the same vein as the semaphore syncobjs, an idr for cheap creation/reuse within a process and export/import via
sync_filefds. Where these fd differ from sema is that they do support host CPU access (these will work just like regularsync_filesin that regard).Quoted 1 line
I kinda feel like I'm going around in circles here and I'm going to just
merge
Quoted 1 line
something instead.
Sure. It was just from the perspective of extending the i915 execbuffer2 that adding an array for semaphore in/out could be neatly generalised to cover fences as well (and that the api for syncobj is a substantial improvement over
sync_mergeand passing one fence in/out). -Chris
Quoted 7 lines
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
dri-devel mailing list [email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Dave Airlie
maintainerQuoted 15 lines · Jason Ekstrand
A few thoughts (from the anv perspective) that I put on IRC but may be better in a mail. In no particular order:
1. Having the fd exported from a syncobj be a valid
sync_fileseems like a
fairly pointless feature to me. If we can make things more sane by throwing that out, I'm all for it.2. As far as
sync_fileinteractions go, I think the far more useful thing
would be for you to be able to export async_filefrom a syncobj which would create async_filethat waits on the last submitted signal operation on the syncobj and then have a way of creating a temporary syncobj that has the fence from async_file. Not sure how this would interact with future fences. If we can't figure it out, let's just forget it and not have any defined interaction.
Quoted 4 lines
3. I'd like to also be able to use syncobj for implementing VkFence
sharing. Really, all this means is adrm_syncobj_waitioctl. Yes, with the currentsync_filestuff, you could turn it into async_fileand poll but I'd rather not burn the file descriptors.
Okay this seems like a good goal.
Quoted 4 lines
4. It would be a neat trick if
drm_syncobj_waitcould take a list of
syncobjs and wait on one or all of them as requested by the user. That said, this would be an optimization at best and I'm fine with waiting on them one at a time.
And this.
Quoted 9 lines
5. I'd like to better define what happens when someone tries to wait twice.
I'm a big fan of the semantics of dma-buf dependencies: Each wait operation waits on the most recently queued signal operation. That seems better to me than waiting causing an implicit reset and waiting twice being invalid. Among other things, it means that we don't have to worry bout the semantics of exactly how execbuf fails if you ask it to wait on the same sync file twice. That said, it can be anything we want, I just want it to be well-defined.
I've been thinking about this, and I think you are right, the fact that sems are 1:1 signal:waiter is probably not necessary to enforce in kernel space, if we don't replace the backing fence on a sem with NULL after waiting, I don't think it should break a working userspace, and it will just make things simpler, I can't see any real way a broken userspace can do much damage here either.
Dave.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Dave Airlie
maintainerPATCH 3/8 drm: introduce sync objects as sync file objects with no fd (v2)
In reply to Dave AirlieFrom: Dave Airlie <[email protected]>
Sync objects are new toplevel drm object, that have the same semantics as sync_file objects, but without requiring an fd to be consumed to support them.
This patch just enables the DRM interface to create these objects, it doesn't actually provide any semaphore objects or new features.
v2: do get/put on the sync file file to avoid race (Daniel)
--- Documentation/gpu/drm-internals.rst | 5 + Documentation/gpu/drm-mm.rst | 6 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_fops.c | 8 ++ drivers/gpu/drm/drm_internal.h | 15 ++ drivers/gpu/drm/drm_ioctl.c | 14 ++ drivers/gpu/drm/drm_syncobj.c | 266 ++++++++++++++++++++++++++++++++++++ include/drm/drmP.h | 5 + include/drm/drm_drv.h | 1 + include/uapi/drm/drm.h | 27 ++++ 10 files changed, 348 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/drm_syncobj.c
Documentation/gpu/drm-internals.rst +5 -0
@@ -98,6 +98,11 @@ DRIVER_ATOMIC implement appropriate obj->atomic_get_property() vfuncs for any modeset objects with driver specific properties. +DRIVER_SYNCOBJ + Driver support sync objects. These are just sync files that don't + use a file descriptor. They can be used to implement Vulkan shared + semaphores. + Major, Minor and Patchlevel ~~~~~~~~~~~~~~~~~~~~~~~~~~~
Documentation/gpu/drm-mm.rst +6 -0
@@ -483,3 +483,9 @@ DRM Cache Handling .. kernel-doc:: drivers/gpu/drm/drm_cache.c :export: + +DRM Sync Objects +=========================== + +.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c + :export:
drivers/gpu/drm/Makefile +1 -1
@@ -16,7 +16,7 @@ drm-y := drm_auth.o drm_bufs.o drm_cache.o \ drm_framebuffer.o drm_connector.o drm_blend.o \ drm_encoder.o drm_mode_object.o drm_property.o \ drm_plane.o drm_color_mgmt.o drm_print.o \ - drm_dumb_buffers.o drm_mode_config.o + drm_dumb_buffers.o drm_mode_config.o drm_syncobj.o drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o drm-$(CONFIG_DRM_VM) += drm_vm.o
drivers/gpu/drm/drm_fops.c +8 -0
@@ -219,6 +219,9 @@ static int drm_open_helper(struct file *filp, struct drm_minor *minor)if (drm_core_check_feature (dev,DRIVER_GEM ))drm_gem_open (dev, priv); +if (drm_core_check_feature (dev,DRIVER_SYNCOBJ )) +drm_syncobj_open (priv); +if (drm_core_check_feature (dev,DRIVER_PRIME ))drm_prime_init_file_private (&priv->prime);
@@ -266,6 +269,8 @@ static int drm_open_helper(struct file *filp, struct drm_minor *minor) out_prime_destroy:if (drm_core_check_feature (dev,DRIVER_PRIME ))drm_prime_destroy_file_private (&priv->prime); +if (drm_core_check_feature (dev,DRIVER_SYNCOBJ )) +drm_syncobj_release (priv);if (drm_core_check_feature (dev,DRIVER_GEM ))drm_gem_release (dev, priv);put_pid (priv->pid);
@@ -400,6 +405,9 @@ int drm_release(struct inode *inode, struct file *filp)drm_property_destroy_user_blobs (dev, file_priv); } +if (drm_core_check_feature (dev,DRIVER_SYNCOBJ )) +drm_syncobj_release (file_priv); +if (drm_core_check_feature (dev,DRIVER_GEM ))drm_gem_release (dev, file_priv);
drivers/gpu/drm/drm_internal.h +15 -0
@@ -142,4 +142,19 @@ static inline int drm_debugfs_crtc_crc_add(struct drm_crtc *crtc) {return 0 ; } +#endif + +/* drm_syncobj.c */ +void drm_syncobj_open (struct drm_file *file_private); +void drm_syncobj_release (struct drm_file *file_private); +int drm_syncobj_create_ioctl (struct drm_device *dev,void *data, +struct drm_file *file_private); +int drm_syncobj_destroy_ioctl (struct drm_device *dev,void *data, +struct drm_file *file_private); +int drm_syncobj_handle_to_fd_ioctl (struct drm_device *dev,void *data, +struct drm_file *file_private); +int drm_syncobj_fd_to_handle_ioctl (struct drm_device *dev,void *data, +struct drm_file *file_private); +int drm_syncobj_info_ioctl (struct drm_device *dev,void *data, +struct drm_file *file_private);
drivers/gpu/drm/drm_ioctl.c +14 -0
@@ -240,6 +240,9 @@ static int drm_getcap(struct drm_device *dev, void *data, struct drm_file *file_ req->value |= dev->driver->prime_fd_to_handle ?DRM_PRIME_CAP_IMPORT :0 ; req->value |= dev->driver->prime_handle_to_fd ?DRM_PRIME_CAP_EXPORT :0 ;return 0 ; +case DRM_CAP_SYNCOBJ : + req->value =drm_core_check_feature (dev,DRIVER_SYNCOBJ ); +return 0 ; }/* Other caps only work with KMS drivers */
@@ -641,6 +644,17 @@ static const struct drm_ioctl_desc drm_ioctls[] = {DRM_IOCTL_DEF (DRM_IOCTL_MODE_ATOMIC , drm_mode_atomic_ioctl,DRM_MASTER |DRM_CONTROL_ALLOW |DRM_UNLOCKED ),DRM_IOCTL_DEF (DRM_IOCTL_MODE_CREATEPROPBLOB , drm_mode_createblob_ioctl,DRM_CONTROL_ALLOW |DRM_UNLOCKED ),DRM_IOCTL_DEF (DRM_IOCTL_MODE_DESTROYPROPBLOB , drm_mode_destroyblob_ioctl,DRM_CONTROL_ALLOW |DRM_UNLOCKED ), + +DRM_IOCTL_DEF (DRM_IOCTL_SYNCOBJ_CREATE , drm_syncobj_create_ioctl, +DRM_UNLOCKED |DRM_RENDER_ALLOW ), +DRM_IOCTL_DEF (DRM_IOCTL_SYNCOBJ_DESTROY , drm_syncobj_destroy_ioctl, +DRM_UNLOCKED |DRM_RENDER_ALLOW ), +DRM_IOCTL_DEF (DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD , drm_syncobj_handle_to_fd_ioctl, +DRM_UNLOCKED |DRM_RENDER_ALLOW ), +DRM_IOCTL_DEF (DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE , drm_syncobj_fd_to_handle_ioctl, +DRM_UNLOCKED |DRM_RENDER_ALLOW ), +DRM_IOCTL_DEF (DRM_IOCTL_SYNCOBJ_INFO , drm_syncobj_info_ioctl, + DRM_UNLOCKED|DRM_RENDER_ALLOW), };#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
drivers/gpu/drm/drm_syncobj.c new file +266 -0
266 lines not on this page · raw message
include/drm/drmP.h +5 -0
@@ -405,6 +405,11 @@ struct drm_file {/** Lock for synchronization of access to object_idr. */ spinlock_t table_lock; +/** Mapping of sync object handles to object pointers. */ +struct idr syncobj_idr; +/** Lock for synchronization of access to syncobj_idr. */ +spinlock_t syncobj_table_lock; +struct file *filp;void *driver_priv;
include/drm/drm_drv.h +1 -0
@@ -53,6 +53,7 @@ struct drm_mode_create_dumb;#define DRIVER_RENDER 0x8000#define DRIVER_ATOMIC 0x10000#define DRIVER_KMS_LEGACY_CONTEXT 0x20000 +#define DRIVER_SYNCOBJ 0x40000/** * struct drm_driver - DRM driver structure
include/uapi/drm/drm.h +27 -0
@@ -647,6 +647,7 @@ struct drm_gem_open {#define DRM_CAP_CURSOR_HEIGHT 0x9#define DRM_CAP_ADDFB2_MODIFIERS 0x10#define DRM_CAP_PAGE_FLIP_TARGET 0x11 +#define DRM_CAP_SYNCOBJ 0x12/** DRM_IOCTL_GET_CAP ioctl argument type */ struct drm_get_cap {
@@ -696,6 +697,26 @@ struct drm_prime_handle {__s32 fd; }; +struct drm_syncobj_create_info { +__u32 handle; +__u32 type; +__u32 flags; +__u32 pad; +}; + +struct drm_syncobj_destroy { +__u32 handle; +__u32 pad; +}; + +struct drm_syncobj_handle { +__u32 handle; +/** Flags.. only applicable for handle->fd */ +__u32 flags; + +__s32 fd; +}; +#if defined(__cplusplus) }#endif
@@ -814,6 +835,12 @@ extern "C" {#define DRM_IOCTL_MODE_CREATEPROPBLOB DRM_IOWR(0xBD, struct drm_mode_create_blob)#define DRM_IOCTL_MODE_DESTROYPROPBLOB DRM_IOWR(0xBE, struct drm_mode_destroy_blob) +#define DRM_IOCTL_SYNCOBJ_CREATE DRM_IOWR(0xBF, struct drm_syncobj_create_info) +#define DRM_IOCTL_SYNCOBJ_DESTROY DRM_IOWR(0xC0, struct drm_syncobj_destroy) +#define DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD DRM_IOWR(0xC1, struct drm_syncobj_handle) +#define DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE DRM_IOWR(0xC2, struct drm_syncobj_handle) +#define DRM_IOCTL_SYNCOBJ_INFO DRM_IOWR(0xC3, struct drm_syncobj_create_info) +/** * Device specific ioctls should only be in their respective headers * The device specific ioctl range is from 0x40 to 0x9f.
Signature · 6 lines
2.9.3 _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
Dave Airlie
maintainerPATCH 5/8 sync_file: add support for a semaphore object
In reply to Dave AirlieFrom: Dave Airlie <[email protected]>
This object can be used to implement the Vulkan semaphores.
The object behaviour differs from fence, in that you can replace the underlying fence, and you cannot merge semaphores.
--- drivers/dma-buf/sync_file.c | 36 +++++++++++++++++++++++++++++++++++- include/linux/sync_file.h | 2 ++ include/uapi/linux/sync_file.h | 14 ++++++++++++++ 3 files changed, 51 insertions(+), 1 deletion(-)
drivers/dma-buf/sync_file.c +35 -1
@@ -44,7 +44,7 @@ int sync_file_validate_type_flags(uint32_t type, uint32_t flags) {if (flags)return -EINVAL ; -if (type !=SYNC_FILE_TYPE_FENCE ) +if (type !=SYNC_FILE_TYPE_FENCE && type !=SYNC_FILE_TYPE_SEMAPHORE )return -EINVAL ;return 0 ; }
@@ -202,6 +202,38 @@ sync_file_get_fence_locked(struct sync_file *sync_file) sync_file_held(sync_file)); } +/** +* sync_file_replace_fence - replace the fence related to the sync_file +* @sync_file: sync file to replace fence in +* @fence: fence to replace with (or NULL for no fence). +* Returns previous fence. +*/ +struct dma_fence *sync_file_replace_fence (struct sync_file *sync_file, +struct dma_fence *fence) +{ +struct dma_fence *ret_fence =NULL ; + +if (sync_file->type !=SYNC_FILE_TYPE_SEMAPHORE ) +return NULL ; + +if (fence) +dma_fence_get (fence); + +mutex_lock (&sync_file->lock); + + ret_fence =sync_file_get_fence_locked (sync_file); +if (ret_fence) { +if (test_bit (POLL_ENABLED , &ret_fence->flags)) +dma_fence_remove_callback (ret_fence, &sync_file->cb); + } + +RCU_INIT_POINTER (sync_file->fence, fence); + +mutex_unlock (&sync_file->lock); +return ret_fence; +} +EXPORT_SYMBOL (sync_file_replace_fence); +static int sync_file_set_fence (struct sync_file *sync_file,struct dma_fence **fences,int num_fences) {
@@ -280,6 +312,8 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a,if (a->type != b->type)return NULL ; +if (a->type !=SYNC_FILE_TYPE_FENCE ) +return NULL ;if (!rcu_access_pointer (a->fence) || !rcu_access_pointer (b->fence))
include/linux/sync_file.h +2 -0
@@ -62,4 +62,6 @@ struct sync_file *sync_file_alloc(uint32_t type, uint32_t flags);struct sync_file *sync_file_create (struct dma_fence *fence,uint32_t type,uint32_t flags);struct dma_fence *sync_file_get_fence (int fd);struct sync_file *sync_file_fdget (int fd); +struct dma_fence *sync_file_replace_fence (struct sync_file *sync_file, +struct dma_fence *fence);#endif /* _LINUX_SYNC_H */
include/uapi/linux/sync_file.h +14 -0
@@ -80,6 +80,20 @@ struct sync_file_info {#define SYNC_FILE_TYPE_FENCE 0/** +* DOC: SYNC_FILE_TYPE_SEMAPHORE - semaphore sync file object +* +* This is a sync file that operates like a Vulkan semaphore. +* The object should just be imported/exported but not use the +* sync file ioctls (except info). +* This object can have it's backing fence replaced multiple times. +* Each signal operation assigns a backing fence. +* Each wait operation waits on the current fence, and removes it. +* These operations should happen via driver command submission interfaces. +* This is useful for shared vulkan semaphores. +*/ +#define SYNC_FILE_TYPE_SEMAPHORE 1 + +/** * struct sync_file_type - data returned from sync file type ioctl * @type: sync_file type * @flags: sync_file creation flags
Signature · 6 lines
2.9.3 _______________________________________________ dri-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/dri-devel
A message that is not in the archive (sent off-list or not yet received): 20170411032220.21101-6-airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Re: [PATCH 5/8] sync_file: add support for a semaphore object
Quoted 23 lines · Dave Airlie
From: Dave Airlie <[email protected]>
This object can be used to implement the Vulkan semaphores.
The object behaviour differs from fence, in that you can replace the underlying fence, and you cannot merge semaphores.
Signed-off-by Dave Airlie <[email protected]>---
drivers/dma-buf/sync_file.c +14
-0+/** +* sync_file_replace_fence - replace the fence related to the sync_file +* @sync_file: sync file to replace fence in +* @fence: fence to replace with (or NULL for no fence). +* Returns previous fence. +*/ +struct dma_fence *sync_file_replace_fence (struct sync_file *sync_file, +struct dma_fence *fence) +{ +struct dma_fence *ret_fence =NULL ; + +if (sync_file->type !=SYNC_FILE_TYPE_SEMAPHORE ) +return NULL ; +
drivers/dma-buf/sync_file.c sync_file_get_fence_locked(struct sync_file *sync_file) · line 228
Quoted 10 lines
drivers/dma-buf/sync_file.c +10
-0+if (fence) +dma_fence_get (fence); + +mutex_lock (&sync_file->lock); + + ret_fence =sync_file_get_fence_locked (sync_file); +if (ret_fence) { +if (test_bit (POLL_ENABLED , &ret_fence->flags)) +dma_fence_remove_callback (ret_fence, &sync_file->cb); + }
Fails when sync_file_replace_fence is passed sync_file->fence.
if (test_and_clear_bit(POLL_ENABLED, &ret_fence->flags)) {
dma_fence_remove_callback(ret_fence, &sync_file->cb);
wake_up(&sync_file->wq); /* only needs the first to redo the add */
}will get the waiter to reset the callback on a new fence, or the old fence replacing itself. Otherwise the waiter will never be woken over the change in fence, not even when the old or new fence is signaled. -Chris
Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Dave Airlie
maintainerRe: [PATCH 5/8] sync_file: add support for a semaphore object
Quoted 28 lines · Chris Wilson
Quoted 27 lines · Dave Airlie
From: Dave Airlie <[email protected]>
This object can be used to implement the Vulkan semaphores.
The object behaviour differs from fence, in that you can replace the underlying fence, and you cannot merge semaphores.
Signed-off-by Dave Airlie <[email protected]>---
drivers/dma-buf/sync_file.c +18
-0+/** +* sync_file_replace_fence - replace the fence related to the sync_file +* @sync_file: sync file to replace fence in +* @fence: fence to replace with (or NULL for no fence). +* Returns previous fence. +*/ +struct dma_fence *sync_file_replace_fence (struct sync_file *sync_file, +struct dma_fence *fence) +{ +struct dma_fence *ret_fence =NULL ; + +if (sync_file->type !=SYNC_FILE_TYPE_SEMAPHORE ) +return NULL ; + +if (fence) +dma_fence_get (fence); + +mutex_lock (&sync_file->lock);
Quoted 8 lines
drivers/dma-buf/sync_file.c sync_file_get_fence_locked(struct sync_file *sync_file) · line 228
Quoted 6 lines
drivers/dma-buf/sync_file.c +6
-0+ + ret_fence =sync_file_get_fence_locked (sync_file); +if (ret_fence) { +if (test_bit (POLL_ENABLED , &ret_fence->flags)) +dma_fence_remove_callback (ret_fence, &sync_file->cb); + }Fails when
sync_file_replace_fenceis passedsync_file->fence.
Not sure what the best semantics are there, any opinions on barring wakeups/polling on semaphore sync_files, and just punting this until we need it.
It would definitely simplify things.
Dave.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
A message that is not in the archive (sent off-list or not yet received): CAPM=9tzgNoSXPoZfJbRcoRmGZL9gENo+TTZCbauMjB7mwayZxw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Re: [PATCH 5/8] sync_file: add support for a semaphore object
Quoted 38 lines · Dave Airlie
Quoted 28 lines · Chris Wilson
Quoted 27 lines · Dave Airlie
From: Dave Airlie <[email protected]>
This object can be used to implement the Vulkan semaphores.
The object behaviour differs from fence, in that you can replace the underlying fence, and you cannot merge semaphores.
Signed-off-by Dave Airlie <[email protected]>---
drivers/dma-buf/sync_file.c +18
-0+/** +* sync_file_replace_fence - replace the fence related to the sync_file +* @sync_file: sync file to replace fence in +* @fence: fence to replace with (or NULL for no fence). +* Returns previous fence. +*/ +struct dma_fence *sync_file_replace_fence (struct sync_file *sync_file, +struct dma_fence *fence) +{ +struct dma_fence *ret_fence =NULL ; + +if (sync_file->type !=SYNC_FILE_TYPE_SEMAPHORE ) +return NULL ; + +if (fence) +dma_fence_get (fence); + +mutex_lock (&sync_file->lock);Quoted 8 lines
drivers/dma-buf/sync_file.c sync_file_get_fence_locked(struct sync_file *sync_file) · line 228
Quoted 6 lines
drivers/dma-buf/sync_file.c +6
-0+ + ret_fence =sync_file_get_fence_locked (sync_file); +if (ret_fence) { +if (test_bit (POLL_ENABLED , &ret_fence->flags)) +dma_fence_remove_callback (ret_fence, &sync_file->cb); + }Fails when
sync_file_replace_fenceis passedsync_file->fence.
Quoted 3 lines
Not sure what the best semantics are there, any opinions on barring wakeups/polling on semaphore
sync_files, and just punting this until we need it.
I think getting it right now will make writing sw_sync-esque (i.e. cpu) tests easier and more complete.
-Chris
Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): 20170412103116.GL4250-aII6DKEyn0pWYbfKqPwjAkR8Iwp7RQ6xAL8bYrjMMd8@public.gmane.org
Re: [PATCH 5/8] sync_file: add support for a semaphore object
Quoted 7 lines
Quoted 4 lines
Not sure what the best semantics are there, any opinions on barring wakeups/polling on semaphore
sync_files, and just punting this until we need it.I think getting it right now will make writing sw_sync-esque (i.e. cpu) tests easier and more complete.
I just don't have any use case for it, so we would be writing code to write tests for it.
That doesn't seem smart.
If there is a future non-testing use case, the API is expressive enough for someone
to add a flag or new sync obj to allow polling and to add support in a nice easily
digestible patch.
Dave.
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): CAPM=9tyiKAH-T2rxwcqxc=LWZ8o_5TyxV3GVhy_JKZv3PZQsCw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Re: [PATCH 5/8] sync_file: add support for a semaphore object
Quoted 11 lines · Dave Airlie
Quoted 7 lines
Quoted 4 lines
Not sure what the best semantics are there, any opinions on barring wakeups/polling on semaphore
sync_files, and just punting this until we need it.I think getting it right now will make writing sw_sync-esque (i.e. cpu) tests easier and more complete.
I just don't have any use case for it, so we would be writing code to write tests for it.
Quoted 7 lines
That doesn't seem smart.
If there is a future non-testing use case, the API is expressive enough for someone
to add a flag or new sync obj to allow polling and to add support in a nice easily
digestible patch.
My first thought was to check the signaled status would be to use poll(0), but that can be retrieved from the sync_file_status ioctl. But to get that still needs for us to acquire an fd from the syncobj. And if we were to want check the flag on a driver syncobj, we would need to be able to export one. That doesn't look very promising...
The testing chain would look like
create syncobj execbuf -> signal syncobj syncobj wait -> dummy/nop execbuf -> fence out
then use the fence as a proxy for testing the status of the syncobj.
For generic tests, we could add an interface for vgem to use syncobjs?
If there's no way to export an fd for the syncobj, then we don't need to handle it in the fops. Just be sure to leave a breadcrumb behind so that the first person who does try to pass back a syncobj fd is reminded that they need to fill in the fops.
-Chris
Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): 20170412200132.GJ12532-aII6DKEyn0pWYbfKqPwjAkR8Iwp7RQ6xAL8bYrjMMd8@public.gmane.org
Re: [PATCH 5/8] sync_file: add support for a semaphore object
Quoted 20 lines · Chris Wilson
Quoted 11 lines · Dave Airlie
Quoted 7 lines
Quoted 4 lines
Not sure what the best semantics are there, any opinions on barring wakeups/polling on semaphore
sync_files, and just punting this until we need it.I think getting it right now will make writing sw_sync-esque (i.e. cpu) tests easier and more complete.
I just don't have any use case for it, so we would be writing code to write tests for it.
Quoted 7 lines
That doesn't seem smart.
If there is a future non-testing use case, the API is expressive enough for someone
to add a flag or new sync obj to allow polling and to add support in a nice easily
digestible patch.
Quoted 5 lines
My first thought was to check the signaled status would be to use poll(0), but that can be retrieved from the
sync_file_statusioctl. But to get that still needs for us to acquire an fd from the syncobj. And if we were to want check the flag on a driver syncobj, we would need to be able to export one. That doesn't look very promising...
Hmm, you do export fd to pass syncobj between processes. Let's not start with syncobj being a second class sync_file.
-Chris
Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Dave Airlie
maintainerRe: [PATCH 5/8] sync_file: add support for a semaphore object
Quoted 21 lines · Chris Wilson
Quoted 20 lines · Chris Wilson
Quoted 18 lines · Dave Airlie
Quoted 7 lines
Quoted 4 lines
Not sure what the best semantics are there, any opinions on barring wakeups/polling on semaphore
sync_files, and just punting this until we need it.I think getting it right now will make writing sw_sync-esque (i.e. cpu) tests easier and more complete.
I just don't have any use case for it, so we would be writing code to write tests for it.
That doesn't seem smart.
If there is a future non-testing use case, the API is expressive enough for someone
to add a flag or new sync obj to allow polling and to add support in a nice easily
digestible patch.
Quoted 8 lines
Quoted 5 lines
My first thought was to check the signaled status would be to use poll(0), but that can be retrieved from the
sync_file_statusioctl. But to get that still needs for us to acquire an fd from the syncobj. And if we were to want check the flag on a driver syncobj, we would need to be able to export one. That doesn't look very promising...Hmm, you do export fd to pass syncobj between processes. Let's not start with syncobj being a second class
sync_file.
It's not the same semantics as a sync_file. Userspace should never be polling on semaphores.
Semaphores are one process signals, one process waits, no semantics for sniffing or use cases. Unless you have a practical use case for an new or proposed
API I don't think we should start with adding functionality.
Dave.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
A message that is not in the archive (sent off-list or not yet received): CAPM=9tyk2NvVTfzEmm+psYv2BfL3xNKhEq_CE7gGeHmS3R9BMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Re: [PATCH 5/8] sync_file: add support for a semaphore object
Quoted 31 lines · Dave Airlie
Quoted 21 lines · Chris Wilson
Quoted 20 lines · Chris Wilson
Quoted 18 lines · Dave Airlie
Quoted 7 lines
Quoted 4 lines
Not sure what the best semantics are there, any opinions on barring wakeups/polling on semaphore
sync_files, and just punting this until we need it.I think getting it right now will make writing sw_sync-esque (i.e. cpu) tests easier and more complete.
I just don't have any use case for it, so we would be writing code to write tests for it.
That doesn't seem smart.
If there is a future non-testing use case, the API is expressive enough for someone
to add a flag or new sync obj to allow polling and to add support in a nice easily
digestible patch.Quoted 8 lines
Quoted 5 lines
My first thought was to check the signaled status would be to use poll(0), but that can be retrieved from the
sync_file_statusioctl. But to get that still needs for us to acquire an fd from the syncobj. And if we were to want check the flag on a driver syncobj, we would need to be able to export one. That doesn't look very promising...Hmm, you do export fd to pass syncobj between processes. Let's not start with syncobj being a second class
sync_file.
Quoted 7 lines
It's not the same semantics as a
sync_file. Userspace should never be polling on semaphores.Semaphores are one process signals, one process waits, no semantics for sniffing or use cases. Unless you have a practical use case for an new or proposed
API I don't think we should start with adding functionality.
The problem, as I see it, is that you are taking functionality away from sync_file. If you are wrapping them up inside a sync_file, we have a fair expectation that our code to handle sync_files will continue to work.
-Chris
Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Dave Airlie
maintainerRe: [PATCH 5/8] sync_file: add support for a semaphore object
Quoted 5 lines
The problem, as I see it, is that you are taking functionality away from
sync_file. If you are wrapping them up inside async_file, we have a fair expectation that our code to handlesync_fileswill continue to work.
What code? there is no code existing that should be sharing sync objects with semaphores backing them, and trying to use them as sync_files.
This is parallel functionality.
Dave.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel
A message that is not in the archive (sent off-list or not yet received): CAPM=9tzx8TjPUQ0qH0j=b=U_RyGerCjCNb+2feTuuONB9iRkqA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Re: [PATCH 5/8] sync_file: add support for a semaphore object
Quoted 8 lines · Dave Airlie
Quoted 5 lines
The problem, as I see it, is that you are taking functionality away from
sync_file. If you are wrapping them up inside async_file, we have a fair expectation that our code to handlesync_fileswill continue to work.What code? there is no code existing that should be sharing sync objects with semaphores backing them, and trying to use them as
sync_files.
By masquerading semaphores as sync_files, you are inviting them to be used with the existing code to handle sync_file.
Quoted 1 line
This is parallel functionality.
And quite different from the existing CPU visible sync_files. Why try stuffing them through the same interface? At the moment the only thing they have in common is the single fence pointer, and really you want them just for their handle/fd to a GPU channel.
After you strip out the fops from the semaphore code, doesn't it boil down to:
static void semaphore_file_release(struct inode *inode, struct file *file)
{
struct semaphore_file *s = file->private_data;
dma_fence_put(s->fence);
kfree(s);
}static const struct file_operations semaphore_file_fops = {
.release = semaphore_file_release,
};
struct semaphore_file *semaphore_file_create(void)
{
struct semaphore_file *s;
s = kzalloc(sizeof(*s), GFP_KERNEL);
if (!s)
return NULL;
s->file = anon_inode_getfile("semaphore_"file",
&semaphore_file_fops, s, 0);
return s;
}Plus your new routines to manipulate the semaphore.
The commonality with the current sync_file {
struct file *file; struct dma_fence *fence; };
could be extracted and sync_file become fence_file. Would it not help to avoid any further confusion by treating them as two very distinct classes of fd?
And for me to stop calling the user interface sync_file. -Chris
Signature · 5 lines
Chris Wilson, Intel Open Source Technology Centre _______________________________________________ amd-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/amd-gfx
A message that is not in the archive (sent off-list or not yet received): 20170412223438.GQ12532-aII6DKEyn0pWYbfKqPwjAkR8Iwp7RQ6xAL8bYrjMMd8@public.gmane.org
Re: [PATCH 5/8] sync_file: add support for a semaphore object
Quoted 7 lines · Chris Wilson
Quoted 6 lines · Dave Airlie
Quoted 5 lines
The problem, as I see it, is that you are taking functionality away from
sync_file. If you are wrapping them up inside async_file, we have a fair expectation that our code to handlesync_fileswill continue to work.
Quoted 5 lines
Quoted 2 lines
What code? there is no code existing that should be sharing sync objects with semaphores backing them, and trying to use them as
sync_files.By masquerading semaphores as
sync_files, you are inviting them to be used with the existing code to handlesync_file.
But what existing code is going to get a sync object from another process and blindly use it without knowing where it got it.
I'm not buying the argument that just because something is possible, we have to support it.
Quoted 38 lines
And quite different from the existing CPU visible
sync_files. Why try stuffing them through the same interface? At the moment the only thing they have in common is the single fence pointer, and really you want them just for their handle/fd to a GPU channel.After you strip out the fops from the semaphore code, doesn't it boil down to:
static void
semaphore_file_release(struct inode *inode, struct file *file){ struct semaphore_file *s = file->private_data; dma_fence_put(s->fence); kfree(s); }static const struct
file_operationssemaphore_file_fops= {
.release =semaphore_file_release,
};struct
semaphore_file*semaphore_file_create(void){ struct semaphore_file *s; s = kzalloc(sizeof(*s), GFP_KERNEL); if (!s) return NULL; s->file = anon_inode_getfile("semaphore_"file", &semaphore_file_fops, s, 0); return s; }Plus your new routines to manipulate the semaphore.
The commonality with the current
sync_file{
Quoted 8 lines
struct file *file; struct dma_fence *fence; };could be extracted and
sync_filebecomefence_file. Would it not help to avoid any further confusion by treating them as two very distinct classes of fd?And for me to stop calling the user interface
sync_file.
That's a better argument, but the consideration is that there are probably use-cases for doing something with these in the future, and we'd be limiting those by doing this. The current code adds the API we need without constraining future use cases overly much, and avoids any pitfalls.
I'll consider whether we should just split sync_file, but you still have the same problems you mention, you get an fd you do something you shouldn't with it, it doesn't fix any of the problems you are raising.
If you have an opaque fd you don't know the providence of, and except some operations to just work o nit, you are going to be disappointed.
Dave.
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx