[Mesa-dev] [PATCH 3/6] amd/common: Add detection of the syncobj wait/signal/reset ioctls.

[Marek Olšák]

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
<bas at basnieuwenhuizen.nl> 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 <maraeo at gmail.com> 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
>> <bas at basnieuwenhuizen.nl> 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
>>> mesa-dev at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev