Hi Christian, On Wed, 26 May 2021 at 12:02, Christian König <christian.koenig@xxxxxxx> 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
