On 10/10/25 07:07, Kasireddy, Vivek wrote: > 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, likely won't be a problem to disable the timer based on a use-case with additional driver params if it will cause problems. Please post your testing results here. -- Best regards, Dmitry
