[rfc] drm sync objects (search for spock)

[Dave Airlie]

On 26 April 2017 at 18:45, Christian König <deathsimple at vodafone.de> wrote:
> Am 26.04.2017 um 05:28 schrieb Dave Airlie:
>>
>> Okay I've gone around the sun with these a few times, and
>> pretty much implemented what I said last week.
>>
>> This is pretty much a complete revamp.
>>
>> 1. sync objects are self contained drm objects, they
>> have a file reference so can be passed between processes.
>>
>> 2. Added a sync object wait interface modelled on the vulkan
>> fence waiting API.
>>
>> 3. sync_file interaction is explicitly different than
>> opaque fd passing, you import a sync file state into an
>> existing syncobj, or create a new sync_file from an
>> existing syncobj. This means no touching the sync file code
>> at all. \o/
>
>
> Doesn't that break the Vulkan requirement that if a sync_obj is exported to
> an fd and imported on the other side we get the same sync_obj again?
>
> In other words the fd is exported and imported only once and the expectation
> is that we fence containing it will change on each signaling operation.
>
> As far as I can see with the current implementation you get two sync_objects
> on in the exporting process and one in the importing one.

Are you talking about using sync_file interop for vulkan, then yes
that would be wrong.

But that isn't how this works, see 1. above the sync obj has a 1:1
mapping with an
opaque fd (non-sync_file) that is only used for interprocess passing
of the syncobj.

You can interoperate with sync_files by importing/exporting the
syncobj fence into
and out of them but that aren't meant for passing the fds around, more
for where you
get a sync_file fd from somewhere else and you want to use it and vice-versa.

I'd like to move any drm APIs away from sync_file to avoid the fd wastages, I'd
also like to move the driver specific fences to syncobj where I can.

Dave.