On Wed, Mar 15, 2017 at 11:09:39AM +1000, Dave Airlie wrote: > On 14 March 2017 at 18:53, Daniel Vetter <daniel at ffwll.ch> wrote: > > On Tue, Mar 14, 2017 at 10:50:49AM +1000, Dave Airlie wrote: > >> This contains one libdrm patch and 4 kernel patches. > >> > >> The goal is to implement the Vulkan KHR_external_semaphore_fd interface > >> for permanent semaphore behaviour for radv. > >> > >> This code tries to enhance sync file to add the required behaviour > >> (which is mostly being able to replace the fence backing the sync file), > >> it also introduces new API to amdgpu to create/destroy/export/import the > >> sync_files which we store in an idr there, rather than fds. > >> > >> There is a possibility we should share the amdgpu_sem object tracking > >> code for other drivers, maybe we should move that to sync_file as well, > >> but I'm open to suggestions for whether this is a useful approach for > >> other drivers. > > > > Yeah, makes sense. I couldn't google the spec and didn't bother to figure > > out where my intel khronos login went, so didn't double-check precise > > semantics, just dropped a question. Few more things on the actual > > sync_file stuff itself. > > > > Really big wish here is for some igts using the debug/testing fence stuff > > we have in vgem so that we can validate the corner-cases of fence > > replacement and make sure nothing falls over. Especially with all the rcu > > dancing sync_file/dma_fence have become non-trival, exhaustive testing is > > needed here imo. > > We'd have to add vgem specific interfaces to trigger the replacement > path though, > since the replacement path is only going to be used for the semaphore sematics. > > Suggestions on how to test better welcome! Yeah, vgem semaphore replacement ioctl is what I had in mind. And I guess if you don't get around to it, we will when we do the i915 side of this :-) -Daniel > > > > > Also, NULL sync_file->fence is probably what we want for the future fences > > (which android wants to keep tilers well-fed by essentially looping the > > entire render pipeline on itself), so this goes into the right direction > > for sure. I think, but coffee kicked in already :-) > > Dave. -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
