Plasma/Wayland and NVIDIA – 2017 edition

More than a year ago I elaborated whether KWin should or should not add support for NVIDIA’s proprietary Wayland solution. I think it is time to look at the situation of Plasma/Wayland and NVIDIA again. In case you haven’t read my previous blog post on that topic I recommend to read it as I use it as the base for this blog post.

Compared to a year ago not much has changed: NVIDIA still does not support the standard Linux solution gbm, which is supported by all vendors and nowadays even going to enter the mobile space. E.g. the purism phone is going to have a standard graphics stack with gbm. So no additional code required. But NVIDIA doesn’t support gbm. Instead it has a proprietary implementation called EGLStreams, which no other vendor implements. Due to that Plasma/Wayland cannot support OpenGL for NVIDIA users.

But current KWin master branch (what will become 5.12) supports automatical fallback to Qpainter compositing in case OpenGL fails. With that it should be possible to run Plasma/Wayland on NVIDIA hardware. Granted it won’t be accelerated, but as explained above that is only NVIDIA’S fault. Also I have not tested this yet. It might be that NVIDIA doesn’t support dumb buffers on DRM.

In my blog post from last year I elaborated whether KWin should add support for NVIDIA’S proprietary solution. I put out a requirement that the patches for Weston need to be merged first:

For KWin such patches do not exist and we have no plans to develop such an adaption as long as the patches are not merged into Weston. Even if there would be patches, we would not merge them as long as they are not merged into Weston.

A year passed and nothing happened. I don’t expect anything further will happen: the patches won’t be merged into Weston. Given that it doesn’t make any sense to make this a requirement for KWin. If we hold up the requirement it would be like saying we would never accept it.

Last year I hoped that XDC would find a solution for the problem:

We do hope that at XDC the discussions will have a positive end and that there will be only one implementation.

And it looked positive: a new universal buffer allocation library got announced. I hoped that this would solve the situation pretty quickly. The new library would get implemented, Mesa and NVIDIA add support for it, we slightly adjust our code and drop gbm. Everybody happy.

But now another XDC passed and from what I understand not much process was made. The library is not ready and no driver uses it. We waited one year for it, I doubt waiting another year will change the situation. Realistically I think it will take another two to three years for the library to get implemented if at all. Then it will take about a year for Mesa gaining support and shipping a release. Yet another year for distributions shipping with that version so that we can depend on it without people killing us. So maybe in five years there will be a replacement. I don’t think we can wait that long.

So does this mean KWin will gain support for EGLStreams? Certainly not! I do not think that the KDE community should spend any time to support NVIDIA’s proprietary solution! We are a free software community and we should not implement code which only benefits proprietary non-free solutions. There are way more free things to do to improve Wayland without having to write code for proprietary solutions.

Also there is another aspect which I did not consider in my blog post last year: XWayland. XWayland also uses gbm and does not have support for NVIDIA’s proprietary solution. Due to that one does not have OpenGL for any legacy X application. This probably includes most games, but currently also browsers such as Firefox and Chromium. I don’t think that this would give a satisfying experience to NVIDIA users. And it is also hardly better than rendering everything through the QPainter compositor. This is another reason for the KDE Community to not spend any time on implementing support for EGLStreams.

But I think there is lots NVIDIA could do. Today I would accept a patch for EGLStreams in KWin if NVIDIA provides it. I would not be happy about it, but I would not veto it. If it is well implemented and doesn’t introduce problems for the gbm implementation I would not really have an argument against it. But I expect NVIDIA to do it. I don’t want a contribution from a non-NVIDIA developer. This mess was created by NVIDIA, NVIDIA needs to fix it.

Similar I think that NVIDIA should adjust XWayland. I understand that NVIDIA is not happy with the design of XWayland, but nevertheless they should make it work. Their users pay quite some money for the hardware. I think they have a right to demand from NVIDIA to fix this situation. Ideal would of course be NVIDIA adopting gbm. But as that seems unlikely, I think it is the duty of NVIDIA to provide patches for their users.

56 Replies to “Plasma/Wayland and NVIDIA – 2017 edition”

  1. What will happen if a ideological solution is chosen instead of a pragmatic one:

    Gnome / Mutter works with Wayland and nVidia, so distributions, especially enterprise one, will simply ditch plasma if they want to deliver Wayland to their users. Most big distributions already have Gnome as the default, this will just make sure that even most others will switch as well.

    Developers were recently asked to switch their systems to Wayland and test. People using nVidia hardware, as it was made clear in some replies to that, simply won’t, because why should they switch their productive system to something that doesn’t work? And “don’t buy nVidia” is not an option for many people who either play games or rely on an OpenGL implementation that is better than what Mesa offers. Less so for the many people who already have nVidia hardware which works perfectly fine under other environments.

    So: personally whilst understanding the reasoning, I think it is a terrible idea that won’t benefit KDE Plasma at all.

    1. If you read my blog post carefully I see a big issue in XWayland not working on NVIDIA. That’s also the case for the GNOME distributions and honestly I don’t understand why Ubuntu shipped with Wayland by default given that XWayland doesn’t work on NVIDIA. I rightfully put that on the showstoppers list.

      1. > I don’t understand why Ubuntu shipped with Wayland by default given that XWayland doesn’t work on NVIDIA.

        It defaults to Xorg instead for NVIDIA users. Or at least that’s what I’m told, I can’t test it because I don’t have any NVIDIA hardware.

    2. […] rely on an OpenGL implementation that is better than what Mesa offers.

      That seems a very outdated statement to me. It has been years since I had trouble with Mesa (admittedly I follow Mesa’s master branch) playing any games. Performance has jumped by leaps and bounds (I’m sure there is still room for further improvements, but they will happen, both Intel and AMD as well as vendors from the SoC GPU market have a vested interest in this).

      This leaves only crappy software that expects wrong behaviour (“what Nvidia does” or “let’s hard-code driver names and non-standard extensions”) or relies on compatibility contexts (crappy software again IMHO, but I won’t argue about it). The latter is something AMD is currently in the process of fixing for Mesa, they seem to want to drop their proprietary driver entirely. At least that is, what I take away from what Marek has written on #dri-devel a couple of days back (search for “compat”, conversation starts at 20:33; ). If this means supporting all of the mess that is compatibility contexts or just enough to get their requirements like CAD or other professional software running, I cannot say.

      Anyway: “don’t buy from $vendor” is nothing new for Linux users (remember the mess, that was WLAN drivers) and I find it a valid recommendation, if said vendor doesn’t care for Linux support. If you have a specific workload that is not supported by Mesa today, that is most likely a bug and should be reported.

    3. Wayland is rather worthless without XWayland currently anyway, so even if they did implement it few applications would be able to even run.

      Until they add EGLStream support for XWayland there is no point, nvidia is worthless in Gnome-shell aswell.

    4. Ahem. Intel driver supports OpenGL 4.5, Vulkan 1.0 and Open GL ES 3.2 all Khronos certified. OpenCL 2.0 is supported through Beignet. Hardware accelerated decoding and encoding support for H.264, MPEG-2, H.265, VP8 and JPEG.

      AMD open driver supports OpenGL 4.5 and Vulkan 1.0 both Khronos certified. Hardware accelerated video decoding and encoding for H.264 and MPEG-2.

      Only a few NVIDIA driver users (very like Apple users) assume that only NVIDIA can write a good driver – that’s never been the case.

      I’ve used NVIDIA closed source driver long ago, it’s a pretty good driver. But I’d rather have FOSS drivers and the ability to use Wayland. NVIDIA had a long time to prepare for Wayland support, this wasn’t something forced on them or anyone else. Their fault for waiting too long.

    5. @Daniel as for the devs being asked to switch to Wayland-on-Gnome, well, I think, Gnome simply have got more money behind. At the moment it’s more feature-complete — KDE-on-Wayland still doesn’t even have primary clipboard, and I am as a developer (I don’t use though Gnome or KDE; I’m a tiling-workflow guy) can tell you, it’s a real showstopper, big deal.

  2. Well all I can say is, I am a fan of Nvidia, and only use Linux, and have various boxes with their hardware, but am annoyed by the fact that they seem to be generally distancing themselves from their previously reasonably good Linux support (apparently, it is also unlikely there will be any support for native 4k in hardware from Nvidia on Linux either, thereby destroying a previously decent income stream for them from Kodi boxes).

    I’m not a gamer so increasingly, the onboard GPUs on Intel CPUs, are doing the job for me, Nvidia used to be the go-to GPU for me for Linux, but they seem to be busy shooting themselves in the foot (perhaps they think it’s just not worth spending the money on supporting Linux any longer?)

    1. It’s called getting too big for your pants. Both NVidia and Google are exhibiting the same syndrome – pure hubris, not listening to customers and screwing up product. Maybe it’s contagious, I don’t know.

      The beautiful thing is, it doesn’t matter how big you are or what your cash reserves or stock market cap is – you will piss away all of that money if your attitude as a CEO starts to suck… And both of these CEOs attitudes have been sucking major donkey something or other for a while now.

      Ever heard the saying, the bigger they are, the harder they fall? Get ready for watching some big falls in the next few years from major manufacturers and software companies. Size is irrelevant – attitude and values determine everything. Nvidia has none – or I should say, it has a shitty attitude… Coming from the top and trickling down like piss on everyone else, consumers included.

      Good thing AMD has seized on the moment and so has Intel. If anyone can tear NVidia a new one with Linux, it’s these two… Perhaps Intel could even buy AMD – AMD was struggling for cash not that long ago… and as a Linux powerhouse, they can propel Intel+AMD on the desktop and laptop to the extent NVidia has never and will never be able to do.

      Huang is as dumb as he’s rich. He’s just too blind to see it.

  3. I see a couple of problems in your post:
    1. You keep calling EGLStreams “NVIDIA’s proprietary solution”, but EGLStreams is actually an EGL extension – thus potentially more portable than GBM as it can work outside Linux world (I know almost nobody has implemented them so far).
    2. Why would you be opposed to a third party providing patches for EGLStreams? Why does that matter?

    Just for context, I appreciate KDE, it’s the DE I feel most comfortable with (even as a Nvidia user) and I wouldn’t dream of telling you what you should do. I just find the above points a little muddy and I’d appreciate if you could elaborate a little, as opposed to letting people speculate on your motives.

    1. You keep calling EGLStreams “NVIDIA’s proprietary solution”, but EGLStreams is actually an EGL extension

      I expected this to come. EGLStreams is proprietary as there is only one vendor. That’s exactly the definition of proprietary.

      Why would you be opposed to a third party providing patches for EGLStreams? Why does that matter?

      There are many things people can work on for Wayland. I appreciate any help on Wayland and I would love people helping out. What I do not want is to get people working on the wrong things and spend time on things that NVIDIA should implement. That’s why I think it’s important.

      1. EGLStreams is a specification. It is a series of extensions to an open API. By definition that is not closed. Nvidia’s implementation is closed, but EGLStreams isn’t.
        Just my 2c.

        1. Sure, but it’s still only implemented by one vendor (or maybe two, since it is in the KHR namespace). OpenGL has lots of these as well. Only those part of a standards revision are really guaranteed to work though. Some are obvious enough for all vendors to implement. This is apparently not the case for EGLStreams. IIRC implementing them would me major changes to a lot of parts of the stack. There were also concerns about the spec itself (IIRC, again) during the last public discussion I’m aware of.

          Just because one vendor has enough clout with a standards body to push an extension through, doesn’t make it less proprietary. Just take the MS Office XML specification. I’d still consider that a proprietary format even though it is a published standard. But it has only one “good” implementation.

          1. > But it has only one “good” implementation.

            Could you clarify, are you talking about LibreOffice or WPS Office implementation of OOXML? :Ь Because AFAIK MS Office have problems with supporting their own format — it’s often being rendered differently in different MS Office versions, up to the point of having different colors.

        2. Proprietary != Closed source and proprietary != Secret.

          Proprietary means custom solution developed in house. It is often secret and closed source, but not necessarily so.

      2. I always read your blog posts and interested in how Wayland is progressing. Not wanting to Hi-Jack your post, I put an issue I am having with Wayland on neon on as I dont know how to bug report. I cannot not code so my way of helping you guys is to try this stuff out and and report back but not getting any response.

  4. You’re doing the right thing. I was speechless when Gnome devs dropped the ball. Besides, right now companies search for middle ground solution, there is no point to code something that works for 1 vendor only and will likely be dropped anyway. Nvidia is a multibillion corporation with hundreds maybe thousands of software developers. If anything they could support both and not shift more work towards community.

    1. Nvidia’s problem is their driver is cross-plaftorm, while GBM isn’t. They have exactly the same problem KWin (and other compositors) has: they’d end up maintaining two code paths.

      Luckily for me, Wayland isn’t widespread yet and it can be safely ignored 😉

        1. To me that’s just scare tactics. I’ve asked countless time for a reference to a major incident caused by xorg’s insecurity and always came up empty.
          Sure, Wayland is more secure, no one is saying otherwise. But if xorg’s shortcoming aren’t so easily exploitable, then security is not reason enough to migrate.

      1. Here’s one reason that is sufficient to make the case for Wayland:

        When running on X server, any program can read the keyboard input bound for other programs – i.e any program can be a keylogger. That game you play can read your Facebook/Gmail/bank password and anything else you type.

  5. Thank you Martin and the KDE team for taking a stance here. Nvidias behaviour wouldn’t fly on any other platform either. If for example Mircrosoft specifies a particular interface for Windows, the hardware vendors will have to target that interface as well. I’m sure MS would ask important vendors for input, but if all but one say “let’s do $foo”, I have a hard time seeing MS going for $bar, just so the spec fits the hardware of one vendor better.
    Nvidia should just play ball here (they won’t I know, they never have unless forced to do so; just look at their FLOSS efforts for stuff that’s for the automotive sector; I really doubt we’d see much Tegra support without them wanting to sell Tegras to car manufactures).

    The only sad part is, that since the Linux desktop market is rather small, potential customers have no real “wallet voting power”. Still, people should take a hard look at the offerings by AMD and Intel. Maybe Nvidia will turn around eventually, if enough do it.

  6. @Martin … namechange? So I guess congratulations are in order :-).
    And again a german umlaut in the name ;-).

    To the topic:
    While not a problem for me personally using AMD hardware, it’s a bit of a sorry state on the NVIDIA side. There was a solution agreed on, yet there was little done.

    Gnome implemented EGLStreams in Mutter some time ago, and probably because of that the unified library lost a bit of traction. I can understand why Gnome did it though, to be able to support Wayland in NVIDIA “properly” early on and to replace it later with the unified solution.

    To the unified library – yes, this should be solved on the nvidia/mesa level instead of the window managers. And I understand that you don’t want to put effort in supporting it for replacing it later. But as you said, it’s a probably a lot of years off, unless we see huge steps towards a solution in the next month (which I doubt, and I don’t see a sponsor for this effort but NVIDIA themselves, and their interest seems very limited). It’s sad to see NVIDIA promising things not living up to their promise – and simply don’t deliver. I really hoped that with the unified library will happen rather sooner than later.

    I understand your position, even with NVIDIA being a mighty vendor and their proprietary drivers used a lot (I know nobody running open source drivers).

    But well, AMD starts to live up to their OSS promise, and they do better and better with every mesa / llvm release when it comes to games. The more is invested there, the less linux users will buy NVIDIA. Which is good for OSS, good for AMD and for us all :-).

    1. >>I know nobody running open source drivers).

      Now you know one =)

      I’ve been using Nouveau or years on different Nvidia chipsets, and happy with it. I wouldn’t want the crappy blob on my systems.

        1. It still black screens, but in the meantime Nvidia’s blob has learned how to properly blacklist it during install 😉

        2. I have to deny on that. I’m using it in my work laptop, and having more issues than I can count, which only occur if you have more than one screen attached.

          First of all screen recognition is wrong. It just shuffles screens as it likes. Secondly, you’ll find artefacts, re-drawing issues, which tend to be so serious that you can’t even tell what’s currently displayed.

          Yes, if you only use your primary screen – no issue. But nouveau is way off being used productively anywhere. If you attach your first beamer, you’ll know.

          I don’t want to shun the effort and good work nouveau guys are doing. It has significantly improved over the past year, before it was not even feasable on single-screen usage.

          There is some way to go, and NVidia is not always making it easy for the driver developers as we’ve seen on recent blogs. I draw my hat, of the length nouveau developers have gone to provide us with the best experience possible. But unless NVidia opens up, or lives up to promises with their proprietary drivers, they’re no option any longer. They’ve joked developers of nouveau and all of us too often with empty promises.

    2. A majority of people do use the open source drivers, most laptops and desktops come with integrated Intel and AMD GPUs. In contrast, almost all of the people using NVIDIA GPUs would do so only on a desktop, and most likely own powerful cards for the purpose of gaming. That number is small compared to integrated GPU users.

  7. This will lead to nothing except users voting with their feet and ditching kwin. In fact, that’s what I will probably do. Nvidia hardware is what I have, and I won’t throw it out just because kwin won’t support it.

    Seriously, Martin, how do you expect users to react given your attitude towards this?

    1. I hope that users will reflect on what I wrote and realize that EGLStream support won’t help as long as XWayland doesn’t support EGLStream. Yes you can vote with your feet and use GNOME which has EGLStream support just to realize that the game you want to play is now rendered on the CPU. Then you can vote again with your feet and go back to X11.

      I think that users will understand this and that’s why I made the XWayland case a prominent part of this blog post.

      1. Yes, that’s one possibility. Another is that people who don’t play 3D games and just want their compositor to work at a decent speed will stick with Gnome as a Wayland compositor. Especially when they’re after the other benefits that Wayland brings, such as improved security.

        Now I can understand that you don’t want to do the work. But refusing patches not because of code qualify concerns but merely because they were written by somebody other than Nvidia? Come on…

  8. So, just to be clear, if a “non-NVIDIA developer” were to submit a patch that is “well implemented and doesn’t introduce problems for the gbm implementation,” such a patch would be rejected without consideration? Or would you at least consider such a patch, provided the contributor was willing and able to support it?

      1. If you truly feel that my question is only theoretical, I’m unsure why you felt the need to preemptively announce that you “don’t want a contribution from a non-NVIDIA developer.”

        In any case, your refusal to answer my question implies that you would reject such patches, which nearly guarantees that you won’t receive any.

        1. As I understood it, I imagine he is ***really*** hoping nobody will waste their time doing something that powerfu-rich-NVIDIA should be doing.

        2. Someone has to maintain it, and that’s probably not something a single volunteer is willing to do. So there is the risk that this ends up not being maintained, only NVDA really has incentive to continue working on this and if they aren’t even willing to pick up the mantle…

          1. What leads you to believe that Nvidia has any incentive to support this? To the contrary, Nvidia has no monetary incentive to create and support an EGLStreams patch for KWin. If Nvidia ever provides such a patch, consider it charity, in which case, don’t expect long-term support. Rather, if you want long-term support, you’re much more likely to receive it from a contributor who truly has incentive to provide it.

  9. I’m totally agree with Martin, I don’t think is good idea to spent development time on vendor specific solutions, that’s against UNIX philosophy. GBM isn’t exactly portable, but more transparent solution for OpenSource.

    If Nvidia don’t want to put any effort creating a community accepted solution, that’s not any project fault.

    I also prefer generic development for generic hardware tasks. I don’t see any added value supporting vendor specific technologies because generic solutions may not work fast as expected due vendor specific hacks and customization.

  10. At this point, with AMD Vega support in Mesa as good as it is, and continually getting better, there seems little point pandering to NVIDIA. If NVIDIA want to compete in his space, nouveau has already done most of the work for them. Stop being obstructive and just give nouveau a hand getting reclocking working fully. As others here have pointed out, unless NVIDIA also adapts XWayland to EGLStreams, the Gnome support for the NVIDIA proprietary driver is basically worthless anyway.

    This is how you lose, NVIDIA. First the Linux desktop, then Linux GPGPU, then everything else, piece by piece by piece. Change direction now, or regret it.

  11. The allocator itself hasn’t moved much, largely because we’ve all been doing infrastructural work to try to make that happen.

    For example, the buffer modifiers work we did to expose tiling & compression modes through KMS, GBM, EGL, Vulkan, and Wayland, was required for these subsystems to expose enough information to the allocator (and receive enough information from it), in order to be able to make a sensible decision. There are a few other places like this where we didn’t have the low-level plumbing in place to support the allocator, and we realised we needed to expose far more information in order to support it.

    I’m hoping for a much more productive 2018 on that front.

  12. Good to finally see some in the Linux community making demands to vendors. We have a awesome community that often fix vendors ignorance and shortcomings, thats good when it is for small vendors with limited resources, but it also makes users point the responsibility to the incorrect people. A large company like NVIDIA would have no problem supporting Linux in a more meaningful way than today, it really only depends on what they want. Their unwillingness to play by the rules might worked before, but now that AMD has become a true alternative Im not so sure their strange strategy will stand for much longer.

  13. In a laptop where both an Nvidia gpu and the integrated Intel graphics card are present:
    – can wayland run on the Intel one?
    – can a game run on the Nvidia one e.g. with xwayland if it will support eglstreams in the future (while kwin is running on the Intel one)?

    Just out of curiosity, to understand how dual gpu configurations work in this situation.

    1. Honestly I don’t know. I have never really looked into multi gpu systems. I myself find them stupid and due to that don’t have such a system. What I’m quite certain is that it is not possible to have some apps run on the nvidia and others on the intel. That would probably be possible if everything uses gbm, but in mixed. Doubt that will be possible.

      1. Thanks for the answer.

        If you want a dedicated GPU on a laptop, you will necessarily have a dual GPU system given that all the Intel processors have an integrated GPU nowadays.

    2. *In general* it should be possible. DRI_PRIME allows to offload graphics workload to another GPU, and then, as I understand, every rendered picture gets swapped to the GPU driving the display, which in turn decides what to do with it.

      However, your specific case of mixing Mesa and NVidia Proprietary driver might be complicated, I don’t know how do they work together.

  14. Nvidia sucks, hands down. But I’d also like to remind people that AMD is not exactly Linux-/customer-friendly in general and has a long list of disappointments.
    Sure, we can start up a wayland session and we have great Mesa GL drivers nowadays. But there is still no usable OpenCL driver at all. There is no usable Vulkan driver from AMD. They announced their plans for offering both as free software two years ago. What happened in the meantime is that we’ve got a community radv Vulkan implementation. OpenCL is supported via the unusable ROCm stack. They claimed they’ll improve the launch support for products, but months after release their high end Vega product can’t still output to a display with upstream drivers. Features like Free-/Adaptive Sync are still missing.

    And then there’s their CPU department. Great comeback with zen but requiring hostile, untrustworthy crap like the PSP backdoor. And they don’t give a shit that thousands complain.

    I don’t blame their devs, they’re doing great. I blame the management for bad resource allocation and wasted opportunities. Nvidia is doing absurdly bad with their drivers, Intel is doing absurdly bad with the ME and they have no intention in filling this void.

  15. As an NVIDIA hardware user i’m very happy with an outstanding hardware support on Linux that NVIDIA had provided for years. And i’m very unhappy about weston/wayland/whatever developers breaking compatibility and leaving me with a pricey but worthless hardware that worked just fine a minute ago.

    Generally i want Linux to run on my hardware. If Linux can not do that – i’ll opt-out of Linux, if wayland can’t do that – i’ll stay on X11. GNOME understands that and does stuff for NVIDIA drivers, (thought i’m still not switching anywhere soon). I don’t need wayland or weston, or kwin or plasma or whatever, i need Blender and Chrome, i also need a decent DE to work in, but applications are more important. Isn’t that obvious?

    Now, the next lines i’ll be writing are not an attack. I’ll just leave it here hopefully to help you understand the situation you are in which you are seemingly struggling to comprehend. Just throwing it out there, alright?

    Your demands or “requirements” to hardware manufacturers means nothing. I’ve read your last year’s blog post and its outcome after a year has passed is pretty natural. You’re also not in position to demand anything from Linux users. RedHat could execute their market power to some extent and force something onto RedHat Linux users, but you don’t. No offense.

    When it comes to executing market power, GNOME will support NVIDIA sooner or later, then they will ditch KDE like they did to Unity. Remember Unity? I know that you are probably hate Unity for compiz, X11, patches to GTK, and Mir, and all that “crap”. But consider yourself in their shoes for a moment.

    I think you’re next in line. Google “divide and conquer”. Be careful and good luck.

Comments are closed.