Announcement

Collapse
No announcement yet.

GNOME Is Also Getting Fixed Up For Lower CPU Usage With NVIDIA Graphics

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

  • #11
    Isn't it wonderful that Nvidia were able to look at the source code for KDE/Kwin, figure out what was wrong, submit a patch and get it fixed?

    Comment


    • #12
      As much as I hate nvidia as the next OSS supporter I have to say Gnome devs are pretty arrogant when it comes to nvidia users.

      I've reported a nvidia specific bug (which I included as being so in the report since I have an AMD desktop as well) which prevented the GDM "stupid-windows-clone-go-up-curtain-crap" from going up when clicking or pressing a button. There's a twitchy reaction only on nvidia setups where it blinks over to the "whats-behind-the-stupid-curtain" and possibly even types whatever you pressed in a password field but then it blinks back and you're at square one.

      This effectively prevents you from removing the useless piece of curtain-crap unless you actually do a "drag" with your mouse (good luck mouseless setups I guess?).

      They weren't even able to ack the issue because guess what, "no nvidia here buddy".

      It's ridiculous. If gnome was a 1-5 person thing I'd accept that but this way it's just retard land.
      Last edited by Almindor; 04-01-2019, 11:58 AM. Reason: typo

      Comment


      • #13
        Originally posted by kaprikawn View Post
        Isn't it wonderful that Nvidia were able to look at the source code for KDE/Kwin, figure out what was wrong, submit a patch and get it fixed?
        Yes, just imagine KDE/Gnome being proprietary binary blobs and NVidia trying to get their hardware working on it, with DEs having various own assumptions regarding driver behaviour.

        Comment


        • #14
          Originally posted by pracedru View Post
          In fact this performance problem is not due to Nvidia drivers, it is due to a wrong implementation in KDE and GTK.
          Still leaves zillions of others due to the Nvidia driver.

          Comment


          • #15
            Originally posted by reavertm View Post

            Yes, just imagine KDE/Gnome being proprietary binary blobs and NVidia trying to get their hardware working on it, with DEs having various own assumptions regarding driver behaviour.
            That's why you have standards.

            Comment


            • #16
              Typo:

              Originally posted by phoronix View Post
              the mouse cursor could be stuck at 60Hz while the the display's refresh rate is greater than 60Hz.

              Comment


              • #17
                Originally posted by pracedru View Post
                All though i would much rather have open source drivers for my Nvidia GFX card, I must say that their drivers works very well. In fact this performance problem is not due to Nvidia drivers, it is due to a wrong implementation in KDE and GTK.
                Not sure this is a very accurate statement. What is correct is that this is only occurs on the NVidia driver due to needing a separate implementation of a lot of stuff, so yes the problem turned out could be dealt with in KDE and GNOME, but it is hard for KDE and GNOME devs to do so as we don't know what exactly is happening inside the NVidia binary driver. On the open source driver side we can look into the driver code and figure out what is expected, on the NVidia binary driver side debugging is a lot harder and sometimes require input from NVidia to figure out.

                Comment


                • #18
                  I'd really like to see this backported for Gnome 3.32.

                  Comment


                  • #19
                    Originally posted by jrch2k8 View Post

                    Is actually backwards but pretty much that is it
                    Are you sure? This is how Mesa behaves to VSync: (compared to proprietary)

                    ​​​​​​

                    Comment


                    • #20
                      Originally posted by ChristianSchaller View Post

                      Not sure this is a very accurate statement. What is correct is that this is only occurs on the NVidia driver due to needing a separate implementation of a lot of stuff, so yes the problem turned out could be dealt with in KDE and GNOME, but it is hard for KDE and GNOME devs to do so as we don't know what exactly is happening inside the NVidia binary driver. On the open source driver side we can look into the driver code and figure out what is expected, on the NVidia binary driver side debugging is a lot harder and sometimes require input from NVidia to figure out.
                      The drivers from NVidia is implented according to spec.
                      KDE and GTK are relying on undocumented features of the Mesa drivers.
                      The error is not in the Nvidia drivers, but in the GTK and KDE implementation. This is the reason that the solution is a patch in KDE and GTK.

                      Comment

                      Working...
                      X