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

[Christian König]

Am 27.05.21 um 12:33 schrieb Daniel Vetter:
> On Wed, May 26, 2021 at 03:23:01PM +0200, Christian König wrote:
>>
>> Am 26.05.21 um 15:12 schrieb Daniel Stone:
>>> Hi,
>>>
>>> On Wed, 26 May 2021 at 13:46, Christian König <christian.koenig at amd.com> wrote:
>>>> Am 26.05.21 um 13:31 schrieb Daniel Stone:
>>>>> 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?
>>> Yeah, I can see that to an extent. But then binary vs. timeline
>>> syncobjs are very different in use (which is unfortunate tbh), and
>>> then we have an asymmetry between syncobj export & sync_file import.
>>>
>>> You're right that we do want a syncobj though. This is probably not
>>> practical due to smashing uAPI to bits, but if we could wind the clock
>>> back a couple of years, I suspect the interface we want is that export
>>> can either export a sync_file or a binary syncobj, and further that
>>> binary syncobjs could transparently act as timeline semaphores by
>>> mapping any value (either wait or signal) to the binary signal. In
>>> hindsight, we should probably just never have had binary syncobj. Oh
>>> well.
>> Well the later is the case IIRC. Don't ask me for the detail semantics, but
>> in general the drm_syncobj in timeline mode is compatible to the binary
>> mode.
>>
>> The sync_file is also import/exportable to a certain drm_syncobj timeline
>> point (or as binary signal). So no big deal, we are all compatible here :)
>>
>> I just thought that it might be more appropriate to return a drm_syncobj
>> directly instead of a sync_file.
> I think another big potential user for this is a vk-based compositor which
> needs to interact/support implicit synced clients. And compositor world I
> think is right now still more sync_file (because that's where we started
> with atomic kms ioctl).
>
> The other slight nudge is that drm_syncobj is a drm thing, so we'd first
> need to lift it out into drivers/dma-buf (and hand-wave the DRM prefix
> away) for it to be a non-awkward fit for dma-buf.
>
> Plus you can convert them to the other form anyway, so really doesn't
> matter much. But for the above reasons I'm leaning slightly towards
> sync_file. Except if compositor folks tell me I'm a fool and why :-)

Yeah as discussed with a Jason already that drm_syncobj is DRM specific 
is the killer argument here. So sync_file is fine with me.

Christian.

> -Daniel