Announcement

Collapse
No announcement yet.

Ubuntu 22.04 LTS Changes Default For NVIDIA Driver Back To Using X.Org Rather Than Wayland

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

  • Ubuntu 22.04 LTS Changes Default For NVIDIA Driver Back To Using X.Org Rather Than Wayland

    Phoronix: Ubuntu 22.04 LTS Changes Default For NVIDIA Driver Back To Using X.Org Rather Than Wayland

    While back in March Ubuntu 22.04 "Jammy Jellyfish" changed the default behavior for NVIDIA's driver to use Wayland inline with Intel and Radeon graphics having used the GNOME Wayland session rather than X.Org for the past few releases, this change was reverted at the last-minute. With a launch-day SRU, Ubuntu 22.04 LTS is defaulting to using the GNOME X.Org session rather than Wayland when running the proprietary NVIDIA driver...

    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
    I was just about googling for this, as I got puzzled as to why my new 22.04 used X instead of Wayland.

    Anyway - considering the amount of problems I have encountered with Wayland on nVidia proprietary drivers, it is probably for the best for now. I hope nVidia sorts this out eventually.

    Comment


    • #3
      I'm not sure if "enjoy the NVIDIA Wayland experience" is the correct way to put it, yet.

      Comment


      • #4
        Bad long-term thinking by Canonical IMO, and this harms the Wayland transition which should be done as fast as possible. The only way to make NVIDIA take Wayland support seriously is to push it as the default session on major distros. Fedora has shown they understand this. The more people get rid of bloated abandonware like X the faster will Wayland mature (even though it is already usable and relatively stable on GNOME, at least).

        Comment


        • #5
          Michael a link to the issue is missing: https://bugs.launchpad.net/ubuntu/+s...3/+bug/1969566

          Comment


          • #6
            What a joke this LTS is!
            On Kubuntu they even removed the Wayland package completely so you cannot test it even on Intel or AMD GPUs without downloading and installing that package.

            Comment


            • #7
              Good, now the NVidia developers can lean back again and the issue that they gave for recommending Xorg will remain unresolved for many months more. Good call!

              Comment


              • #8
                Yeat, it's a conundrum, what should Canonical do, support your quest to get Wayland functioning in the future? Or support their users to get a functioning desktop (as good as possible given their hardware) today?

                Comment


                • #9
                  Originally posted by Mechanix View Post
                  I was just about googling for this, as I got puzzled as to why my new 22.04 used X instead of Wayland.

                  Anyway - considering the amount of problems I have encountered with Wayland on nVidia proprietary drivers, it is probably for the best for now. I hope nVidia sorts this out eventually.
                  This comment from an actual nVidia Linux driver developer thoroughly explains why Wayland & Xwayland will probably remain problematic for the foreseeable future;
                  thus, sticking to X11 is actually a good choice for Ubuntu 22.04 LTS:

                  I'm not that worried about general game perf (especially those in the test suites of popular Linux benchmarking suites) with kernel-side commits, which I assume is what you're referring to with radeonsi Vs. NV perf. I assume most games are optimized to minimize command buffer submissions because their engines are optimized for WDDM/Windows.

                  I'm well aware implicit sync is the semantic of the Linux graphics stack, as I've been pushing back on assuming that semantic for years, and at this point I think everyone agrees, all else being equal, explicit sync is preferable. The only major component of the graphics stack that doesn't support explicit sync is X. Hence, while I don't dispute that this is an NVIDIA driver issue, I still assert that X not supporting explicit sync is a valid X issue as well, and my opinion is that addressing that is better for end users than adopting implicit sync semantics in the NVIDIA driver. While OSS driver stacks have supported Wayland and GBM for years, the fact is our driver already requires a more or less bleeding-edge set of supporting OSS components to support these use cases, so it doesn't necessarily need to be burdened by backwards compatibility with a host of older implicit-sync-only userspace or kernel components. They already aren't going to work for other reasons.

                  Yes, we could theoretically attach/consume implicit fences to buffers from userspace to mimic OSS driver behavior to some extent. I followed Jason's patch series to this effect, and we do some of this for synchronization in PRIME situations now, as it's vastly simpler when the only implicit synchronization boundary we care about is SwapBuffers() for consumption on a 3rd-party driver. It gets much harder to achieve correct implicit sync with arbitrary modern API usage (direct read/write of pixels in images in compute shaders, sparse APIs, etc.), and this has been a big pain point with Vulkan implementations in OSS drivers from my understanding. I don't know what the current state is, but I know it limited the featureset exposed in OSS Vulkan drivers when they first came out. I assume it's technically achievable, but I'd prefer not to add that complexity to our driver stack, nor do something like downgrade functionality of dmabuf-based surfaces to account for such limitations just for something everyone agrees is outdated in a world where rendering isn't as simple as read-only textures and write-only render buffers occupying the entirety of a single kernel-side allocation in a given command buffer, which was a pretty accurate mental model of GPU usage when implicit sync was developed.

                  Comment


                  • #10
                    Originally posted by alem View Post
                    Thanks for the link. Very interesting that
                    - the issue is about Xwayland / backward compatability, not native Wayland clients.
                    - is related to implicit vs explicit sync. Implicit sync has been a major pain point for Wayland compositors, including the famous "cursor only updates at game refresh rate" problem.

                    I.e. IIUC this is purely about missing legacy features in either X or the nvidia driver - while the architecture for the future is already in place.

                    Comment

                    Working...
                    X