Am 12.04.2017 um 05:58 schrieb Dave Airlie: > On 12 April 2017 at 13:34, Mao, David <David.Mao at amd.com> 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? Not even remotely. Since X and the application are separate processes they can't access each others schedule contexts. > 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. Sorry, I'm not following the whole discussion. Why do we want a dummy submission in the first place? Just to have the semaphore in the signaled state? > 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. Yes, agree. We should fix this on the user space level, not add any kernel workarounds. Regards, Christian. > > Dave. > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
