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.
Thanks. Best Regards, David -----Original Message----- From: Dave Airlie [mailto:airl...@gmail.com] Sent: Wednesday, April 12, 2017 11:18 AM To: Mao, David <david....@amd.com> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org Subject: Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1) On 12 April 2017 at 12:49, Mao, David <david....@amd.com> wrote: > But how to handle the semaphore wait in the vkQueuePresentkHR? The problem here is that really we'd want the presenting process to do the signal once it submits the work for actual presentations (be that the X server DDX or whatever). However that is going to be a bit tricky, for radv I've just been submitting an empty command stream submit, once the X server lets us know we've presented. I looked how the codebase before I started working on it worked, and I can't see if it dealt with this properly either, the impression I get is that it might submit the wait sems via the sem ioctl onto a ctx, but the X server might be using a different ctx, so would never execute the wait, and we'd execute the wait the next time we did a command submission. I suppose we could just queue up the vkQueuePresentKHR wait sems in userspace instead of a NULL cs if this solution was acceptable. Dave. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
