On Wed, Apr 26, 2017 at 7:57 AM, Christian König <deathsimple at vodafone.de> wrote: > Am 26.04.2017 um 11:57 schrieb Dave Airlie: > >> 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/ >>>> >>> 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 at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170509/2ff094cf/attachment.html>
