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

  • #91
    Originally posted by wertigon View Post

    You are arguing like a person would say Linux is "broken" because the MACH has a better structure - that kind of thinking aged like fine milk. But to clarify, "broken" driver model, in this case, is that it is not compatible with the Linux model. Maybe I should have said "Incompatible" model instead, but oh well.
    Yeah, seems everybody, in particular including open source Mesa driver developers, thinks that an explicit sync architecture is better. The current Linux implict sync model was a fine choice 20 years ago, but is increasingly falling behind the times. There have been long discussions on the Mesa developers mailing lists how to move towards an explicit sync model, made a LOT more difficult by the understandable desire to not break all existing users.

    For a non-Mesa driver it doesn't seem clear at all that rearchitecting it to an implicit sync model makes sense, considering Mesa itself is planning to move away from it.

    Kopper+Zink works for freakin' *everything* (once bugs have been ironed out). And everything needs to support Vulkan in either case. So why not simply *only* support Vulkan, and Zink the games on OpenGL, and call it a day? From where I am standing this is now the logical choice to support desktop Linux. Who cares about whether Wayland renders at 10 000 FPS or 100 000 FPS? Does it matter if a Bugatti can go 300 mph and the Ferrari only 290 mph, when all your driving will happen below 100 mph regardless?
    Zink seems like an awesome project, and it wouldn't surprise me in the slightest if Mesa drivers for some new HW would just implement Vulkan and use Zink for OpenGL rather than making a HW-specific OpenGL driver.

    But anyway, all this stuff about explicit vs implicit sync is not that relevant to OpenGL vs Vulkan vs Zink, it's lower level concerns about how to communicate dependencies between buffers (rendered by Vulkan or OpenGL or some other API, or a compute buffer used by a compute shader) that are used by different applications (potentially running in different security contexts) in a rendering pipeline.

    Comment


    • #92
      Originally posted by indepe View Post
      From those explanations I don't understand why nvidia's driver works better with X11. To me it would sound like X11 would have the same problems as XWayland.
      I think it's because NVidia worked around all this previously in their X.Org DDX driver.

      With XWayland, that driver is no longer used and X talks directly to the kernel driver instead (via wayland), which bypasses all their X workarounds.
      Last edited by smitty3268; 24 April 2022, 04:28 PM.

      Comment


      • #93
        As a general 'user' of an LTS (mine is KUbuntu 20.04 and moved one machine to 22.04 now), I could careless about the above Wayland vs. X argument. All I want to see if when I pull up libreOffice it works. Or FreeCad, or kiCad, Lazarus, Putty, Thunderbird, start a VM, or whatever I need. I want the system to be rock solid. More FPS, syncing ... who cares? Security who cares? Play with all that new buggy stuff in another distro or non-LTS until you get it right. I just want the system to work every time I login to the system. I'd still be on Fedora if I wanted to deal with bleeding edge issues. But I am on an LTS now. Expectations are different. So far Ubuntu has met that challenge (in my experience) on my laptops, desktops, and server. And Video cards in my systems are Nvidia as a FYI. Nary a problem.

        So if going back to X makes it a better experience. Then that was the right choice.
        Last edited by rclark; 24 April 2022, 06:00 PM.

        Comment


        • #94
          Wayland is still full of bugs and I'll stick with trusty old X11 regardless of my GPU until it's had a bit more stabilisation.



          And no I won't use Gnome, why should I have a shit DE just to use Wayland ?

          Comment


          • #95
            Originally posted by jabl View Post

            But anyway, all this stuff about explicit vs implicit sync is not that relevant to OpenGL vs Vulkan vs Zink, it's lower level concerns about how to communicate dependencies between buffers (rendered by Vulkan or OpenGL or some other API, or a compute buffer used by a compute shader) that are used by different applications (potentially running in different security contexts) in a rendering pipeline.
            And now we are arguing about two separate things.

            End users: "Well, AMD, Intel and other GPU vendors are using the Mesa driver model just fine and get good results from it. Why can't Nvidia just copy that?"
            Nvidia: "Because it's not a Microkernel!"
            End users: "... So? AMD and Intel does this, why not Nvidia?"
            Nvidia: "Because we have to sacrifice a goat to do it! It's messy!"
            End users: "... Right. You are aware Kopper + Zink managed to get Wayland running just fine using nothing but your Vulkan implementation yes? Not perfectly, not yet, but working nonetheless?"
            Nvidia: "They got that working by selling their soul to Satan!"

            Look, I couldn't really care less about whether some obscure technical detail could make this easier to work with. Fact of the matter is Nvidia is clearly the guys not playing ball here. Doesn't matter if the community is wrong about this.

            Now would I love a Wayland 2.0 that uses explicit sync? Yes, yes I would. Will we get there? Possibly. If AMD, Intel and Nvidia agree it is a good thing, I cannot see why it won't happen eventually. But that does not change the fact that Nvidia is the oddball not moving with the rest of the community, and it is now starting to hurt their sales. I suggest Nvidia either start getting their shit together, or they will slowly bleed market share to AMD and Intel in this segment. Market has spoken.

            Comment


            • #96
              Originally posted by Developer12 View Post
              There's nothing to be fixed. The problem is squarely with nvidia's drivers, and only with their drivers. Not going forward with wayland in its buggy-but-workable state on their cards just allows nvidia to wallow forever. Everyone else on intel and AMD will never see a single bug, and it's time people started to associate nvidia's failings with nvidia.
              They won't, because people are just like that. But Wayland is very much "people in glass houses" here, and until Wayland itself is functional enough and stable enough to replace X for a *majority* of users, not just a very noisy 2% of them, Wayland is barely in a position to even try to pressure a behemoth like nvidia into fixing their bugs at all, let alone jumping through hoops to deal with design flaws in the graphics stack.

              This same scenario keeps playing out over and over and over again. You can take 95% of these comments and apply them unchanged to literally YEARS of distro releases. Somebody has to blink first, and it isn't going to be the 800lb gorilla. Once Wayland is actually usable, nvidia will fall in line. Until then, *Wayland itself* is what's allowing nvidia to behave the way they are.

              Once that finally happens, everything will be better for everyone: Wayland becomes a usable default, everyone has working HW, and the superior explicit sync policy becomes available. But it has to start with Wayland being adequate, and there's very little indication that that's even genuinely a goal for it right now. Instead, even basic functionality gets ignored for 5-10 years at a time, and then 90% of the work is pushed off to the DE groups anyway so that it has to be duplicated two or three times, which makes the whole process even slower. It's finally at least getting close, but there's no denying it's been an absolute farce so far.

              Comment


              • #97
                Something is telling me Wayland is going to be the Year... cof cof...the End of the Linux Desktop. Hope I am wrong though.

                Comment


                • #98
                  Originally posted by arQon View Post

                  They won't, because people are just like that. But Wayland is very much "people in glass houses" here, and until Wayland itself is functional enough and stable enough to replace X for a *majority* of users, not just a very noisy 2% of them, Wayland is barely in a position to even try to pressure a behemoth like nvidia into fixing their bugs at all, let alone jumping through hoops to deal with design flaws in the graphics stack.
                  Wayland has already replaced X11 on the majority of user's desktops. Today. AMD and intel combined make up far more marketshare than just nvidia and they're happily using wayland as the default

                  The rest of your logic falls apart from there.

                  Nvidia is the only one asking for a last-minute exception on literally the very last day.

                  Comment


                  • #99
                    Originally posted by Developer12 View Post
                    Wayland has already replaced X11 on the majority of user's desktops. Today. AMD and intel combined make up far more marketshare than just nvidia and they're happily using wayland as the default

                    The rest of your logic falls apart from there.

                    Nvidia is the only one asking for a last-minute exception on literally the very last day.
                    Nvidia's Linux market share isn't moving due to the dependency of CUDA. Intel's OneAPI looks promising, while AMD screwed up the adoption of ROCm by not supporting RDNA until Feb 09, 2022.

                    Until these two protocols below are added, xorg will remain the default for many that use the Linux desktop. Let's not forget all the current automation already inplace for xorg. This is going to remain uncommented
                    WaylandEnable=false
                    in
                    /etc/gdm3/custom.conf
                    in my Ubuntu deployments for quite some time. Can't believe enterprise Linux distributions are pushing Wayland. I understand non-LTS version of Ubuntu, Fedora and other rolling release desktop distributions. There should be feature parity before pushing a new alternative to an enterprise distribution. I'll be following Arcan since that looks like a superior project to Wayland. Wish that was actually backed by Valve instead of Wayland.

                    This a protocol extension that offers enhanced presentation timing requests and events, in order to help clients minimize visual anomalies. It is modeled after the VK_KHR_present_timing...

                    The aim of the color management extension is to allow clients to know the color properties of outputs, and to tell the compositor about the color properties of...

                    Comment


                    • Originally posted by WannaBeOCer View Post

                      Nvidia's Linux market share isn't moving due to the dependency of CUDA. Intel's OneAPI looks promising, while AMD screwed up the adoption of ROCm by not supporting RDNA until Feb 09, 2022.
                      Most machines running nvidia cards for CUDA are headless servers in compute farms.

                      Originally posted by WannaBeOCer View Post
                      Until these two protocols below are added, xorg will remain the default for many that use the Linux desktop. Let's not forget all the current automation already inplace for xorg. This is going to remain uncommented in in my Ubuntu deployments for quite some time. Can't believe enterprise Linux distributions are pushing Wayland. I understand non-LTS version of Ubuntu, Fedora and other rolling release desktop distributions. There should be feature parity before pushing a new alternative to an enterprise distribution. I'll be following Arcan since that looks like a superior project to Wayland. Wish that was actually backed by Valve instead of Wayland.

                      https://gitlab.freedesktop.org/wayla...ge_requests/45
                      https://gitlab.freedesktop.org/wayla...ge_requests/14
                      Why should ROCm or oneapi be added? Where should they be added that you're talking about? They have no bearing on wayland support. They're compute APIs.

                      Distributions are adopting Wayland and putting in place automation for it are the same thing. What did you think bringing up support for something new looked like?

                      If feature parity were important nothing would ever be adopted. It only needs to work well enough in 99% percent of cases. The rest gets smoothed out later. That's why distros have been pushing for the switch. If they wait until everything's perfect it will never happen. See HURD.

                      Comment

                      Working...
                      X