Am 12.04.2017 um 05:58 schrieb Dave Airlie:
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?
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
