Re: vsync in VM?

[Kamil Paral]

On Thu, May 2, 2019 at 6:19 PM Adam Jackson <ajax(a)redhat.com&gt; wrote:

>  On Thu, 2019-05-02 at 17:05 +0200, Kamil Paral wrote:
>  > Hello,
>  >
>  > I wonder whether it's expected that vsync doesn't work in VMs. I've
>  > tested Fedora 28/29/30 Workstation and Fedora 30 KDE guests on Fedora
>  > 30 host, with virtio GPU (3D acceleration on and off) or QXL GPU, and
>  > in all cases, I'm seeing hundreds or thousands of FPS in glxgears,
>  > implying that vsync is not working.
>  >
>  > Is that an expected state? Is there a simple way to force vsync on
>  > inside a VM? (using virt-manager + libvirt)
>
>  Short answer: yes it's expected, no there's no way to do that, probably
>  there should be.
>
>  Long answer:
>
>  The concept of "vsync" in a virtual machine is a bit fuzzy. What
>  monitor's timings do you think you're syncing to? What do you do when
>  there's more than one host process watching the framebuffer (think both
>  gtk and vnc views on the same device)? But, assuming you manage to
>  answer those questions...
>
>  At least in qemu's implementation neither qxl nor bochs has any
>  "hardware" concept of a vertical retrace interrupt. And for both of
>  those you'll end up with llvmpipe for the 3D driver, which doesn't have
>  any concept of vsync either. The latter we could maybe fix in a few
>  ways, but I wouldn't expect the former to ever change.
>
>  virtio looks like it has _some_ internal notion of interrupts, but if
>  that's supposed to be implementing vsync it's not obvious to me how
>  it's accomplishing that. vmwgfx I suspect does have synthetic vsync
>  events, but I think you'd need to be using an actual vmware vm to make
>  that happen and not qemu.
>  
Thanks, Adam, for a detailed answer.