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

["Christian König" <christian.koenig@amd.com>]

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