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/
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
