Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)

[Dave Airlie <airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On 12 April 2017 at 13:34, Mao, David <David.Mao@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?

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.
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx