https://bugs.kde.org/show_bug.cgi?id=520084
--- Comment #10 from [email protected] --- (In reply to Zamundaaa from comment #9) > Yeah, triple buffering kicking in would make sense. I instrumented scheduleRepaint() for when `item` is my chromium surface. In an experiment with glxgears running (same virtual desktop, not minimized), `d->pendingFrameCount`, `d->maxPendingFrameCount` and `effectiveMaxPendingFrameCount `are always 1, which makes sense since triple buffering is disabled by default on Nvidia. I could test with KWIN_DRM_DISABLE_TRIPLE_BUFFERING=0 to see if that would add another frame of latency with glxgears running. > Our default 1ms fixed latency in the commit thread is just to work around CPU > schedulers being bad at precise timing. I don't think that's the primary driver, my predicted render times are in the 9ms range. So if I cap `expectedCompositingTime` at 6ms, I make the window for chromium 3ms bigger, versus lowering the safety margin from 1ms to 0.2ms, which makes it only 0.8ms bigger. I'll need to retest the safety margin tweaks with my new instrumentation in place too. As to your overall point, I am not done investigating yet, but my instrumentation showed that the delays from sending input to chromium until receiving damage for its surface is stable with and without glxgears running. Between 1.4-1.9ms. KWin's render_duration (as in `render end` - `render start`) is very stable at 2.1ms too. But it only takes one composition render for the 2x variance factor to start adding significant numbers to the predicted render time. Technically, variance & predicted render time is lower when glxgears is constantly rendering every frame. But because chromium hits that pendingFrameCount branch, this predicted render time starts mattering. I think I'll try some of the following ideas next: 1. Try to lock my NV GPU at some clock or prevent it from going idle - see if I can tackle render duration consistency and confirm it lets chromium be composited late. 2. Correlate render time spikes with other activity. 3. See if it's any different on AMDGPU - wrt triple buffering and render time consistency 4. Tweak the RenderJournal so that variance decays faster? I don't fully get the algorithm but I think removing the max(0, ...) from renderTimeDiff gets me to something that decays smoothly. 5. Enable triple buffering, test if it'd add even more latency. -- You are receiving this mail because: You are watching all bug changes.
