venus: work around broken fencing on virtio-gpu
This MR fixes fencing on virtio-gpu by... handling fencing entirely in userspace!
It implements phase 1 of better fencing (except for external fence/semaphore). It also allows me to deprecate virgl/virglrenderer!501 (closed), which is a local patch that Chrome OS carries.
The first 7 commits replace sync-file-based fencing by a userspace solution: to busy poll in vkWaitForFences, vkWaitSemaphores, vkQueueWaitIdle, and vkDeviceWaitIdle. This may sound scary, but the truth is that when the guest waits on sync files, the host actually busy polls some fences out there. This change moves the busy polling logic from the host to the guest in practice. There will be a higher CPU overhead (to encode/decode vk commands) but also a lower latency (by skipping kvm and guest kernel).
The 8th commit fixes WSI fencing by calling vkQueueWaitIdle in vkQueuePresentKHR. This can kill the performance, but is what needs to be done until the kernel gets implicit fencing. On Chrome OS, the issue is worked around partially, but venus should not rely on the workaround and be broken elsewhere. Instead, we should focus on fixing the kernel driver.
The last commit enables timeline semaphore support on virtio-gpu, now that we don't rely on sync files.
vn_renderer_sync becomes unused. I did not go as far as removing it in this MR. We will see how fast we move forward into the other phases of better fencing and decide what to do with it.
This has been tested on vtest and crosvm/x11, and passes Vulkan CTS 1.2. I am going to test it on Chrome OS next (EDIT: verified this works on Chrome OS).