=> we'd really want to pass a semaphore between the X server and client to do this perfectly. Do you means that you want X to signal the semaphore that waited by client, through special version of xsync? We use pretty complex tricks to build synchronization logic upon the event and shm fence. But it would be better if we could use unified way to signal/wait the xsync fence and the semaphore object. I can see the benefit for combining the semaphores' wait/signal into the submit routine, but how about extend the interface to allow null ib submission? In this case, it will always return the last seq_no for null ib list, and the semaphore in signal list will be associated with last fence as well. IIRC, the semaphore wait is applied to schedule entity as the dependency, which means it don't need to be associated with schedule job as well. Thanks. Best Regards, David -----Original Message----- From: Dave Airlie [mailto:airlied@xxxxxxxxx] Sent: Wednesday, April 12, 2017 11:58 AM To: Mao, David <David.Mao@xxxxxxx> Cc: amd-gfx@xxxxxxxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1) On 12 April 2017 at 13:34, Mao, David <David.Mao@xxxxxxx> wrote: > My point is it is reasonable to split the semaphore signal/wait with the command submission. > For the signal ioctl, we could just pick the last fence in the same schedule context, and we don't need to ask for a explicit flush or a dummy submission trick. > The spec guarantee the signal always comes before the wait, which means, we could always get the valid fence. For the kernel sem object. I'm a bit vague on the schedule contexts stuff, but does anything guarantee the X server present operation be in the same schedule context? This might be something for Christian to chime in on, we could I suppose add ioctls to avoid the dummy CS submission, we could also make dummy CS submission simpler, if we submit no IBs then we could just have it deal with the semaphores for those cases and avoid any explicit flushes, which saves reproducing the logic to wait and sync. But at least for the wait case, we need to send something to the scheduler to wait on, and that looks like the CS ioctl we have now pretty much, For the signal case there might be a better argument that an explicit signal with last fence on this ctx could be used, however at least with the way radv works now, we definitely know the X server is finished with the present buffer as it tells us via its own sync logic, at that point radv submits an empty CS with the signal semaphores, we'd really want to pass a semaphore between the X server and client to do this perfectly. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
