On 07/08/2019 16:49, Koenig, Christian wrote:
Well first of all I strongly suggest to make the sideband information a
separate IOCTL and not use the existing signal/query IOCTLs for it.


It felt like at least the query ioctl was the right place to get the sideband value.

I can change.



Then as far as I see this basically sets a sequence number to use for
binary semaphores, is that correct? If yes then that would be a rather
elegant idea.


Yeah that's pretty much it. From the vulkan API point view, this doesn't even need to be atomic, it just needs to happen within vkQueueSubmit().


Again to explain the issue, it's that syncobj is container and we might race picking up the fence from one thread while the submission thread updates the fence.

Essentially reusing the fence chain mechanism solve the issue because we can wait on a particular replacement sequence number (matching a vkQueueSubmit() call).


-Lionel



Christian.

Am 07.08.19 um 15:37 schrieb Lionel Landwerlin:
Hi,

The goal of this feature is to solve an issue that was seen in our
testing. After discussing on [1] I thought we could solve this problem
with stalling the application thread after each vkQueueSubmit() call
where a binary semaphore is signaled but I don't think it's a good
option because of performance impacts on the application.

Unfortunately there isn't a good way to reproduce this problem 100%
because it essentially exposes a race between the application thread
and the submission thread.

I've uploaded tests in the Khronos repository to try to expose the
issue.

Thanks,

[1] : https://lists.freedesktop.org/archives/dri-devel/2019-August/229188.html

Lionel Landwerlin (2):
    drm/syncobj: add sideband payload
    drm/syncobj: add submit point query capability

   drivers/gpu/drm/drm_syncobj.c | 132 ++++++++++++++++++++++------------
   include/drm/drm_syncobj.h     |   9 +++
   include/uapi/drm/drm.h        |   5 +-
   3 files changed, 100 insertions(+), 46 deletions(-)

--
2.23.0.rc1


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to