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.
Regards, Christian.
I haven't used rcu anywhere here, I've used xchg to swap fence pointers in the hope that's safe. If this does need rcu'ing I suggest we do it in a follow on patch to minimise the review pain. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
