Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×
Graphics X Linux

NVIDIA's Proprietary Linux Driver Adds Support For Wayland, Mir (phoronix.com) 83

An anonymous reader writes: After being desired by NVIDIA Linux users for years, the proprietary GeForce graphics driver natively supports Wayland and Mir as an alternative to an X.Org Server. It's been a long time coming for the proprietary GPU driver stacks to support Wayland/Mir, but with today's 364.12 beta driver there is now the necessary DRM KMS kernel support and EGL extensions for being able to handle these next-generation display solutions. The new NVIDIA Linux driver also provides integrated Vulkan support, PRIME rendering support, and other additions.
This discussion has been archived. No new comments can be posted.

NVIDIA's Proprietary Linux Driver Adds Support For Wayland, Mir

Comments Filter:
  • Might be about time to move the gaming rig over to SteamOS.

    • by aliquis ( 678370 )

      Might be about time to move the gaming rig over to SteamOS.

      So far the performance has been quite a bit worse on SteamOS than on Windows. I don't see why this update would change that. So far Vulkan has performed worse than DirectX too but I assume that will change with new games/engine versions by competent developers.

      • by Anonymous Coward on Monday March 21, 2016 @12:53PM (#51744779)

        While a popular point of rhetoric, there exists ZERO evidence SteamOS (Linux) is slower than Windows. For example: https://www.youtube.com/watch?v=rISRVeJxhnE Very improperly, most people and articles are attributing poor performance to SteamOS when the real issue is sub-par ports of applications. Also note in the video you can observe a couple of glitches (texture loading) in the Window's demo whereas it's silky smooth on Linux ( - which is believed to be superior Linux file caching).

        To be clear, not that I'm ignoring your last sentence, but your first two sentences are misleading; though I don't believe that's intentional. If a game's performance is lackluster, you can completely blame the game developer as it has absolutely nothing to do with SteamOS. SteamOS has all of the foundations to provide FASTER performance than Windows. There exists no evidence to substantiate a claim that SteamOS is slower than Windows and all evidence points to platform performance deltas being that of lazy ports and developers who lack platform knowledge to optimize for Linux as they have done for Windows. Hell, once again we have games running under Wine which are starting to outperform native Windows. Which is pretty profound when you consider they are frequently doing DX to OpenGL translations to boot. Meaning they are faster even with an additional abstraction layer. Bluntly, there is every evidence that SteamOS/Linux (with NVIDIA anyways) is faster than Windows and where applications falter, you can squarely blame the developers.

        Additionally, the Vulkan comment is not true. So far, developers who are learning to use a new API, without redesigning to properly leverage Vulkan, and running on beta drivers, have performed worse than DirectX; which is a highly optimized and well understood framework. Furthermore, there are specific guideline recommendations for when Vulkan should be used and when it's possible to provide ideal performance. The current use cases are not even known if these satisfy the recommendations. As such, the examples people commonly use may not even represent ideal candidates for the newer DX12/Vulkan APIs.

        In summary, while you have accurately parroted the rhetoric and FUD, it is not supported by any available evidence. That said, I believe the spirit of your comment can be accurately rephrased to say: Many games running on SteamOS have lackluster performance because developers have failed to optimized their games for the new platform (OpenGL vs DX9, DX10, DX11). As such, many games will run slower on SteamOS than Windows, through no fault of SteamOS. This is a subtle yet profoundly important distinction. And it's a distinction which is directly contrary to the common FUD.

        • Re: (Score:3, Interesting)

          by Anonymous Coward

          Arma 3 Bechmark results:
          https://i.imgur.com/UfpUI5p.png
          https://i.imgur.com/ypWsvqz.png
          https://i.imgur.com/haTiRLZ.png

          Worth noting, the port was achieved using a DX wrapper which converts DX calls into OpenGL. With an extra abstraction layer, it's still performing on par or better than Windows.

          • by Hylandr ( 813770 )

            Mod UP +1 and Thank you for these informative posts.

            I am going to load up Linux on my desktop tonight and see how it goes. Going use a separate drive just in case though. :)

          • Hum... If these benchmarks are true, so now you have my attention. I never thought about using Linux seriously as a desktop because of the poor performance of GUIs and the ugly mess that are the desktop applications for the same, but if the AAA games are getting to have good performance on it then is a step in the right direction.
        • by aliquis ( 678370 )

          I don't really get the need for the attitude, if there existed zero evidence for it then I wouldn't mention it, however as you said in my case "don't believe that's intentional" maybe the same can be said about the harshness in your comment. But I assume it was, but you kinda covered it up by kinda stating being too harsh may not be valid because my "lies" wasn't intentional so whatever.

          Over to the posts.
          The stuff I've seen HAS BEEN lower performance on SteamOS. As for WHY that's is the case I don't really

  • Thank you Nvidia. It's about time that there was a broader support base for Wayland, and the launch-day support of Vulkan on Linux has been quite positive too.

    • by Viol8 ( 599362 )

      "It's about time that there was a broader support base for Wayland"

      Why? What exactly does Wayland bring to the table that X doesn't? I can think of a few things vice versa.

      • What exactly does Wayland bring to the table that X doesn't?

        You know every single vitriolic attack that's ever been made against SystemD.... well you could apply pretty much all of them to the X server with the main difference being that with X server they are actually true most of the time, while with SystemD most of the more salacious ones are flat out wrong and are just copy-n-pasted as trolls.

        Further, if we were to take a Venn diagram of the subset of people who foam at the mouth with hate about SystemD and the subset of people who foam at the mouth with hate at

        • by jedidiah ( 1196 )

          > You know every single vitriolic attack that's ever been made against SystemD...

          Except you didn't really answer the question.

          If anything, X is much like init. For many of us it "just works" and gets stuff done. It sits quietly in the background and does it's thing. It does not make itself a problem.

          "It's icky and crufty" isn't really an answer either for X or init.

          It seems like the best thing the Wayland fanboys can say for themselves is that you won't notice the difference. That's if we are exceedingly

          • I was also very skeptical about Wayland advantages, esp. as I considered X to be one of most cool features of Linux/Unix systems. But when you take a look to some details, then you see that it is not so cool. When X was designed, it was designed to draw primitives - lines, fonts. And it was not designed to draw bitmaps. In its current usage, it mostly draws bitmaps, i.e. true rendering is done in applications (using libraries like GTK, KDE, Qt...) while X is just slapping it together. And it does it in a ve

            • A server dishes out resources. In this case the resource is screen. It's counterintuitive if you think server= compute server, but there are other examples like print server too. It does make sense.

              • Yes, it does make sense, but it is counter-intuitive when you hear that for the first time. Exactly the case you mentioned = compute server runs clients and they attach to the server which is actually my work station. They could have chosen some other wording, no matter that technically X server is indeed a server.

                • by thsths ( 31372 )

                  It is not just counter-intuitive, it is also wrong. The limited resource is not your screen, but your desktop. That may be a small distinction, but it leads to all kinds of problem in X. For example, running multiple screens is still a bit of a faff. And you can run only one window manager.

                  In a clean architecture, the window manager would be the server, and the screens would be clients.

                  • I'm not sure many are interested in multiple window managers, but if so then you run multiple X servers or a nested X server.

        • by dbIII ( 701233 )
          Yet some of those older Kindles mentioned in another article use X. My phone uses X. Even a very low end WinCE terminal thing I have at home uses X. Somehow it works even on very crappy hardware incapable of running Wayland while you are pretending it does not.
      • by jbolden ( 176878 )

        -- What exactly does Wayland bring to the table that X doesn't?

        Better performance.
        Effective remote over high latency.
        Reduced cost of support / bugs.
        etc...

        • by dbIII ( 701233 )

          Better performance.

          I asked you for benchmarks last time and you had nothing to back up that statement. It may be the aim but Wayland is not performing better yet - especially since most of the drivers are cut and pasted from X.

          Effective remote over high latency.

          WTF? Remote access is explicitly not supported at all!

          • by jbolden ( 176878 )

            Wayland is using an architecture that has obviously better performance. It is an architecture shared by systems that do outperform X consistently. Whether it does or doesn't have better performance today of 6 months ago is mostly irrelevant. When it is done, if it works, it will have better performance. A highway under construction might only be safe to drive at 5mph. That doesn't mean that eventually it won't allow for much higher speeds than backroads and such a statement is obvious by just looking

            • by dbIII ( 701233 )

              Wayland is using an architecture that has obviously better performance

              As the benchmarks would show if there were any and you were correct. Reality is that it is a work in progress so still inferior performance, which is expected and not a problem apart from clueless fanboys lying about it when there is no need to do so.

              WTF is your problem?

        • by dbIII ( 701233 )
          Please inform the readers how expected future developments are "delivering" those things that are not yet available.
  • by jordanjay29 ( 1298951 ) on Monday March 21, 2016 @12:12PM (#51744313)
    It seems well timed to coincide with the release of 16.10 later this year, which, if all goes well, should use Mir by default for Unity 8. This gives NVIDIA 6 months or so for early adopters to work out the major kinks for them. Smart plan.
    • by rahvin112 ( 446269 ) on Monday March 21, 2016 @12:32PM (#51744529)

      Mir is a joke NIH solution to a problem that's already solved with Wayland. And just like all their other NIH solutions to problems they will abandon in a year when it's clear how much it's going to cost them to support it. It's the same story at Canonical over and over again.

      • That may be absolutely correct, but Ubuntu vanilla still accounts for a large number of linux "users" for which NVIDIA would be wise to target in one go like this.
      • Mir exists, in part, because there actually are some real problems with X11, such as the complete lack of anything resembling security on the input path. These problems were not things that the Wayland developers decided to fix. I'm not a huge fan of Mir, but if you're going to replace X11 then replacing it with Wayland is at best a sideways step.
        • Mir exists, in part, because there actually are some real problems with X11, such as the complete lack of anything resembling security on the input path. These problems were not things that the Wayland developers decided to fix.

          Compositing window managers intercept nearly everything so that they can re-map events to arbitrarily shaped windows etc. Which security flaws aren't easily fixed by compositing windowmanagers on X?

        • by neuro88 ( 674248 )
          No, Wayland fixes all of this. In fact, this is in part why Mir uses the exact same input library as wayland: libinput.
      • Fedora and Arch and just about every other Linux distro are NIH solutions including Android. If you are not using Slackware then you are using NIH solutions. What's your point? SystemD is a NIH solution, Wayland is a NIH solution, Pulse Audio is a NIH solution, Gnome and KDE are NIH solutions. I could go on and on. Your argument that people should not innovate to suit their own needs and use cases is moronic at best. The NIH excuse is tired and beaten to death. trying to use NIH to justify your hate
    • by Junta ( 36770 )

      Of course, 'if all goes well, should use Mir by default' has been a missed goal a few times in the past.

    • It is not coincidence. It's planning on the part of Canonical and nVidia.

  • Nowadays the headline should be "NVIDIA's Proprietary Linux Driver Adds Vulkan 1.0" and in the article text you can also mention Wayland and Mir.
    • Except that Vulkan support isn't news.
      Nvidia had Vulkan support for Linux on launch day. The news is the official Wayland support.

  • Now we can have nicely accelerated VR linux desktops. https://www.youtube.com/watch?... [youtube.com] https://github.com/evil0sheep/... [github.com]

Congratulations! You are the one-millionth user to log into our system. If there's anything special we can do for you, anything at all, don't hesitate to ask!

Working...