The announcement of KDE Neon dev/unstable switching to Wayland by default raised quite a few worried comments as NVIDIA’s proprietary driver is not supported. One thing should be clear: we won’t break any setups. We will make sure that X11 is selected by default if the given hardware setup does not support Wayland. Nevertheless I think that the amount of questions show that I should discuss this in more detail.
NVIDIA does support Wayland – kind-of. The solution they came up with is not compatible to any existing Wayland compositor and requires patches to make it work. For the reference implementation Weston there are patches provided by NVIDIA, but those have not been integrated yet. 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.
The solution NVIDIA came up with requires different code paths. This is unfortunate as it would require driver specific adjustments and driver specific code paths. This is bad for everybody involved. For us developers, for the driver developers and most importantly for our users. It means that we developers have to spend time on implementing and maintaining a solution for one driver – time which could be spent on fixing bugs instead. We could do such an effort for one driver, but once it goes to every driver requiring adjustment it gets not manageable.
But also adjustments for one driver are problematic. The latest NVIDIA driver caused a regression in KWin. On Quadro hardware (other hardware seems to be not affected) our shader self test fails which results in compositing disabled. If one removes the shader self test everything works fine, though. I assume that there is a bug in KWin’s rendering of the self test which is triggered only with this driver. But as I don’t have such hardware I cannot verify. Yes, I did pass multiple patches for investigating and trying to fix it to a colleague with such hardware. No, please don’t donate me hardware.
In the end, after spending more than half a day on it, we had to do the worst option which is to add a driver and hardware specific check to disable the self test and ship it with the 5.7.5 release. It’s super problematic for the code maintainability to add such checks. We are hiding a bug and we cannot investigate it. We are now stuck with an implementation where we will never be able to say “we can remove that again”. Driver specific workarounds tend to stick around. E.g. we have such a check:
// Broken on Intel chips with Mesa 9.1 - BUG 313613
if (gl->driver() == Driver_Intel && gl->mesaVersion() >= kVersionNumber(9, 1) && gl->mesaVersion() < kVersionNumber(9, 2))
return;
It's nowadays absolutely pointless to have such code around as nobody is using such a Mesa version. But the code is still there, makes it more complex and has a maintenance cost. This is why driver specific implementations are bad and is nothing we want in our code base.
People asked to be pragmatic, because NVIDIA is so important. I am absolutely pragmatic here: we don't have the resources to develop and maintain an NVIDIA specific implementation on Wayland.
Also some people complained that this is unfair because we do have an implementation for (proprietary) Android drivers. I need to point out that this does not compare at all.
First of all our Android implementation is not specific for a proprietary driver. It is written for the open source hwcomposer interface exposed through libhybris. All of that is open source. The fact that the actual driver might be proprietary is nothing we like, but also not relevant for our implementation.
In addition the implementation is encapsulated in a platform plugin and significantly reduced in functionality (only one screen, no cursor, etc.). This is something we would not be able to do for NVIDIA (you would want multi-screen, right?).
For NVIDIA we would have to add a deviation into the DRM platform plugin to create the OpenGL context in a different way. This is something our architecture does not support and was not created for. The general idea is that if creating the GBM based context fails, KWin will terminate. Adding support there for a different way to get an OpenGL context up and running would result in lots of added complexity in a very important code path. We have to ensure that KWin terminates if OpenGL fails. At the same time we have to make sure that llvmpipe is not picked if NVIDIA hardware is used. This would be a horrible mess to maintain - especially if developers are not able to test this without huge effort.
From what I understand from the patch set it would also require to significantly change the presenting of a frame on an output and by that also turn our lower level code more complex. This code is currently able to serve both our OpenGL and our QPainter based compositor, but wouldn't allow to support NVIDIA's implementation. Adding changes there would hinder us in future development of the platform plugin. This is an important area we are working on and KWin 5.8 contains a new additional implementation making use of atomic mode settings. We want to have atomic mode settings used everywhere in the stack to have every frame perfect. NVIDIA's implementation would make that difficult.
EGLStreams bring another disadvantage as the code to bind a buffer (what a window renders) to a texture (what the compositor needs to render) would need changes. Binding the buffer is currently performed by KWin core and not part of the plugin infrastructure. Given that new additional code would also be needed there. We don't need that for any other platform we currently support. E.g. for hwcomposer on Andrid libhybris takes care of allowing us to use EGL the same way as on any other platform. I absolutely do not understand why changes would be needed there. Existing code shows that it can be done differently. And here we see again why I think the situation with EGLStream does not compare at all to supporting hwcomposer.
Overall we are not thrilled by the prospect of two competing implementations. We do hope that at XDC the discussions will have a positive end and that there will be only one implementation. I don't care which one, I don't care whether one is better as the other. What I care about is only requiring one code path, the possibility to test with free drivers (Mesa) and the support for atomic mode settings. Ideally I would also prefer to not have to adjust existing code.
I find it odd that the Linux community is abhorrent to nvidia EGLStream solution. When NVIDIA finally does something right and makes an open standard instead of something platform specific that may not even perform as well as EGLStream solution. IMHO everyone should just adopt EGLStreams. Linux platform specific solutions to graphics drivers dont perform that well and are not open standards. EGLStreams makes things easier on graphics drivers thus developers to make cross platform code as well.
I think it’s not odd. I don’t know about the possible advantages of EGLStream over GBM, that you mention. But this also isn’t the point of this blog post.
The point is, that GBM was first and EGLStream was late to the party (or atleast its advantages weren’t clearly communicated to the Wayland/Weston developers early on). So GBM is already used solely in the Weston compositor and in other ones like KWin.
Changing that would need additional work, and because of that, there should be clear advantages and not just the commitment of one specific vendor, even if it is used by the majority of users. And atleast I haven’t read about possible advantages before. Also I would trust the Weston developers in this regard.
But most certainly there shouldn’t be multiple solutions for the same problem by different vendors, then needing multiple code paths for the same functionality in the compositor code as a result.
I think Martin clearly stated in the above blog post, that these are his concerns and not adopting open sourced Nvidia standards in general.
[Just to be on the safe side: nothing in the following post is meant as a personal attack! I’m merely going after the “superiority” claim and Nvidia’s insistence on EGLStreams.]
Have you read the thread at ? Because just reading that thread makes your claim of superiority for EGLStreams seem a bit, let’s be generous, far fetched. Many respected FLOSS developers had serious concerns (which, btw, where raised even before code started appearing, after Nvidia first talked about their intentions) and the issue is again, that while Nvidia did open-source this in the end, they developed it behind closed doors, threw it over the fence and expected that everyone else would switch to their solution.
So, from my POV it looks more like: Nvidia had either a solution cooked up without checking what already existed (very unlikely), they knew there was a different solution but didn’t care or they noticed that the solution already in place doesn’t work with their hardware/driver stack (maybe technical, maybe legal reasons, who knows).
And that’s something that rarely flies in the FLOSS space. I can understand that this might be annoying if you bought a Nvidia GPU, but lets face it: you knew you were dependant on their closed source drivers with all the trouble this can cause (and had caused in the past). Now you can either hope Nvidia is providing you with a closed-source stack that works for you (eg. a KWin platform plugin that abstracts this all away, if that should be possible) or you’re out of luck (like in the past, when support for a GPU was cancelled out of the main driver and now you had to decide if you wanted that kernel/X/etc. update or rather stick with you’re GPU, because updates for the legacy drivers were irregular at best (no idea if this is better these days, I haven’t owned a Nvidia GPU in a long time since AMD started doing FLOSS drivers in earnest, but you probably get what I mean).
My only recommendation to Linux users is this: buy a GPU where the driver is available in source form and just “keeps working”. Doesn’t matter if it’s the Intel IGP or a discrete AMD GPU, in either case you can run a wide range of GPUs (including pretty old ones) and still get improvements. Plus these drivers tend to just work “out of the box” with most distributions. (And in case something is broken, it usually only takes a couple of days for a fix to materialise after a bug is reported. At least that has been my experience so far with an AMD GPU, current Kernel and Mesa/LLVM.)
Ahrg, the URL to the thread went missing, let’s try again: https://lists.freedesktop.org/archives/wayland-devel/2016-March/thread.html#27547
This is only useful advice if a product is available for linux with open source drivers which is stability / performance / featurewise competitive with nVidia’s offerings. Currently this simply isn’t the case for a lot of users.
For me one of three things will probably happen.
1) Somebody produces a driver which is a functional replacement for the nVidia card in my system that has open source drivers and I move to Wayland.
2) KWin allows for nVidia drivers on Wayland and I move to Wayland.
3) I stay on X
Great post. Explains all the questions really well. I appreciate the time you spent to write such great summary.
Well, I am not really concerned about all this NVidia / Wayland topic yet, and since I don’t know advantages / disadvantages of GBM/EGLStreams, I do not care – there are other people who can judge this better.
As NVidia guys will be present at this years XDG (don’t remember where I read that, but I’m sure I did), I hope they’ll come up with a good solution for the issue. I just don’t understand why NVidia went another direction than anyone else – but they’ll have their reasons.
XDG didn’t start yet, and I think it’s in good hands with the X/Wayland and NVidia guys.
Of course you wouldn’t like to switch platform now – I doubt anyone with a working GBM implementation would be excited of having to implement another code path.
Wait and see. I doubt NVidia guys want a driver nobody supports, and I doubt that the Wayland/Weston guys want to miss out NVidia proprietary completely. So we’ll hopefully see a solution sooner or later.
I see no real need to switch to Wayland “right now” for anyone (except early adopters). We did live with X11/Xorg for a long time now, and with all it’s quirks – it works, and it works well. Walyand is no question exciting, and we’re all looking forward to when we can use it, but a few month or year longer with X won’t kill anyone. And in a way, we’ll still have X11 then with XWayland.
Why Nvidia went a different way is easy to answer: their driver is the same on Linux, Windows, Solaris and BSD. And they can’t use GBM on Windows. Basically they did what Martin is doing here: chose the solution that required them to maintain a single code path.
To my understand NVIDIA’s driver is close-sourced. I honestly doubt that you can know whether their driver could or could not support GBM or requires EGLStream without reading the source code.
This is their primary argument when they come and push for it at XDG. It’s that doing GBM would be very difficult for them while EGLStreams fits naturally into their driver architecture. I don’t think they’d spend all this effort complaining about GBM if it weren’t genuinely difficult for them to implement.
Well, going eglstreams way – everybody does a lot of work. Going GBM – only Nvidia does a lot of work. Alternatively Nvidia could go the way of the AMD proprietary driver and have an open source kernel driver (using GBM). Also a lot of work but once done the future will be easier for everybody.
Would this have permanent ramifications on Nvidia performance? I’m assuming you mean the proprietary driver would continue to use EGLSteams, and the kernel driver would “adapt” it into a GBM interface.
Martin is asking that Wayland ether use EGLStreams or GBM. Martin is asking for one code path. I do not think anyone working on Wayland wants to deal with two code paths.
He would prefer sticking with GBM, because that is already being implemented into Kwin.
Well, it’s software and, in theory, you can do anything.
But since there’s no GBM on Windows, Nvidia would be presented with the very problem you have right now: they’d end up with two code paths to maintain.
On the other hand you’re right, I don’t know their code, I’m only assuming they’re doing something similar on Windows that can’t be implemented over GBM.
Even so, it’s that simple:
1. NVidia ending up either rewriting the code to match GBMs, or maintaining two code paths
2. Everyone else doing the same: Weston, KDE, Gnome, Enlightenment; oh and don’t forget clients: GTK, KDE, EFL, SDL, whatever game engines, etc.
In fact, communtity *already* maintaining GBMs for NVidia, it’s the Nouveau project. Perhaps to help themselves NVidia could just help a bit to communtity?
I totally disagree with this. Moving beyond X11 is well overdue. Yes, AIGLX/Compiz allowed X11 to hobble on for another decade, but the situation is dire now.
1. X11 is terrible at handling mixed DPI cases. So if you have a Laptop with a 4K screen and a 1080p external monitor, there’s no good solution for extending the desktop from your internal display to the standard dpi monitor. Some workarounds exist, but they’re a hassle and poorly implemented.
2. X11 wasn’t designed for hybrid/switchable graphics and sucks at it. Laptops have been shipping with hybrid graphics architecture for 8 years and the experience is still miserable for Linux desktop users. The “best” solution still involves restarting your X session.
3. Screen tearing remains a persistent issue. Seriously, just move a window around and watch the artifacts. The Linux desktop is in the stone age with this one.
You are totally off-topic here.
It’s not about KWin not going to support Wayland, it’s KWin (and presumably other Wayland compositors) not going into a huge unecessary refactoring in order to support a single proprietary’s driver-specific solution while every other driver uses GBM just fine currently for Wayland.
So here the blame is on NVIDIA for not only coming very late to the Wayland party but making Wayland compositors having extra development and maintenance just for them.
Were you responding to me? I get the issue about KWin and EGLSteams (more or less). I was responding to STiAT saying that it doesn’t matter right now because wayland is only an “early adopter” issue.
It’s horrible that Nvidia is holding up Wayland adoption by pushing their unique implementation at the 11th hour. Desktop users need Wayland desperately. But at least in my case, it’s not optional to have good discrete graphics. Unfortunately, that means proprietary driver support is necessary. Nvidia’s moves here will definitely make me consider AMD in my next workstation after a decade of Nvidia exclusivity.
To
“The general idea is that if creating the GBM based context fails, KWin will terminate.”
All I can say is that I get a black screen and KWin is not terminating but hanging there (I’d guess KWin terminating would throw me back to SDDM with NVidia proprietary and in VirtualBox which has no Wayland support at all – tested with 5.7.3).
Could that be a bug / should that be reported?
If that’s also the case with Plasma 5.8: yes, that would be a bug and yes please report it then. We have some improvements in 5.8 to handle the startup better and more reliable.
Latest KDE Neon with Wayland and proprietary drivers behave just like that for me: login -> crash -> back to login screen.
So if there’s a problem, it’s not a universal one.
> The solution NVIDIA came up with requires different code paths
Is EGLstream limited to Nvidia? If it’s a standard EGL feature, can it be used for Mesa drivers as well, thus avoiding different code paths?
Yes it’s a standard EGL extension however despite being out for years, nobody besides NVIDIA had any interest in it. Also it doesn’t bring any advantage GBM can’t offer while bringing a lot of synchronisation issues on the other side.
currently it’s NVIDIA specific. As I wrote I don’t care that much which solution as long as there is only one.
That would still require all compositors, tookits and all protocol extensions you want being able to use EGLStreams – not sure about the open source drivers, but for one path I’d suggest they’d need to support this too. Nobody does right now.
NVidia wants EGLStreams hammering on that they couldn’t possibly get out the performane of GBM they could get by EGLStreams. I didn’t understand the details about it, but that’s what it seems to boil down to.
NVidia claims it would be easy and not a lot of work, I have my doubts on that, since not just Martin but GNOME Developers (Jonas, * – there are a lot of other very interesting inputs by Intel and other vendors as well) as well stated that it isn’t that easy, and that Weston isn’t a reference to let’s say .. the grandpas on the block in the segment of window management – which KWin certainly is.
They as well say they don’t see GBM going away anytime soon, so it would boil down to the two complex code pathes (words from the GNOME developer, not from Martin).
Martin probably is very open and often easily read by press due to his blog, but if you just look up the mailing lists you’ll read similar things.
* https://lists.freedesktop.org/archives/wayland-devel/2016-May/028853.html
Just read Daniel Vetters last reply on the thread, which pretty much tells everything:
“It exists and is widely used in shipping open-source systems like CrOS, X,
wayland and whateever else. eglstreams lacks the adoption, both in
compositors and in open source drivers. You could try to fix that by just
writing the eglstreams support for everyone (including mesa drivers and
all the existing compositors people are building), but I don’t see that
happening.”
> eglstreams lacks the adoption, both in compositors and in open source drivers.
OK, thanks for clarifying this. Lack of support in open drivers is the most important point. Not sure if lack of usage in other compositors should bother KWin (or any other compositor which wants to solve this problem), but lack of support in drivers is a hard blocker which will inevitably result in supporting multiple paths, unless that support in drivers will be implemented.
True, if all drivers would support EGLstreams Martin could implement just one codepath with EGLStreams. He probably would not be very happy abdoning the GBM work, but at least he could (if he wants, of course).
For the two codepathes… Martin is right, especially KWIN being a mostly one man show, ressources maintaining, updating and bugfixing a second implementation is not nice.
Besides, what was it about the mir topic.. No vendor specific patches (I know this is not even true at the moment for drivers), but a full code path for one vendor even being as important as nvidia is insane.
I hope Nvidia and Wayland developers will come to some consensus, and either Nvidia will implement GBM, or EGLstreams will be added to all Mesa drivers.
Or they just move the whole thing to Vulkan instead 😉
Moving KWin to Vulkan makes sense as part of huge redesign to parallel rendering, and Martin said he doesn’t plan it at present. Not sure what the analog of EGLstreams / GBM is in WSI / Vulkan realm.
If this situation does not change, either by NVidia or the FLOSS developers, then most gamers on Linux (myself included) would stick to X11 forever.
Gamers on Linux are likely to switch to Polaris and Vega cards, since amdgpu + radeonsi are getting in shape (and will be even better next year). And they work fine with Wayland and KDE. I think gamers should be more concerned about how well gaming experience works out on Wayland in general (like pointer containment and such).
I actually thought about going amd for its new driver setup. But after nvidia is trying to do the right thing and develop an open standard that is far superior to GBM for years i will just stick with nvidia and X11 and live with its quirks. If the linux community wants to kill its desktop market that it gained than so be it.
From the mailing list discussion it doesn’t seem that EGLStream is really superior at all to GBM, not to mention “far superior”. At least there is no consensus that it is. NVidia is claiming it is, but pretty much everyone else seems to disagree.
> an open standard that is far superior to GBM
You didn’t read pros’n’cons, did you?
Martin avoided comparing Streams and GBM just because 1) he’d be involved into a flamewar, and 2) the topic Streams vs GBM was discussed in details
For 2-nd point, you can read this:
https://lists.freedesktop.org/archives/wayland-devel/2016-March/thread.html#27547
I seem to remember there was another discussion, but can’t find the link.
TL;DR: streams are not superior even a bit, they are *at best* equal to GBM. Things are either could not be done in either of them, or could be done in both of them.
GBM devs said themselves they are adding features of EGLStreams. They are basically creating a platform locked clone of an open standard. That is what you get for ignoring NVIDIA when they finally try to do the right thing. So what if many parties have days of extra work to implement an open standard? It may save 10 times the work in the future… because you know, open standard. Ofcourse i do not know the specifics as i am not working on these things. But mentioning these specifics in details is a lot better than a ‘we are too lazy’. Martin mentioned timing but didnt go in too much detail. Seems like more laziness. Wayland will just be a no go for desktops if it keeps up like this and that would be a shame. The irony must be lost on you of me buying nvidia for its open standards. (which is why i wanted to buy a amd gpu for how they are handling the amdgpu/pro drivers)
So how do i start my desktop in wayland on my intel iGPU if nvidia drivers dont work and start my games on my nvidia gpu. Oh wait EGLStreams would make such things much easier. More irony.
> GBM devs said themselves they are adding features of EGLStreams.
> They are basically creating a platform locked clone of an open
> standard. That is what you get for ignoring NVIDIA when they
> finally try to do the right thing.
No. If GBM was a clone, the present discussion woudln’t even happen. Though GLStreams and GBM seem to serve the same purpose, but the concepts very different, just note on the mailing list, how many changes both clients and compositors would have to do. And features you mentioned are being added on demand, but not because “oh, wait, we forgot to implement X!”.
Still, it’s an interesting question why, given they serve the same purpose, GLStreams weren’t choosen from the beginning of Wayland. I can speculate a bit: probably the reasoning involved the fact that nobody has GLStreams implementation at the time (including NVIDIA, if I got it right). So they simply choose the format for which every driver has support (and proprietary ones are off for the simple reason that nobody knows how do they work).
But whatever way that happened, NVIDIA should’ve actively participated in the development, they should’ve creating threads on the list, explaining pros’n’cons of GLStreams back then. What happened instead, is that even now, after Wayland support in the World is almost done, and NVIDIA woke up, they still struggle to show a technical advantage of GLStreams on the mailing list.
> and proprietary ones are off for the simple reason that nobody knows
> how do they work
Though even then, it would be rational to assume that they copied the way that other drivers do. Which is GBM.
Hi Martin,
Doesn’t kwin use the Qt compositor API ? If so, isn’t the GBM vs EGLStreams abstracted by Qt ?
Qt has both EGL/GBM and EGL/EGLStreams integrations
No, KWin does not use QtCompositor API. Also we do not use Qt’s OpenGL abstractions for rendering.
Hello Mr. Graesslin,
It would be great to see an futher view of Wayland Security under KDE Plasma 5.8. For me this is very interesting to see, which possibilities are exist to attack Wayland in many ways. Will Flatpak be supported by KDE Plasma too?