[platforms/x11] Never block on retrace, always present after paint
ClosedPublic

Authored by romangg on Aug 27 2019, 9:41 PM.

Details

Summary

Compositing in X11 was done time shifted, meaning that we paint first, then
wait one vblank interval length and present on prepareRenderingFrame the
previous paint result. This is supposed to make sure we don't miss the vblank
and in case of block till retrace be able to continue issuing commands and
only shortly before next vblank present.

This is counter-intuitiv, not how we do it on Wayland or even on MESA with X.
The reason seems to be that the GLX backend was in the beginning written
against Nvidia proprietary driver which needed this but nowadays even this
driver defaults to non-blocking behavior on buffer swap.

Therefore remove this legacy anomaly fully and directly present after paint.
We then wait one refresh cycle and in the future can optimize this by delaying
the paint and present till shortly before vsync.

Test Plan

kwin_x11 tested on i915 and Nvidia proprietary driver.

Diff Detail

Repository
R108 KWin
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
romangg created this revision.Aug 27 2019, 9:41 PM
Restricted Application added a project: KWin. · View Herald TranscriptAug 27 2019, 9:41 PM
Restricted Application added a subscriber: kwin. · View Herald Transcript
romangg requested review of this revision.Aug 27 2019, 9:41 PM
romangg updated this revision to Diff 64781.Aug 27 2019, 9:59 PM

Cache refresh rate on Wayland. Otherwise it is calculated again on every present.

I tested now also on Nvidia proprietary driver and there were no issues.

romangg edited the test plan for this revision. (Show Details)Aug 28 2019, 11:02 AM

As usual, do you need help testing this on amdgpu? 😜

As usual, do you need help testing this on amdgpu? 😜

Sure. :) Can you check X and Wayland sessions?

alexeymin added a comment.EditedAug 28 2019, 7:18 PM

Sure. :) Can you check X and Wayland sessions?

I've tested both. Works fine, wayland one seem to work even smoother that x11. On X I feel some kind of slight fps drop when dragging window, hard to tell for sure. Wayland seems perfect (I only miss working keyboard repeat/delay setting and middle-click paste)

P.S. tested X again, no, all fine, maybe I'm just seeing things

P.P.S. X11 I am using all the time, I did make && sudo make install into my main system and living with that. Into Wayland I only reboot eventually for a smaller periods of time, to test something

zzag added a subscriber: zzag.Sep 5 2019, 8:56 AM

Given that the feature freeze is closer and closer, are you okay if your changes go to 5.18? That way we'll have more time to test these patches.

workspace.cpp
1611–1612

No, we don't need to print this line anymore because it will always say "removed."

In D23514#525852, @zzag wrote:

Given that the feature freeze is closer and closer, are you okay if your changes go to 5.18? That way we'll have more time to test these patches.

Sorry if I wasn't clear on that, my plan was anyway to merge it only after 5.17 release to have enough time testing them on master since the changes are fundamental to the compositing pipeline and in some way a bit experimental.

workspace.cpp
1611–1612

I thought I leave it in so it's clear that the feature got "removed". But maybe it's better to just not print the line.

romangg updated this revision to Diff 66536.Sep 20 2019, 10:51 AM
romangg marked 2 inline comments as done.
  • Remove vertical retrace mention in supportInformation
  • Rebase on master and series changes
zzag added a comment.Sep 20 2019, 4:48 PM
This comment was removed by zzag.
romangg updated this revision to Diff 68579.Oct 22 2019, 11:09 PM

Rebase on master.

romangg updated this revision to Diff 68582.Oct 23 2019, 12:37 AM

Rebase on series changes.

Any remaining issues? Otherwise I will push this series later today after I tested myself again and some positive feedback D23105#546113.

zzag added a comment.Oct 23 2019, 8:41 AM

My concerns about performance regression introduced by this patch haven't been addressed. The time span during which kwin records rendering commands slides gradually over time, it's not aligned to vblank.

In D23514#552564, @zzag wrote:

My concerns about performance regression introduced by this patch haven't been addressed. The time span during which kwin records rendering commands slides gradually over time, it's not aligned to vblank.

Did you raise these concerns here? I don't see them. What solution do you propose?

zzag added a comment.Oct 23 2019, 9:31 AM

What solution do you propose?

Synchronize rendering to vertical retraces. We don't have a lot of choices.

zzag added a comment.Oct 23 2019, 9:32 AM

This patch can't go in as is because of the performance issues.

I suggest to land this patch together with OML_sync_control patch(es).

In D23514#552583, @zzag wrote:

This patch can't go in as is because of the performance issues.

I suggest to land this patch together with OML_sync_control patch(es).

What performance issues? Me and other people tested this on multiple machines without noticing problems. You have a way to trigger the performance problems? Certain apps, effects?

Not syncing to vblank is not per se a performance issue as in lower framerate. It just means the latency is not optimized. On current master we do this with maximal possible latency of one frame all the time btw.

zzag added a comment.EditedOct 23 2019, 1:04 PM

I'm talking about this. The fps is around 40 to 50 even though I have only one client open (Konsole).

You have a way to trigger the performance problems?

Uh, just run kwin with this patch and enable show fps effect.

EDIT: Just to clarify, show fps effect doesn't cause the performance problems, it's just for debugging.

zzag added a comment.Oct 23 2019, 1:20 PM

Not syncing to vblank is not per se a performance issue as in lower framerate. It just means the latency is not optimized.

Without syncing to vblank our timings will be off. It's possible that we may start compositing right before the upcoming vblank and thus miss it.

zzag added inline comments.Oct 23 2019, 1:47 PM
composite.cpp
786–809

I think we still need some of this code. Syncing to vblank will be a problem though.

In D23514#552703, @zzag wrote:

I'm talking about this. The fps is around 40 to 50 even though I have only one client open (Konsole).

You have a way to trigger the performance problems?

Uh, just run kwin with this patch and enable show fps effect.

EDIT: Just to clarify, show fps effect doesn't cause the performance problems, it's just for debugging.

You know that the show fps effect is not a benchmark, right? I mean it says so just below it.

zzag added a comment.Oct 24 2019, 8:21 AM

You know that the show fps effect is not a benchmark, right? I mean it says so just below it.

I know that, however it should not display such low numbers when there is only one static [1] client open.

This patch intends to move present() from prepareRenderingFrame() to endRenderingFrame(), but it also introduces a few undesired side-effects, which should be addressed either here or in the follow-up patches. The frame rate drop is a pretty serious issue. Waiting the whole vblank interval will cause the time span during which kwin records rendering commands to drift, which may introduce undesired stuttering. The other problem is that rendering is no longer synchronized to vblank, it basically means that our timings are off.

[1] Meaning it's not frequently updated

In D23514#553134, @zzag wrote:

[...] in the follow-up patches [...]

That was the idea anyways. The patch series here is only for simplification to a point that the system is still working but with a minimum of code complexity, optimization comes afterwards. See my testbed D23105, which listens for swap events on Mesa and aligns compositing with that and Fredrik's patch D23881, which does the same with a little trick for Nvidia.

This revision was not accepted when it landed; it landed in state Needs Review.Thu, Nov 14, 8:03 AM
This revision was automatically updated to reflect the committed changes.