Hi Christian,
On Wed, 26 May 2021 at 12:02, Christian König christian.koenig@amd.com wrote:
Am 25.05.21 um 23:17 schrieb Jason Ekstrand:
This new IOCTL solves this problem by allowing us to get a snapshot of the implicit synchronization state of a given dma-buf in the form of a sync file. It's effectively the same as a poll() or I915_GEM_WAIT only, instead of CPU waiting directly, it encapsulates the wait operation, at the current moment in time, in a sync_file so we can check/wait on it later. As long as the Vulkan driver does the sync_file export from the dma-buf before we re-introduce it for rendering, it will only contain fences from the compositor or display. This allows to accurately turn it into a VkFence or VkSemaphore without any over- synchronization.
Regarding that, why do we actually use a syncfile and not a drm_syncobj here?
The later should be much closer to a Vulkan timeline semaphore.
How would we insert a syncobj+val into a resv though? Like, if we pass an unmaterialised syncobj+val here to insert into the resv, then an implicit-only media user (or KMS) goes to sync against the resv, what happens?
Cheers, Daniel