Re: [rfc] drm sync objects (search for spock)

[Jason Ekstrand <jason@jlekstrand.net>]

[-- Attachment #1.1: Type: text/plain, Size: 3346 bytes --]

On Wed, Apr 26, 2017 at 7:57 AM, Christian König <deathsimple@vodafone.de>
wrote:

> Am 26.04.2017 um 11:57 schrieb Dave Airlie:
>
>> On 26 April 2017 at 18:45, Christian König <deathsimple@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/
>>>>
>>>
I've done a quick scan over the patches and I like the API.  It almost
looks as if Santa read my wish list. :-)

That said, it was a "quick scan" so don't take this as any sort of actual
code review.  It'll probably be a little while before I get a chance to sit
down and look at i915 again but things seem reasonable.


> 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.
>>
>
> Ah, ok that makes some more sense.
>
> 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 would prefer dealing only with one type of fd in userspace, but that
> approach should work as well.
>
> I'd like to move any drm APIs away from sync_file to avoid the fd wastages,
>>
>
> That sounds like it make sense, but I would still rather vote for
> extending the sync_file interface than deprecating it with another one.
>
> I'd also like to move the driver specific fences to syncobj where I can.
>>
>
> I'm pretty sure that is not a good idea.
>
> Beating the sequence based fence values we currently use for CPU sync in
> performance would be pretty hard. E.g. at least on amdgpu we can even check
> those by doing a simple 64bit read from a memory address, without IOCTL or
> any other overhead involved.
>
> Regards,
> Christian.
>
>
>
>> Dave.
>>
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[-- Attachment #1.2: Type: text/html, Size: 5480 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel