On Thu, May 28, 2026 at 9:54 AM Thomas Zimmermann <[email protected]> wrote: > > Hi > > Am 27.05.26 um 18:31 schrieb Julian Orth: > > On Wed, May 27, 2026 at 3:39 PM Thomas Zimmermann <[email protected]> > > wrote: > >> DRM's WAIT_VBLANK ioctl synchronizes user-space clients to display > >> refresh. This is meaningless with vblank timers, which run unrelated > >> to the hardware's vblank. > >> > >> Disable the ioctl for simulated vblanks. Set DRM_VBLANK_FLAG_SIMULATED > >> for CRTCs with simulated vblank events in all such drivers. The vblank > >> timers of these devices still rate-limit the number of page-flip events > >> to match the display refresh. > >> > >> According to maintainers, user-space compositors do not require the ioctl > >> for rate-limitting display output. Weston, Kwin and Mutter rely on > >> completion > >> events. Mutter optionally uses the WAIT_VBLANK ioctl only to optimize the > >> time from input to output. > >> > >> When testing with mutter and weston, the page-flip rate appears correct > >> with the patch set applied. > > To avoid this being a regression, you need to test that this change > > does not regress input latency. > > Let me stress that the current situation is that there's high-quality, > and low-quality and no timing information. Depends on the driver and > hardware. > > > > > As discussed on IRC, compositors use vblank data to predict the time > > of the next flip event. For each device that you are touching here, > > there are two possibilities: > > > > - The vblank data is related to the flip timing, i.e. flip events and > > vblank events are sent at almost the same time. In this case removing > > these apis removes the path for compositors to predict the time of the > > next flip event. Input latency will therefore regress after idle > > periods when the compositor no longer has the time of the last vblank. > > User-space compositors seem to operate under this assumption. That, I > think, makes sense on better hardware with rendering and vblank IRQs. > Page flips are fast on such systems. > > > > > - The vblank data has nothing to do with the time of the next flip > > event. In this case this series could in fact improve latency because > > it removes the incorrect data from the compositor. > > Most of the hardware that would use vblank timers falls in this > category. Page flips often consist of memcpys into video memory, or they > transfer pixel data over slow peripheral busses. The amount of work per > page flip varies with the size of the damage rectangles. > > Any vblank timing information here is therefore of low quality. For some > scenarios, it would be common to miss a vblank or even the one after it.
What matters is if the flip event will be aligned to _some_ vblank event. As long as that is the case, the compositor can estimate which vblank it will hit based on previous frames and can schedule its work accordingly. I believe KWin and Mutter already support scheduling frames for multiple vblanks in the future to support low-powered devices or devices that are under high load. I have not looked into this myself. But even on high-powered devices compositors already take per-commit kernel work into account. For example, by default I aim to commit 1.5 ms before vblank. This grace period is adjusted dynamically if I miss the expected vblank. Therefore I don't think this is an argument against exposing vblank info. Even if the hardware had such an interrupt, the memcpy and slow-bus issues would continue to apply. > > > IMHO, the first thing to discuss is whether having possibly low-quality > timing information is preferable to having either high-quality timing or > none. I have no strong opinion, but would tend to the latter. If you want to make userspace aware that vblank events are not backed by hardware interrupts, then maybe this could be exposed as a driver cap or a flag in the vblank event. Userspace could then decide on their own what to do with that information. Currently I don't think any compositor would use that information since they target flip times and don't care if those times are driven by hardware or software (since this is not actionable by userspace anyway). So maybe the useful flag would be "flip times will not be aligned to any vblank event" if that applies to any driver. > > Best regards > Thomas > > > > > > Whether the times of the flip events correspond to hardware timings is > > not relevant. Everything in wayland compositors is scheduled against > > flip event timings and they are also forwarded to clients for their > > frame scheduling. If the flip timings are wrong/out of sync with the > > hardware, then removing the vblank apis does not improve this > > situation. > > > >> This change has been discussed at length on IRC recently. > >> > >> https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2026-05-08&show_html=true > >> https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2026-05-12&show_html=true > >> https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2026-05-13&show_html=true > >> https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&highlight_names=&date=2026-05-15&show_html=true > >> > >> v2: > >> - add filter to CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls (Michel) > >> - clarify Mutter's behavior in cover letter (Michel) > >> > >> Thomas Zimmermann (9): > >> drm/vblank: Add drmm_vblank_init() to indicate managed cleanup > >> drm/vblank: Add DRM_VBLANK_FLAG_SIMULATED > >> drm/amdgpu: vkms: Set DRM_VBLANK_FLAG_SIMULATED > >> drm/bochs: Set DRM_VBLANK_FLAG_SIMULATED > >> drm/cirrus: Set DRM_VBLANK_FLAG_SIMULATED > >> drm/hypervdrm: Set DRM_VBLANK_FLAG_SIMULATED > >> drm/qxl: Set DRM_VBLANK_FLAG_SIMULATED > >> drm/virtgpu: Set DRM_VBLANK_FLAG_SIMULATED > >> drm/vkms: Set DRM_VBLANK_FLAG_SIMULATED > >> > >> drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 3 ++- > >> drivers/gpu/drm/drm_vblank.c | 26 +++++++++++++++------ > >> drivers/gpu/drm/drm_vblank_helper.c | 2 +- > >> drivers/gpu/drm/hyperv/hyperv_drm_modeset.c | 2 +- > >> drivers/gpu/drm/qxl/qxl_display.c | 2 +- > >> drivers/gpu/drm/tiny/bochs.c | 2 +- > >> drivers/gpu/drm/tiny/cirrus-qemu.c | 2 +- > >> drivers/gpu/drm/virtio/virtgpu_display.c | 2 +- > >> drivers/gpu/drm/vkms/vkms_drv.c | 4 ++-- > >> include/drm/drm_crtc.h | 2 +- > >> include/drm/drm_device.h | 2 +- > >> include/drm/drm_vblank.h | 15 +++++++++++- > >> 12 files changed, 45 insertions(+), 19 deletions(-) > >> > >> > >> base-commit: 5fb5a9a63cf5ece68e0eeb6fa397da27712bccf0 > >> -- > >> 2.54.0 > >> > > -- > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com > GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg) > >
