Announcement

Collapse
No announcement yet.

Triple Buffering Likely Not Landing Until GNOME 42

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

  • #11
    Staying with XFCE since 2012 was a good choice for me. Every time I gave Gnome or Kde a shot I couldn't justify the switch because of ridiculous high usage of system resources. And now they want to use triple buffering so the GPU can keep up with rendering a 2D desktop while most low-to-mid-range games do well with double buffering? This is going in a horribly wrong direction I'm afraid!

    Comment


    • #12
      Originally posted by smartalgorithm View Post
      GNOME news are like next gen AAA title games... so what kind of GPU i need to run it at 30+ fps?
      Always interesting to read the insights here... or rather lack of insights. The issue is that the GPU frequency might have been scaled down, causing the frames to run late. This whole MR is about ensuring the GPU is fully utilized and tricking the GPU to scale up the frequency to ensure the frames arrive on time. So, this has nothing to do with GNOME require and insane amount of resources. You can be lightweight, but if the GPU just scales down you will still stutter. So, this MR is actually to ensure GNOME should run smoothly on older hardware, by using the GPU efficiently.

      Comment


      • #13
        I think next to the GNOME 40 is GNOME 41.

        Comment


        • #14
          Originally posted by smartalgorithm View Post
          GNOME news are like next gen AAA title games... so what kind of GPU i need to run it at 30+ fps?
          A Mali 400 MP2 is enough, this is rather a workaround for a bugged Intel GPU energy management.

          Comment


          • #15
            Originally posted by GruenSein View Post
            I find this solution pretty hackish. Apparently, the GPU is effortlessly capable of rendering the desktop with the required frame timings. However, artificially increasing the workload so that the GPU realizes that it has to power up seems more like avoiding the real problem than a decent fix. I mean, why doesn't the GPU realize that it is lagging behind? It appears to me that the performance profiles aren't quite right.
            The problem is that the GPU doesn't have deadline, doesn't know when it is behind. And more importantly if you figure out you are behind its alot harder to catch up. Ramping up/down is not that easy either and might result in the GPU not doing any work for awhile.
            Its far from an easy task to predict your necessary (minimum speed), I am sure Gnome/GTK lacking a scenegraph (and thus a good view of all pending work) doesn't help.

            Comment


            • #16
              Originally posted by nkalkhof View Post
              Staying with XFCE since 2012 was a good choice for me. Every time I gave Gnome or Kde a shot I couldn't justify the switch because of ridiculous high usage of system resources. And now they want to use triple buffering so the GPU can keep up with rendering a 2D desktop while most low-to-mid-range games do well with double buffering? This is going in a horribly wrong direction I'm afraid!
              You completely miss understood the purpose of that MR. In fact no buffering is needed to run this 3D(yes, its a 3D desktop) desktop. The issue is that gnome uses so little GPU power on Intel iGPUs that it goes into a lower clock mode, causing stuttering and frames that lack behind the timing. Its ugly, but by no means even near the ugliness of some of the workarounds for the Nvidia driver.

              Comment


              • #17
                Originally posted by 144Hz View Post
                Triple buffering to circumvent driver problems? No thanks. Upstream wouldn’t take it anyway.
                They may do, at least for now. The work needed to make that MR are all nice benefits to gnome. And if you think about how many hacks and workaround are in the code base to support the horrible nvidia driver, then that one won't bring much issue.

                Comment


                • #18
                  Or make compositing as efficient as Sway's to avoid creating performance issues in the first line?

                  Comment


                  • #19
                    Uh, triple buffering is neither a hack nor working around driver issues or anything like it in this case. It's simply required to reliably keep the GPU busy enough for best throughput. Do you think it's a coincidence that macOS and Android's SurfaceFlinger compositor use selective triple buffering? Nope.

                    Comment


                    • #20
                      Originally posted by Alexmitter View Post

                      They may do, at least for now. The work needed to make that MR are all nice benefits to gnome. And if you think about how many hacks and workaround are in the code base to support the horrible nvidia driver, then that one won't bring much issue.
                      Isn't this also one of those quirks that's usually built-in to the Windows driver or Windows software to work around stuff just like this? I swear I've read something like that before.

                      Comment

                      Working...
                      X