Hi Dmitry, > Subject: Re: [PATCH] drm/virtgpu: Use vblank timer > > On 10/9/25 06:23, Kasireddy, Vivek wrote: > > Hi Thomas, > > > >> Subject: [PATCH] drm/virtgpu: Use vblank timer > >> > >> Use a vblank timer to simulate the vblank interrupt. The DRM vblank > >> helpers provide an implementation on top of Linux' hrtimer. Virtgpu > >> enables and disables the timer as part of the CRTC. The atomic_flush > >> callback sets up the event. Like vblank interrupts, the vblank timer > >> fires at the rate of the display refresh. > >> > >> Most userspace limits its page flip rate according to the DRM vblank > >> event. Virtgpu's virtual hardware does not provide vblank interrupts, so > >> DRM sends each event ASAP. With the fast access times of virtual display > >> memory, the event rate is much higher than the display mode's refresh > >> rate; creating the next page flip almost immediately. This leads to > >> excessive CPU overhead from even small display updates, such as moving > >> the mouse pointer. > >> > >> This problem affects virtgpu and all other virtual displays. See [1] for > >> a discussion in the context of hypervdrm. > > When running Virtio-gpu with some of the UIs (gtk, spice, etc) in Qemu, > the > > Guest display updates are synchronized with a timer (or repaint callback > in > > the case of Gtk) the UI layer provides particularly when blob=true. In other > > words, the Guest's atomic commit does not complete until the Host > signals > > (via a fence) that the update (or flush) is done. > > > > This is because when blob=true, the Guest's FB is accessed by the Host > without > > making any copies. So, to avoid tearing, the Guest needs to be prevented > from > > accessing its FB until the Host is done. Therefore, I think for virtio-gpu, > > the > virtual > > vblank timer can only be helpful when blob=false as this is the only case > where > > Guest's display updates are unbounded (and Host makes a copy of the > Guest's FB). > > > > I am not sure how this would affect virgl use-cases but Dmitry can help > explain if > > the vblank timer would be useful there or not. > > The vblank timer should only limit framerate of virtio-gpu, I don't > expect it will cause new problems. Do you see tearing using this patch? AFAICS, having a vblank timer when blob=true would be redundant and will interfere with the synchronization mechanism because the Guest compositor would start a new repaint cycle without knowing if it OK to reuse the FB it had submitted previously. I have not yet tested this patch but I strongly believe it will cause tearing issues particularly when blob=true.
> > Vblank timer makes a big performance improvement for virtio-gpu KMS, > especially for a native context on QEMU. No tearing spotted with it. This means that the only remaining case to be tested is blob=true and virgl=false. I'll try to test it soon and let you know. Thanks, Vivek > > -- > Best regards, > Dmitry
