Originally posted by Baguy
View Post
Announcement
Collapse
No announcement yet.
KDE Plasma's KWin Working On Per-Screen Refresh Rates, Compositing From Multiple Threads
Collapse
X
-
Originally posted by Aryma View Postlet'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
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...
- Likes 5
Comment
-
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.
- Likes 1
Comment
-
Originally posted by bug77 View PostYes, I'm sure they're not going multi-threading just because. I was just saying the reasons are not apparent going by that post.
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.
- Likes 5
Comment
-
Originally posted by mgraesslin View PostTo 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.
Number is rendered frame X is skip
Code:60 HZ 1X34XX7 120Hz 1234567
Code:60 HZ 1X3XXX7 120Hz 1234567
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.
- Likes 1
Comment
-
Originally posted by mgraesslin View 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.
- Likes 1
Comment
Comment