OK. I was confused because the name has_syncobj_wait suggests that it's about amdgpu_cs_syncobj_wait, not WAIT_FOR_SUBMIT.
Marek On Wed, Dec 27, 2017 at 1:18 AM, Bas Nieuwenhuizen <[email protected]> wrote: > For vulkan, I wanted this because of > > drm/syncobj: Allow wait for submit and signal behavior (v5) > > Vulkan VkFence semantics require that the application be able to perform > a CPU wait on work which may not yet have been submitted. This is > perfectly safe because the CPU wait has a timeout which will get > triggered eventually if no work is ever submitted. This behavior is > advantageous for multi-threaded workloads because, so long as all of the > threads agree on what fences to use up-front, you don't have the extra > cross-thread synchronization cost of thread A telling thread B that it > has submitted its dependent work and thread B is now free to wait. > > Within a single process, this can be implemented in the userspace driver > by doing exactly the same kind of tracking the app would have to do > using posix condition variables or similar. However, in order for this > to work cross-process (as is required by VK_KHR_external_fence), we need > to handle this in the kernel. > > This commit adds a WAIT_FOR_SUBMIT flag to DRM_IOCTL_SYNCOBJ_WAIT which > instructs the IOCTL to wait for the syncobj to have a non-null fence and > then wait on the fence. Combined with DRM_IOCTL_SYNCOBJ_RESET, you can > easily get the Vulkan behavior. > > > I suppose you could use an earlier DRM version if you don't need it. > IMO we should keep them separate, as on radv semaphores don't need any > wait functionality at all. > > On Tue, Dec 26, 2017 at 6:29 PM, Marek Olšák <[email protected]> wrote: >> Does this mean that radeonsi shouldn't use amdgpu_cs_syncobj_wait on older >> DRM? >> >> Does it make sense to have separate has_syncobj and has_syncobj_wait flags? >> >> Marek >> >> On Sun, Dec 17, 2017 at 1:11 AM, Bas Nieuwenhuizen >> <[email protected]> wrote: >>> First amdgpu bump after inclusion was 20 (which was done for local BOs). >>> --- >>> src/amd/common/ac_gpu_info.c | 1 + >>> src/amd/common/ac_gpu_info.h | 1 + >>> 2 files changed, 2 insertions(+) >>> >>> diff --git a/src/amd/common/ac_gpu_info.c b/src/amd/common/ac_gpu_info.c >>> index 0576dd369cf..c042bb229ce 100644 >>> --- a/src/amd/common/ac_gpu_info.c >>> +++ b/src/amd/common/ac_gpu_info.c >>> @@ -277,6 +277,7 @@ bool ac_query_gpu_info(int fd, amdgpu_device_handle dev, >>> vce.available_rings ? vce_version : 0; >>> info->has_userptr = true; >>> info->has_syncobj = has_syncobj(fd); >>> + info->has_syncobj_wait = info->has_syncobj && info->drm_minor >= 20; >>> info->has_sync_file = info->has_syncobj && info->drm_minor >= 21; >>> info->has_ctx_priority = info->drm_minor >= 22; >>> info->num_render_backends = amdinfo->rb_pipes; >>> diff --git a/src/amd/common/ac_gpu_info.h b/src/amd/common/ac_gpu_info.h >>> index 5b9e51658b0..04e17f91c59 100644 >>> --- a/src/amd/common/ac_gpu_info.h >>> +++ b/src/amd/common/ac_gpu_info.h >>> @@ -81,6 +81,7 @@ struct radeon_info { >>> uint32_t drm_patchlevel; >>> bool has_userptr; >>> bool has_syncobj; >>> + bool has_syncobj_wait; >>> bool has_sync_file; >>> bool has_ctx_priority; >>> >>> -- >>> 2.15.1 >>> >>> _______________________________________________ >>> mesa-dev mailing list >>> [email protected] >>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
