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

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

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

    KDE Plasma users will hopefully be seeing the KWin Wayland compositor perform better and more reliably in 2021...

    http://www.phoronix.com/scan.php?pag...ter-Experience

  • #2
    Finally. Years with the timer problem...

    Comment


    • #3
      Having read that post, it's still not clear whether compositing is heavy enough to warrant multi-threading.
      The rest of the issues seem pretty common sense. I don't see what's the fuss, maybe the code (or OpenGL or Vulkan) is messed up enough to make those use cases not easy to follow.

      On the bright side, we don't have to wait for KDE6 to get these additional goodies.

      Comment


      • #4
        For now I would be happy to see lag-free and smooth desktop experience for one monitor, I lost hope in multi monitor support long time ago because of crashed and desktop settings reset every reboot.

        Comment


        • #5
          Originally posted by sp82 View Post
          For now I would be happy to see lag-free and smooth desktop experience for one monitor, I lost hope in multi monitor support long time ago because of crashed and desktop settings reset every reboot.
          Didn't feel laggy for me in years (if ever). But I guess this is one of those things that can be highly config dependent.
          I've been running two monitors for years with nary a problem as well.

          I would suggest removing/renaming the config folders and trying to start clean. Also, check whether you have other locally modified config files. If you do, newer packages won't overwrite them.
          Last edited by bug77; 12 December 2020, 07:00 PM.

          Comment


          • #6
            Originally posted by bug77 View Post
            Having read that post, it's still not clear whether compositing is heavy enough to warrant multi-threading.
            Probably isn't, but if it helps keep clock speeds low then I see that as a good thing.
            Also, this likely helps with software rasterizing.

            Comment


            • #7
              Originally posted by schmidtbag View Post
              Probably isn't, but if it helps keep clock speeds low then I see that as a good thing.
              I doubt it helps any. Light load+multi threading=significant overhead (usually)

              Originally posted by schmidtbag View Post
              Also, this likely helps with software rasterizing.
              I don't think software rasterizing+compositing is something that should be encouraged :P
              Last edited by bug77; 11 December 2020, 12:10 PM.

              Comment


              • #8
                What I don't get is why stuff needs to be throttled to the lowest common thing ?
                Let's say we have 2 monitors:
                1. 4K 10bit 120 Hz
                2. 2K 8bit 60 Hz
                Why not render everything for the best monitor in 10bit 120 Hz and then downgrade from there the bit depth and refresh rate for the other one ?
                It's hard to understand why the best monitor has to suffer because the other one doesn't have the same capabilities when stuff could've been downgraded for the one(s) that can't display that.

                Comment


                • #9
                  Originally posted by bug77 View Post
                  Having read that post, it's still not clear whether compositing is heavy enough to warrant multi-threading.
                  The rest of the issues seem pretty common sense. I don't see what's the fuss, maybe the code (or OpenGL or Vulkan) is messed up enough to make those use cases not easy to follow.
                  The author explained that the problem is Kwin is making "legacy" assumptions that aren't valid anymore with modern OpenGL drivers. The other half of the problems is of course X11 limitations that have been inherited to the Wayland implementation as well. Multithreading would be used to run separate compositors for each display. I guess there is no reliable and "easy" way to handle use cases where one display runs at 60 Hz and the second at 75 or even 144 Hz, as there are going to be frames for which timings overlap and also the window between two frame would vary based on the aforementioned overlapping of timings.
                  Last edited by curfew; 11 December 2020, 11:22 AM.

                  Comment


                  • #10
                    Originally posted by bug77 View Post
                    Having read that post, it's still not clear whether compositing is heavy enough to warrant multi-threading.
                    The rest of the issues seem pretty common sense. I don't see what's the fuss, maybe the code (or OpenGL or Vulkan) is messed up enough to make those use cases not easy to follow.

                    On the bright side, we don't have to wait for KDE6 to get these additional goodies.
                    There are times when going multi-threading actually simplifies things and I suspect this is one case of it.

                    Comment

                    Working...
                    X