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
