On Wed, Apr 26, 2017 at 7:57 AM, Christian König <deathsimple@xxxxxxxxxxx> wrote:
Am 26.04.2017 um 11:57 schrieb Dave Airlie:
On 26 April 2017 at 18:45, Christian König <deathsimple@xxxxxxxxxxx> 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.
Ah, ok that makes some more sense.Doesn't that break the Vulkan requirement that if a sync_obj is exported toAre you talking about using sync_file interop for vulkan, then yes
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.
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 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@xxxxxxxxxxxxxxxxxxxxg
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
