Re: [rfc] drm sync objects (search for spock)
On Wed, Apr 26, 2017 at 7:57 AM, Christian König wrote: > Am 26.04.2017 um 11:57 schrieb Dave Airlie: > >> On 26 April 2017 at 18:45, Christian König >> 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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [rfc] drm sync objects (search for spock)
Am 26.04.2017 um 11:57 schrieb Dave Airlie: On 26 April 2017 at 18:45, Christian König 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [rfc] drm sync objects (search for spock)
On 26 April 2017 at 18:45, Christian König 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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [rfc] drm sync objects (search for spock)
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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[rfc] drm sync objects (search for spock)
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 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel