https://bugs.kde.org/show_bug.cgi?id=520084
--- Comment #12 from [email protected] --- I just found something that invalidated most of my testing because I did not control for it. $ kscreen-doctor output.HDMI-A-1.vrrpolicy.always Makes it so that on an idle kwin, even without actual VRR being engaged on the display, the first damaged surface triggers an immediate compositor render. Hence latency readings going down as low as 8.7ms. With vrrpolicy.never, it actually uses PresentationMode::VSync (or Async, since I have tearing allowed), and the latency floor is somewhere around 14ms. This is not a KWin bug though, it's Nvidia reporting vrr_capable to drm: $ drm_info | rg -i -C4 'HDMI-A|vrr|VRR' │ └───Height: [0, 65535] ├───Connectors │ ├───Connector 0 │ │ ├───Object ID: 128 │ │ ├───Type: HDMI-A │ │ ├───Status: connected │ │ ├───Physical size: 1600×900 mm │ │ ├───Subpixel: unknown │ │ ├───Encoders: {0} -- │ │ ├───"TILE" (immutable): blob = 0 │ │ ├───"CRTC_ID" (atomic): object CRTC = 62 │ │ ├───"Colorspace": enum {Default, BT2020_RGB, BT2020_YCC} = Default │ │ ├───"HDR_OUTPUT_METADATA": blob = 0 │ │ └───"vrr_capable" (immutable): range [0, 1] = 1 But I have VRR disabled in the OSD, and its debug overlays also confirm I am using fixed refresh rates as expected. Enabling VRR on the display makes it change EDID on the fly, I think. Maybe the driver remembers the display used to advertise it before, or whatever. Either way, with vrrpolicy.never, there is still a penalty to running glxgears in the background. I'll need to redo my measurements later, but it seems like that is down to predicted render time, so it can probably be mitigated by raising min GPU clocks or with other tricks. To be confirmed... Basically, I was testing a configuration that should not be possible. -- You are receiving this mail because: You are watching all bug changes.
