On Thu, May 2, 2019 at 6:19 PM Adam Jackson <ajax(a)redhat.com> wrote:
On Thu, 2019-05-02 at 17:05 +0200, Kamil Paral wrote:
> 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.
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.