KDE Plasma's KWin Working On Per-Screen Refresh Rates, Compositing From Multiple Threads

[tildearrow]

I've been using Plasma X11 with Kwin-lowlatency to solve the latency and refresh rate issues. That said these patches are definitely welcome as using a fork of kwin that only focuses on X11 is not ideal.

KWin-lowlatency does not solve the multiple refresh rate problem, as it would require a complete rewrite.

[Aryma]

let's be honest

Linux is Sucks when it comes to graphics and Display support

and I don't think there any change in this at least for this decade

[duby229]

let's be honest

Linux is Sucks when it comes to graphics and Display support

and I don't think there any change in this at least for this decade

Oh hell a decade ago linux was waaaay further behind...

If we're talking about AMD, their OSS drivers are currently -the- best drivers that have ever existed for anything... They still aren't perfect, but they surely are better than anything that has ever existed before...

[xeekei]

It's great that KDE finally are pushing for Wayland. They've really been dragging their feet before this. People keep saying "Wayland still isn't here", while in reality Wayland is "done", but the DEs (aside from Gnome) haven't ported their compositors.

[mgraesslin]

Yes, I'm sure they're not going multi-threading just because. I was just saying the reasons are not apparent going by that post.

To give a very simple example: imagine you have two screens one running at 60 Hz and one at 120 Hz. No just for the sake of argument let's assume the rendering for one screen takes 5 ms. 5ms for screen B, 5 ms for screen A and 5 ms for screen B. Overall for one frame of screen A it's 15 ms, that still works. But for screen B it would be 5 ms and 10 ms. So every second frame of screen B would be missed. On the other hand if it's threaded and each rendering can happen on it's own cpu it would work out fine.

Even if we go down to more realistic rendering timings we still benefit by having the rendering of each screen in a thread. The delta between last frame and next vblank becomes larger which is always good. And also it allows to do input handling while rendering. Which is extremely important for high precision input devices in case of gaming, etc.

So yes this is great work and was something I hoped to find time for years ago - just other things were more important back then.

[oiaohm]

To give a very simple example: imagine you have two screens one running at 60 Hz and one at 120 Hz. No just for the sake of argument let's assume the rendering for one screen takes 5 ms. 5ms for screen B, 5 ms for screen A and 5 ms for screen B. Overall for one frame of screen A it's 15 ms, that still works. But for screen B it would be 5 ms and 10 ms. So every second frame of screen B would be missed. On the other hand if it's threaded and each rendering can happen on it's own cpu it would work out fine.

Does not work out that neat. 60Hz down convert normally does not work out to be a straight frame skip.
Number is rendered frame X is skip

60 HZ 1X34XX7
120Hz 1234567

Yes 5 frame missed the vsync of the 60hz in that code example so you now have two skipped frames in a row. Now lets say we don't prebuffer frame 4 and the same miss happens at 5..

60 HZ 1X3XXX7
120Hz 1234567

Now its 3 missed frames of 120 and truly 2 frames of no change at 60hz this may be noticed. So prebuffer is a must.

Lot think 1 frame skip when its really 0-2 frame skip of the 120Hz signal to 60hz averaging out to a constant 1 frame skip. The ability to buffer output out of alignment with vsync is key to pulling this off. Please note early GPU units all buffer swaps had to be on vsync alignment that leads to the horrible jarring second example with it being way worse between 30Hz vs 60Hz screens leading to the logic if just set both screens to lower Hz value and be done with it. Also lead to who cares with X11 if we are always a frame behind.

Now it gets worse if you are nvidia they just let the miss aligned frame tear badly.

[bug77]

To give a very simple example: imagine you have two screens one running at 60 Hz and one at 120 Hz. No just for the sake of argument let's assume the rendering for one screen takes 5 ms. 5ms for screen B, 5 ms for screen A and 5 ms for screen B. Overall for one frame of screen A it's 15 ms, that still works. But for screen B it would be 5 ms and 10 ms. So every second frame of screen B would be missed. On the other hand if it's threaded and each rendering can happen on it's own cpu it would work out fine.

Even if we go down to more realistic rendering timings we still benefit by having the rendering of each screen in a thread. The delta between last frame and next vblank becomes larger which is always good. And also it allows to do input handling while rendering. Which is extremely important for high precision input devices in case of gaming, etc.

So yes this is great work and was something I hoped to find time for years ago - just other things were more important back then.

Ah ok, so it's not about just throwing threads at the problem, but rather having one thread per screen. Now it makes sense, thanks.