Hi Christian, David,
Sorry to report this so late in the process, but I think we found an
issue not directly related to syncobj timelines themselves but with a
side effect of the threaded submissions.
Essentially we're failing a test in crucible :
func.sync.semaphore-fd.opaque-fd
This test create a single binary semaphore, shares it between 2
VkDevice/VkQueue.
Then in a loop it proceeds to submit workload alternating between the 2
VkQueue with one submit depending on the other.
It does so by waiting on the VkSemaphore signaled in the previous
iteration and resignaling it.
The problem for us is that once things are dispatched to the submission
thread, the ordering of the submission is lost.
Because we have 2 devices and they both have their own submission thread.
Jason suggested that we reestablish the ordering by having
semaphores/syncobjs carry an additional uint64_t payload.
This 64bit integer would represent be an identifier that submission
threads will WAIT_FOR_AVAILABLE on.
The scenario would look like this :
- vkQueueSubmit(queueA, signal on semA);
- in the caller thread, this would increment the syncobj
additional u64 payload and return it to userspace.
- at some point the submission thread of queueA submits the
workload and signal the syncobj of semA with value returned in the
caller thread of vkQueueSubmit().
- vkQueueSubmit(queueB, wait on semA);
- in the caller thread, this would read the syncobj additional
u64 payload
- at some point the submission thread of queueB will try to
submit the work, but first it will WAIT_FOR_AVAILABLE the u64 value
returned in the step above
Because we want the binary semaphores to be shared across processes and
would like this to remain a single FD, the simplest location to store
this additional u64 payload would be the DRM syncobj.
It would need an additional ioctl to read & increment the value.
What do you think?
-Lionel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
