[Intel-gfx] [PATCH 5/7] dma-buf: Add an API for exporting sync files (v11)

[Daniel Stone]

Hi Christian,

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