On Thu, Feb 18, 2021 at 9:03 PM Andrey Grodzovsky <Andrey.Grodzovsky@xxxxxxx> wrote: > > Looked a bit into it, I want to export sync_object to FD and import from that FD > such that I will wait on the imported sync object handle from one thread while > signaling the exported sync object handle from another (post device unplug) ? > > My problem is how to create a sync object with a non signaled 'fake' fence ? > I only see API that creates it with already signaled fence (or none) - > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_syncobj.c#L56 > > P.S I expect the kernel to crash since unlike with dma_bufs we don't hold > drm device reference here on export. Well maybe there's no crash. I think if you go through all your dma_fence that you have and force-complete them, then I think external callers wont go into the driver anymore. But there's still pointers potentially pointing at your device struct and all that, but should work. Still needs some audit ofc. Wrt how you get such a free-standing fence, that's amdgpu specific. Roughly - submit cs - get the fence for that (either sync_file, but I don't think amdgpu supports that, or maybe through drm_syncobj) - hotunplug - wait on that fence somehow (drm_syncobj has direct uapi for this, same for sync_file I think) Cheers, Daniel > > Andrey > > On 2/9/21 4:50 AM, Daniel Vetter wrote: > > Yeah in the end we'd need 2 hw devices for testing full fence > > functionality. A useful intermediate step would be to just export the > > fence (either as sync_file, which I think amdgpu doesn't support because > > no android egl support in mesa) or drm_syncobj (which you can do as > > standalone fd too iirc), and then just using the fence a bit from > > userspace (like wait on it or get its status) after the device is > > unplugged. -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
