On 12 April 2017 at 12:49, Mao, David <David.Mao@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
