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

[Christian König]

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