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

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

In D23514#521002, @alexeymin wrote:

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

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

In D23514#521023, @romangg wrote:

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

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.

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.

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

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?

What solution do you propose?

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

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.

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.

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.

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.

In D23514#553048, @romangg wrote:

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.