Announcement

Collapse
No announcement yet.

Ubuntu 20.04 GNOME X.Org vs. Wayland Session Performance Impact For Gaming

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

  • #61
    Originally posted by jacob View Post

    Simply not true. If you want to know, i *DO* have a video encoding running right now, on a relatively feeble CPU too, with no problems. I know that the problem exists but it's not inherent to Wayland, moving the mouse or windows doesn't take any more CPU than under X11 - quite to the contrary, in fact. BTW GNOME's Mutter has an undocumented feature where it runs the main UI thread with RR scheduling. It's not enabled by default (not yet at least, and certainly for good reasons) but I tried it for some time, without any observable issues... and the UI just flied, regardless of CPU load.
    Are you using Arch or one of it's derivatives? I've been told by one other guy about some hacks they made to reduce the impact of input lag. (If I remember right they did something with cgroups to increase the amount of CPU time allocated to wayland under cpu load conditions, but I never looked into it. I just vaguely remember this guy mentioning it. It's not a true fix though, it's a literal hack.)

    Anyway regardless of whether or not you personally notice it, it's most definitely there for certain. Wayland isn't capable of syncing output on input, the protocol would need to be redesigned and then extended to do it.
    Last edited by duby229; 03-30-2020, 11:21 PM.

    Comment


    • #62
      Originally posted by oiaohm View Post
      Really its possible to get a 2003 distribution install it in a virtual machine and run for a while. I recommend you do so you take of your rose colour glasses. X11 was not in that good of condition in 2003. It was 2007 when x.org finally learns how to auto-configure itself.
      He did not say that. He said that in 2003, "desktop linux was at a marketshare height it hasn't reached before or since". I wouldn't doubt that he's correct about that - roughly half the people locally in my industry were using some form of desktop Linux back then. I had installation disks, and was frequently asked to come to someone's house or office and help install SuSE. People used to buy a lot of PCs without an OS back then - something that MS made sure would not continue to happen.

      Regarding your comments on the condition of the desktop in 2003 - KDE 3.x in 2003-2004 was a very nice desktop. I still use Trinity fairly often because I prefer some of the features that no longer exist with today's advanced desktops, I find it quite nice looking, and I like the workflow.

      But, besides all that, I think what you've been posting today is very valuable information. I really appreciate you taking the time to respond to everyone, I'm learning quite a bit more about wayland from your different responses to people's comments. Clearly wayland is the future for desktop Linux distros. Unfortunately it has been a slow-arriving future, but the technical challenges are very well documented, and there are no shortcuts. And I agree that it's much closer to an RC-quality release than an alpha-quality release. Today's benchmarks really show that.

      Comment


      • #63
        Originally posted by duby229 View Post

        Are you using Arch or one of it's derivatives? I've been told by one other guy about some hacks they made to reduce the impact of input lag. (If I remember right they did something with cgroups to increase the amount of CPU time allocated to wayland under cpu load conditions, but I never looked into it. I just vaguely remember this guy mentioning it. It's not a true fix though, it's a literal hack.)

        Anyway regardless of whether or not you personally notice it, it's most definitely there for certain. Wayland isn't capable of syncing output on input, the protocol would need to be redesigned and then extended to do it.
        Running Ubuntu 20.04. I don't know what you mean by "syncing output on input". As I said, I know that the lag problem exists in some cases, but it's not pervasive and not something that is inherent to Wayland. Under Wayland, both screen compositing and input processing are handled by the same process (unlike how it's done on X11) so it comes down to that process' implementation, the protocol is not involved in this. With X11 you *HAD THE IMPRESSION* that there never was a lag problem because pointer movement was handled by the X server which made it responsive regardless of how garbage the compositor was - but only the mouse pointer, not reacting to actual events. Early Wayland compositors such as Gnome Shell were ports of X11 compositors, which obviously didn't fare well (not properly multithreaded etc).

        My only real-world experience with Wayland is with GNOME, until 3.32 reactivity and lag were (occasionally) a problem, by 3.34 it had improved substantially, on 3.36 it's better than it has ever been with a composited X11 desktop and on 3.36 with RR enabled is as close to perfection as it gets.

        Comment


        • #64
          tildearrow Congratulations. Your assumptions made you censor obvious facts. As many times before it is historical proven and well documented how the Wayland Meritocracy works.
          https://cgit.freedesktop.org/wayland.../GOVERNANCE.md

          Oh and I didn’t tell you to use GNOME instead of your current setup. Use weston or whatever you like.

          Comment


          • #65
            Originally posted by 144Hz View Post
            tildearrow Congratulations. Your assumptions made you censor obvious facts. As many times before it is historical proven and well documented how the Wayland Meritocracy works.
            https://cgit.freedesktop.org/wayland.../GOVERNANCE.md
            I hate you.

            Originally posted by 144Hz View Post
            Oh and I didn’t tell you to use GNOME instead of your current setup. Use weston or whatever you like.
            Yes, you did. In a clever and indirect way.

            Comment


            • #66
              jacob Take a +1. Here we are in 2020 with Ubuntu LTS on GNOME 3.36. And people are still discussing year old software. Mutter and Shell 3.36.1 are just released and they come with a few more fixes to the main thread blocking issues.

              Some people’s mental blocking and mental lag is just horrible.

              Comment


              • #67
                Originally posted by 144Hz View Post
                jacob Take a +1. Here we are in 2020 with Ubuntu LTS on GNOME 3.36. And people are still discussing year old software. Mutter and Shell 3.36.1 are just released and they come with a few more fixes to the main thread blocking issues.

                Some people’s mental blocking and mental lag is just horrible.
                To be fair, no STABLE distro with GNOME 3.36 has been released yet. But I get where you're coming from. It's like those people who always whine that BTRFS is supposedly crap and unreliable because 15 years ago they had an irrecoverable corruption problem with it.

                Comment


                • #68
                  Originally posted by jacob View Post

                  To be fair, no STABLE distro with GNOME 3.36 has been released yet. But I get where you're coming from. It's like those people who always whine that BTRFS is supposedly crap and unreliable because 15 years ago they had an irrecoverable corruption problem with it.
                  I would not use btrfs as an example, because btrfs still doesn't have stable RAID5/6 support after 15 years, nor to say RAIDZ.

                  I used to believe btrfs could be a nice alternative to ZFS, but now I'm thinking of migrate away from btrfs to xfs -- the latter one is on a stable track towards a COW filesystem.
                  Last edited by zxy_thf; 03-31-2020, 12:39 AM.

                  Comment


                  • #69
                    Originally posted by zxy_thf View Post
                    I would not use btrfs as an example, because btrfs still doesn't have stable RAID5/6 support after 15 years, nor to say RAIDZ.

                    I used to believe btrfs could be a nice alternative to ZFS, but now I'm thinking of migrate away from btrfs to xfs -- the latter one is on a stable track towards a COW filesystem.
                    BTRFS has no stable RAID 5/6 because no-one seems to be willing to fund it. Those who use BTRFS in production and pay for its development (directly or indirectly) all prefer RAID 10 and presumably would use that even if BTRFS had stable 5/6/Z.

                    XFS is a great journaling filesystem but it is far from being an actual full-fledged CoW filesystem. Maybe it will evolve towards that, but it won't be in the foreseeable future. For RAID 0/1/10, BTRFS is rock solid and if I wanted RAID 5/6 I would probably go the XFS or Ext4 over LVM route too, at the cost of losing some of BTRFS' extremely useful features.

                    Comment


                    • #70
                      Originally posted by oiaohm View Post

                      https://gitlab.freedesktop.org/wayla...land/issues/84

                      The problem is different to what you think it is. When it comes to applications using VRR they will basically use opengl/vulkan like they do now though the normal DRM(Direct rendering manager) under X11 with Wayland. No major differences.

                      Its more tell compositor to switch in VRR mode because if GPU is not in VRR mode program cannot use VRR mode. If every compositor implemented a unique way for this not going to be disaster bad because application code does not need to be coded uniquely for this. Application could simply try to use VRR see by opengl/vulkan it not working and display message telling user to enable it. Ok not the most nice experience. We are not talking absolutely deal breaker or stacks of unique code in applications so it works.

                      The reality with current wayland protocol VRR could work perfect if the compositor was rendering the screen in VRR mode so the application able to use opengl/vulkan instructions to the DRM to control it.

                      There is another option is application wanting to use VRR in fact use DRM leasing to have the complete screen handed over to them when leased they have full control of the VRR setting but this would be horrible rough. This has to be done for VR headsets because compositor does get to be too much overhead. Yes VRR in DRM lease done under wayland for Virtual Really works perfectly. So some VRR stuff works with wayland.
                      i was fairly hostile in my original comment so i appreciate the fair reply back to it. i do hope wayland gets vrr support soon and DE's like gnome don't take their sweet time to adopt it. vrr is really nice for games. for those curious to the level of experience it adds, its like running xorg with composite enabled to no longer get any screen tearing when you're dragging a window or scrolling in web browser. vrr makes it super nice to no longer worry about always HAVING to max out to your refresh rate to prevent tearing. linux has made major strives in improving its gaming experience and anything that puts a damper on it will only set it back.

                      it is nice to hear though there have been talks about getting it working with wayland. i may be critical with wayland but most of my experience with it stems from gnome with nvidia. i recently replaced my 2070 with a 5700 xt because i wanted to support amd's open source drivers and no longer deal with the what if's of nvidia supporting x, y, or z. so i should give gnome and wayland another shot now. personally i haven't been happy these last few days as my original 3900x kicked the bucket on me on stock settings with zero pbo... i just recently got my new one i had to buy because amd kept giving me a run around when i tried to rma it (they wanted me to run windows.. even though i told them i did test on windows as well. i guess they saw linux and noped out of it?). had to reinstall arch from all the corruption i got from the hard locks... sigh.
                      Last edited by pieman; 03-31-2020, 01:55 AM.

                      Comment

                      Working...
                      X