Announcement

Collapse
No announcement yet.

Ubuntu Talks Up Its GNOME Dynamic Triple Buffering Support In 22.04/22.10

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

  • Ubuntu Talks Up Its GNOME Dynamic Triple Buffering Support In 22.04/22.10

    Phoronix: Ubuntu Talks Up Its GNOME Dynamic Triple Buffering Support In 22.04/22.10

    Originally carried as a patch against Ubuntu 22.04 for its GNOME 42 desktop and continued to be maintained against GNOME 43 for the upcoming Ubuntu 22.10 is supporting dynamic triple buffering with the Mutter compositor. This has allowed Ubuntu's GNOME desktop environment to perform better for some systems albeit not upstream in GNOME...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Ubuntu 22.04 has been a great release in my opinion. So much so I think I will just leave my install alone as long as possible. I don't have much free time these anyway and "if it ain't broke, don't fix it!"

    Comment


    • #3
      This & variable refresh rate. Already two nice features too look forward to in GNOME 44 (probably).

      Comment


      • #4
        I wonder why this isn't just done at the driver level. Put the logic somewhere in mesa and suddenly all desktops and GL programs benefit from it. In theory, dynamic triple buffering is good for all hardware, not just underpowered iGPUs. People with big, beefy GPUs also benefit from higher performance or lower lag compared to a static triple or double buffer, depending on whether the GPU can keep up with monitor refresh or not.

        Comment


        • #5
          Originally posted by binarybanana View Post
          I wonder why this isn't just done at the driver level.
          This is in the driver. You still need a client to request it. You also do not want to have it on all the time since it eats power and will hit the already poor linux laptops battery time.

          Comment


          • #6
            Originally posted by binarybanana View Post
            In theory, dynamic triple buffering is good for all hardware, not just underpowered iGPUs.
            I think you are misunderstanding the problem here.

            The problem is the GPU sees little work and thinks "hey, I can save power here by going into a lower power state". But it predicts that wrong so it causes stutter. dynamic triple buffering makes for work for the GPU to stop it going into as low a power state.

            That makes things smooth on the GPU where it was a problem at the risk it will cause higher resource usage atleast in that scenario and maybe others.

            AFAIK this is a bug in the intel mesa driver, but getting the right heuristic to avoid it is dificult. When it seemed like this merge request was going to be merged into gnome 42, there were a lot of angry commenters on phoronix angry at the workaround being merged.

            Comment


            • #7
              Originally posted by binarybanana View Post
              I wonder why this isn't just done at the driver level. Put the logic somewhere in mesa and suddenly all desktops and GL programs benefit from it. In theory, dynamic triple buffering is good for all hardware, not just underpowered iGPUs. People with big, beefy GPUs also benefit from higher performance or lower lag compared to a static triple or double buffer, depending on whether the GPU can keep up with monitor refresh or not.
              what this MR generally does is to increase CPU and GPU load so clocks ramp up faster. It's really an annoying frequency scheduler bug under the hood.

              Comment


              • #8
                Funny how Gnome devs often refuse Canonical's code, but they have no problem at all up-streaming the crappy code that led to a Canonical employee making a fix.

                Comment


                • #9
                  Originally posted by M@GOid View Post
                  Funny how Gnome devs often refuse Canonical's code, but they have no problem at all up-streaming the crappy code that led to a Canonical employee making a fix.
                  Recently I've seen the Canonical dev had a discussion with Gnome devs about the max display bpc issue. One Gnome dev suggested to simply run the display at lower than native resolution. Like who would actually want to run his display at lower than native resolution?
                  Of course the Canonical dev replied that he doesn't consider this as a viable workaround.
                  This just shows that some devs are really disconnected from their user's needs and I've seen it more than a few times in other open source projects.

                  Comment


                  • #10
                    Originally posted by user1 View Post
                    This just shows that some devs are really disconnected from their user's needs and I've seen it more than a few times in other open source projects.
                    Amen brother. Sometimes I wish most devs that deal with code that affect common users, to just have a spare system, preferably a older slow laptop with low res screen. Time over time you feel that some dev was running a top of the line system, when he/she upstream the code thinking "runs great in my system".

                    Comment

                    Working...
                    X