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 15:12 schrieb Daniel Stone:
> Hi,
>
> On Wed, 26 May 2021 at 13:46, Christian König <christian.koenig@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.

Regards,
Christian.

>
> Cheers,
> Daniel