Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • bug77
    replied
    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.
    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.

    Leave a comment:


  • oiaohm
    replied
    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.
    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
    Code:
    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..

    Code:
    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.

    Leave a comment:


  • mgraesslin
    replied
    Originally posted by bug77 View Post
    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.

    Leave a comment:


  • xeekei
    replied
    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.

    Leave a comment:


  • duby229
    replied
    Originally posted by Aryma View Post
    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...

    Leave a comment:


  • Aryma
    replied
    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

    Leave a comment:


  • tildearrow
    replied
    Originally posted by Baguy View Post

    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.

    Leave a comment:


  • duby229
    replied
    Originally posted by Grawp View Post

    I was also having various screen tearing (even a diagonal tear!) and buggy multimonitor setup on NVidia laptop (Thinkpad T510).
    Then I went for desktop machine with Xeon with an integrated GPU and it completely solved multimonitor problems in KDE/Plazma tough there still was some screen tearing albeit a different one from Nvidia.
    Then I updated my desktop machine with RX580 card and I've had absolutely no problems with multimonitor setup or screen tearing WHATSOEVER in KDE/Plazma and it's been that way for 3 years through various plazma, kde-libs, kde-apps releases.
    That specific GPU has been utterly magical problem solver.

    Note: I've always been on latest LTS kernel.
    Nvidia's driver is only capable of tearfree on the 1st monitor, any additional monitors will tear. It's not really a bug so much as a limitation of their Twinview implementation, which has other problems as well...

    And yeah, same here, I been totally tearfree since like 2010 or so when the AMD open source drivers overhauled their tearfree options for X11. (Their OSS drivers weren't always the most performant drivers, but since then have definitely been the least buggy and the best looking provided you waited to purchase a new card until after its support was good.)
    Last edited by duby229; 11 December 2020, 05:54 PM.

    Leave a comment:


  • Baguy
    replied
    Originally posted by programmerjake View Post
    Assuming they fix the multi-monitor issues with heterogeneous refresh rates, I might be convinced to switch to KDE since I have 1 144Hz monitor and 2 60Hz monitors. 144Hz is awesome for games when it works!
    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.

    Leave a comment:


  • programmerjake
    replied
    Assuming they fix the multi-monitor issues with heterogeneous refresh rates, I might be convinced to switch to KDE since I have 1 144Hz monitor and 2 60Hz monitors. 144Hz is awesome for games when it works!

    Leave a comment:

Working...
X