Am 26.05.21 um 13:31 schrieb Daniel Stone:
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?
Well this is for exporting, not importing. So we don't need to worry about that.
It's just my thinking because the drm_syncobj is the backing object on VkSemaphore implementations these days, isn't it?
Christian.
Cheers, Daniel