https://bugs.kde.org/show_bug.cgi?id=520084
--- Comment #7 from [email protected] --- (In reply to Zamundaaa from comment #6) > > I've now done a round of tests with `KWIN_DRM_OVERRIDE_SAFETY_MARGIN=200` > 200us isn't enough to (reliably) prevent frame drops, any tests with that > are bound to have problems. Absolutely, I was just testing it to see if it had an impact at all, as a tunable. It did, but only in the typical case of an idle desktop. And even then, it had a longer tail - consistent with what you're saying > axis: kwin_drm_override_safety_margin > [browser=chromium, display_hz=120, machine=desktop, platform=linux] > 200 n= 500 median= 13.410 ms IQR= 4.301 ms > Q1-Q3=11.122..15.423 ms min-max=8.759..29.767 ms > (none) n= 500 median= 18.578 ms IQR= 4.334 ms > Q1-Q3=16.527..20.861 ms min-max=13.548..26.266 ms > [browser=chromium, display_hz=120, machine=desktop, platform=linux, > zed_editor_open=yes] > 200 n= 500 median= 20.439 ms IQR= 4.583 ms > Q1-Q3=18.152..22.735 ms min-max=15.041..28.714 ms > (none) n=1300 median= 22.121 ms IQR= 4.320 ms > Q1-Q3=20.116..24.436 ms min-max=14.775..31.073 ms I did more tests, and found some interesting facts: It's the same on amdgpu - I tested with a GCN 5 GPU, 1080p@120. It does not support HDMI 2.1, so I had to drop resolution. Near-identical NixOS setup otherwise and the same KWin, kernel, etc. being used. Labeled as `machine=server` below. The effect of running Zed vs not is similar on Windows 11. VRR on KWin seems to help by one frame, but Zed still impacts it. Mutter 49.4 is unaffected by Zed running or not. Both in latency and rate of atomic commits per second. But, if I use glxgears instead of Zed, it acts the same as the others. I couldn't test it with VRR though. > axis: zed_editor_open > [browser=chromium, display_hz=120, machine=desktop, platform=linux] > (none) n= 500 median= 18.578 ms IQR= 4.334 ms > Q1-Q3=16.527..20.861 ms min-max=13.548..26.266 ms > yes n=1300 median= 22.121 ms IQR= 4.320 ms > Q1-Q3=20.116..24.436 ms min-max=14.775..31.073 ms > [browser=chromium, display_hz=120, machine=desktop, platform=linux, vrr=on] > (none) n=1000 median= 8.155 ms IQR= 2.255 ms > Q1-Q3=7.781..10.036 ms min-max=6.922..20.036 ms > yes n= 300 median= 20.256 ms IQR= 4.035 ms > Q1-Q3=17.962..21.997 ms min-max=15.849..24.848 ms > [browser=chromium, display_hz=120, machine=server, platform=linux] > (none) n= 300 median= 15.648 ms IQR= 4.704 ms > Q1-Q3=13.290..17.994 ms min-max=10.341..27.781 ms > yes n= 300 median= 18.974 ms IQR= 4.123 ms > Q1-Q3=16.543..20.666 ms min-max=14.177..32.168 ms > [display_hz=120, machine=desktop, platform=windows] > (none) n= 500 median= 14.518 ms IQR= 6.541 ms > Q1-Q3=10.989..17.530 ms min-max=7.810..29.903 ms > yes n= 500 median= 19.997 ms IQR= 4.340 ms > Q1-Q3=17.996..22.336 ms min-max=15.296..31.842 ms > [browser=chromium, compositor=mutter, display_hz=120, machine=desktop, > platform=linux] > (none) n= 300 median= 13.445 ms IQR= 4.056 ms > Q1-Q3=11.745..15.801 ms min-max=8.756..19.111 ms > yes n= 300 median= 12.776 ms IQR= 3.938 ms > Q1-Q3=10.817..14.755 ms min-max=8.432..22.775 ms > [browser=chromium, compositor=mutter, display_hz=120, machine=server, > platform=linux] > (none) n= 300 median= 16.016 ms IQR= 4.397 ms > Q1-Q3=13.938..18.335 ms min-max=11.677..25.322 ms > yes n= 300 median= 17.471 ms IQR= 4.359 ms > Q1-Q3=15.362..19.721 ms min-max=12.426..23.900 ms > axis: glxgears_open > [browser=chromium, compositor=mutter, display_hz=120, machine=desktop, > platform=linux] > (none) n= 300 median= 13.445 ms IQR= 4.056 ms > Q1-Q3=11.745..15.801 ms min-max=8.756..19.111 ms > yes n= 300 median= 24.131 ms IQR= 3.941 ms > Q1-Q3=22.127..26.068 ms min-max=19.137..33.170 ms I logged some `KWIN_LOG_PERFORMANCE_DATA=1`, but I didn't find any differences in render duration or predicted render times across my static mouse vs circling mouse tests. And it makes sense to me - the same kind of compositing workload is involved either way, and it's on the critical path of the click-to-photon test. The safety margins reported were very close in both scenarios, around 0.63ms. Something about compositors being under load adds latency, but I can't find direct proof of it. If the apps themselves are cheap to run, like glxgears, and KWin uses the same safety margins in both tests to schedule ahead of vblank, where is the latency coming from? -- You are receiving this mail because: You are watching all bug changes.
