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.
