Besides the likes of Red Hat, Intel has been the only other major organization in recent time willing to devote resources to areas like X.Org release management, but even while they let go some of their Wayland folks years ago, they seem uninterested in devoting much in the way of the X.Org Server advancements as we approach 2021. With Ubuntu 21.04 also possibly defaulting to Wayland for its GNOME session, the KDE Wayland support getting squared away, and other advancements continuing, X.Org Server 1.21 may very well prove to be an elusive release.
The transition to Wayland is taking far longer than it should, and a lot of important software simply isn’t ready yet. KDE is still hard at work, and my desktop environment of choice – Cinnamon – has zero support in the works for Wayland. Don’t get me wrong – I’m excited for Wayland – but it feels like we’re counting down by continually multiplying by 0.5 – no matter how many times you multiply, you never quite reach zero.
Sooner or later, Wayland will be almost feature complete and almost supported by all software and drivers; and when Wayland reaches that stage these people will decide to switch to something else (and abandon Wayland).
Why? Because developers control the direction of the OS; and for developers “new and interesting” always beats “stable and useful (and boring)”. They don’t have accountants screaming about the cost of updating/porting all the other software; they don’t have a marketing department screaming about lost market share that change/breakage causes; and they don’t have “upper management” deciding if/when the benefits of change actually justifies all of the costs.
Some fundamental truths there, Brendan.
I also suppose the idea DEVs make money by DEVing also plays a part. Maintaining stuff is not very profitable for DEVs, although I appreciate it can be very very profitable for a corporation, what little maintaining stuff pays is often spread across very few with most effectively dealt out of the game. So “New and Interesting” is really just a way of dealing yourself back into a game you had already lost or might have been losing!
Will this ever change, I doubt it! Just go into the local hardware store and see how many different flat head screwdrivers you can buy, humanity is addicted to different!
My biggest beef with all this is that humans also conflate different with better, and it’s far from being the case! But I won’t ever win that one, look at Apple!
@cpcf
Think Different. LOL
Don’t forget that Wayland is only a PROTOCOL, not a software, and its most interesting thing is that nearly everything is an extension. This means that it is as extensible as X11, but since everything can be made obsolete, it is even more futureproof than X11 (which is very futureproof, as demonstrated by the extensions that allowed to fully replace the render engine and use composition).
This is very true, and a point that most people forget. But I’m as confused as to why there isn’t a standard implementation that most systems use. With x 11, there was xfree86 then the xorg implementation. Gnome’s is different than KDE’;s If I were just using KDE, I’d have to say wayland is terrible. I was using it years ago and it had some insane usability issues. But at that same time Gnome’s was rock solid. Smoother and better than the xorg backed version. I l;oved kde, but I couldn’t justify still using it.
I’m aware and appreciative of the benefits of wayland vs xorg, but I don’t know enough of the details to understand why those benefits required so many individualized implementations.
There is: Weston. It is the reference implementation, and has several libraries with code to reuse. But as a reference implementation, it is quite simple and maybe ugly… just like X11 without window manager 😀
I don’t know if it’s taking longer than it should. I think people that were watching from a distance thought this would be a quick switch over, but most people that know about this stuff were saying 10 years to get to a pretty usable place. There’s just so much that goes into this type of fundamental switch that it, in hindsight, it should have seemed obvious how long it would take.
Gnome is pretty much there with Wayland and KDE isn’t far behind. Now that the two major desktops are day to day usable under Wayland more and more things will gradually follow. I’ve been impressed with Gnome running Wayland when I’ve used it and it seems every release it gets better and more feature complete.
When I upgrade to Fedora 33 I’ll be interested to try out Gnome 3.38 and see how it feels compared to 3.36 which was already very solid under Wayland.
I suppose I could try proxying my entire desktop through something like Xpra. on top of XWayland. I’ve never had a window manager that could last more than a few weeks without dying or needing a forced restart, and I don’t think I’ve ever seen a compositor last more than two or three weeks of uptime without going bad.
X.org lasts me months without killing whatever I’m working on and I still don’t see any efforts toward adoption of a proper session recovery extension for Wayland..
…in the mean time, I’m working toward making more and more of my desktop weather a failure like that, either by moving to applications with a persistent backend and a separate frontend (eg. the Deluge torrent client can operate in that kind of detached mode) or by writing replacements that operate in that manner or by looking into ways to use things like Xpra to achieve that.
It’s horror stories like this that keep me away from Desktop Linux BTW. I ‘ve been hearing “Wayland is coming” for the last 8 years (first stable was released in 2012), and in the meantime development time is split between X.org and Wayland (as if there wasn’t enough developer starvation for anything Desktop-related on Linux).
Compare and contrast to Windows, where Microsoft released WDDM and immediately every GPU vendor brought their A-game to support WDDM because it mattered.
I run 100% open-source software on my Windows (LibreOffice, OpenShot, Avidemux, VLC, MPC-HC, Firefox, Meld, WinMerge), with the exception of Nvidia 3D Vision Player, utorrent 2.2 (old habits die hard) and games, but when it comes to OSes, you need a PHB to say “we are going to Wayland in the next release and we will pour enough resources to make it happen, and any IHV who doesn’t follow along will not get their drivers signed”.
If i may suggest you, try usint qbittorrent on Windows 🙂
Have suggested to a lot of friends that are non-techies/Windows users and they are pretty happy with this alternative.
It has all the same features like DHT, LSD, PeX and default tracker lists to all new torrents without all the Adware from uTorrent. GUIs ate pretty simmilar too
I’ve been meaning to ditch uTorrent and was looking for an alternative. I read good things about qbittorrent, and with this endorsement I’ll check it out now.
BTW this is the existential threat for Desktop Linux that lots of people feared would happen: X.org dying and Wayland not having drivers ready (and still being beta itself).
An Nvidia GPU + proprietary drivers is a good way to get good graphics under Nvidia (using X.org obviously) for the person who wants a Unix-like OS on their PC, and it was only semblance of mainstream appeal Desktop Linux had. Things are not going well…
First of all, X is not going anywhere. Even if there were no further releases (there will be, the author of the article is just trying to get some publicity) it is still extremely competitive from the users’ point of view. Yes, it carries some no longer used features but for the most part this has no impact on usability or performance.
My advice is, if you are interested in Linux – try it. There are a lot of things to learn and enjoy. I don’t know what your interests are (it could be display subsystems are your thing) but for most people it doesn’t matter how things work as long they work.
If you were to see Microsoft/Apple “kitchen” you would also see many solutions that were done years ago and no longer receive much attention, and experimental technologies being actively worked on for extensive periods of time. There is no guarantee the new code will ever ship, and except patents and research papers it remains mostly secret. This creates an illusion of an incremental focused development but the reality is very far from it.
One of my interests is 3D stereoscopy (no joke, old-timers here might remember me confessing the fact I have the last 3D Vision laptop ever made -an Alienware 880m- which I daily-drive sometimes), but I will stick to Windows for that particular hobby, don’t worry. Windows 8.1 that is.
What scares me about Desktop Linux is that the community will say “of course it works!” for nearly every type of hardware and then 5 pages later they will mutter something about “software rendering”, “low clocks due to locked firmware with the open-source drivers”, “upgrade breakages with the proprietary Nvidia driver”, which signals to me that their definition of “works” is vastly different than the mainstream definition of works, for both the open and closed driver. If all you want is an Intel iGPU to use as a display adapter, I guess it’s fine (although I don’t rule out the possibility of issues there that I wasn’t told about, such as issues with power management or v-sync that Desktop Linux always seems to have with non-Nvidia GPUs). But anyway, when you’ve paid for performance hardware, you can’t run an OS that makes a display adapter out of it. And no, I won’t install Desktop Linux just so I can see how cool the icons are, been there, done that.
But Xorg works, doesn’t it? Most issues Wayland was trying to solve are already implemented in X via direct rendering. Just use it. Even when/if Wayland is ready Xorg will still be maintained because too many important applications depend on it.
Wayland may be coming, may be not. It is still experimental software and we only hear about it so much is because it is being developed in the open. If it was a commercial product you would at most read about it in a blog post. Definitely not install it on your production system. Not before it reaches feature parity with a system it replaces and not before it gains adoption of 3rd party vendors, and even then the whole thing can be scrapped and never see the light of day. Do you remember that database based file system that was supposed to come in Windows Vista?
Maybe the problem is nVidia using a proprietary protocol (GBM) for buffers instead of following the standard (EGLStreams). But even in that case, Gnome Shell DOES support nVidia in Wayland.
Huh? Wasn’t it nvidia with EGLStreams and Mesa with GBM? Though truth to be told EGLStreams as official standard have been around for a couple of years before GBM have been publicized.
Yes, you are right. I should re-read what I write before posting O:-)
So, does Nvidia work under Wayland?
Clarification: with proprietary drivers and acceleration. The open-source “Nouveau” drivers not only aren’t that good but can’t even re-clock the GPU to it’s rated/advertised clocks (all Nvidia GPUs start at a low/power-saving clock and then the driver -in co-operation with some proprietary firmware- re-clocks them to the rated/advertised clocks). The open-source “Nouveau” driver doesn’t do that at all after Kepler and does it only as an experiment on Kepler and earlier.
As I said, Wayland is only a protocol, not a program, so it doesn’t matter. Gnome Shell under Wayland does support nVidia privative drivers, but thanks to the work of the Gnome programmers that accepted the extra work of maintaining two different code paths.
I looked into that once and, basically, GBM predates EGLStreams but it took a few years for the Mesa developers to realize that nVidia had put EGLStreams forward for de jure standardization in an attempt to deligitimize GBM already being a de facto standard.
Aside from that, if you read the relevant KWin-related blogs, part of the problem with EGLStreams is that it’s like Chrome Extensions to GBM’s XUL extensions and doesn’t provide a way to request some of the guarantees that they configure GBM to provide.
(In essence, part of the reason KDE was reluctant to support it is that it brings back an element of the X11-era “nVidia’s binary driver internals can’t offer everything we want without falling off the fast path”. and standardizing on it would risk pushing that out to other drivers.)
To make clear, EGLStreams is not EGL.
EGLStreams is an official standard proposed and created by Nvidia and ST-Ericsson. It is a standard because no one objected. There are many “small” standards that exist because people had no response to object. It might be useful to someone.
Nvidia is the only consumer of EGLStreams, It is an official standard with one user.
Wayland was a collaboration between wayland devs, Linux kernel, Gnome, KDE, Qt, Intel, AMD, Samsung and others. Nvidia was invited to participate and decided not. All parties agreed on using GBM. It was only until much later that Nvidia suggested everyone adopt EGLStreams. There was a serious discussion with the Wayland devs. In the end, the Wayland devs decided not to start over with EGLStreams.
The Linux desktop is developed and maintained by an army of volunteers. . Some projects do not have the resources to support both EGLStream and GBM. If EGLStreams was a drop in replacement there would not be an issue, but it is not. EGLStreams has its own unique issues and bugs that cannot be reproduced on other hardware or drivers because no one else uses the standard.
I do not even think EGLStreams outside of Nvidia on Windows and MacOS.
Why exactly should Nvidia have participated in that collaboration? Nvidia knows more about high performance graphics than everyone that was involved in the Wayland collaboration. Honestly, it’s better that Nvidia went the way that they decided to go. If Wayland ever actually becomes the default desktop & Nvidia decides to fully support it, Nvidia will still end up producing better drivers than the entire open source community. Why? Because design by committee isn’t always the best way to work. Additionally, why should the highest performer allow themselves to have their hands tied by conforming to what the other developers (who decidedly are NOT the highest performer)?
Cinnamon not supporting Wayland is a Cinnamon issue, not a Wayland one.
It’s indicative of a Wayland issue though: User-friendly distros avoid Wayland like the plague because it isn’t well-supported by drivers, especially Nvidia (which again, is the only way for a mainstream user to get good graphics on Desktop Linux).
Distros I use are user friendly… just picky about their friends 😀
NVidia is the only way to get good graphics on Desktop Linux? WTF?
How is it possible, that Fedora works just fain on the new Thinkpads? Is it because Fedora is not user friendly? :-O
it is funny that Ubuntu, one of the most user-friendly distro, uses Gnome shell, which can work with nVidia in Wayland.
Maybe a bit off topic. But Cinnamon seems to be a memory eater af a day of being active. It terribly slows down my computer and I need to restart the computer. There is no easy way to restart Cinnamon. And that is why I am experimenting with KDE for a while. I am gonna try to install NVIDIA drivers next. Lets see how that goes.
(And I want to have a background spanning my two monitors like in Cinnamon). Lekker belangrijk (as we dutchies would say), but life goals are needed.
Also: the discussion about using linux desktop is not interesting for most of the people bc of Wayland, but bc they have no idea L:inux desktop exist. Only techies can bother about that.
Right-click panel > Troubleshoot > Restart Cinnamon.
Fuck hell. That is easy.
So why do I need KDE anyway. 😉
Does Wayland even work on nVidia? I haven’t been able to get it to work on Pop! OS. And some software like Zoom doesn’t really support Wayland without stipulations.
It actually does, you need to edit gdm settings files though.
Does anyone remember why they started developing Wayland? Last time I’ve checked it, I had problems with redrawing frames in Firefox and D’n’D in Gnome (Archiver->Nautilus).
I think most of the issues with X11 back in the day have been resolved, mostly due to the under-the-hood work (such as kernel-mode drivers and Mesa improvements) which was require to implement Wayland. The X protocol had some shortcomings with supporting VSync properly and sometimes requires tweaking to get it working correctly.
See The Real Story Behind Wayland and X – Daniel Stone (linux.conf.au 2013).
The TL;DR is:
1. Modern,composited X11 setups work by farming out every function in the X server except for “terrible, terrible IPC”. to other processes.
2. Despite resigning themselves to everyone agreeing to break the X spec in the same way to fix various things over the years, for things like being able to use media control buttons while the screen way locked, “We tried. It would break the X spec too badly.”
Hoping this is a “dream exaggeration”. Wayland != X11 neither in form or function.
Is there an all Wayland future? Maybe. But it’s still quite a ways off.
They’re going to make Wayland the future whether you like it or not.
If you dig through the relevant wikis, you’ll find admissions that Wayland is X12, created by the X11 maintainers… they just don’t call it X12 because they didn’t want people up in arms that X12 looks nothing like X11.
From their perspective, continuing to maintain X11 is like being forced to maintain some randomly chosen Firefox ESR release in perpetuity in addition to developing the newest version..
I’ve been using Wayland with Gnome Shell for several years, and everything works like a charm.
That’s my concern. From my experience I would never say Gnome Shell works like a charm. Too many arbitrary Gnome-only design decisions, poor interopebility with KDE and X11 apps, too many features removed.
Poor interoperability with X11 apps in Gnome Shell?
Also, of course I add a ton of extensions to adapt it to my taste (even I wrote several).
Yes.
Gnome Shell may work for you just like some game engines work for me – they support a subset of features they were designed for. The only difference is the latter don’t pretend to be desktop environments.
A true measure of compatibility is running X/Gnome3/KDE applications on any of Weston/Gnome Shell/KDE Wayland/… compositors and having all features work across them. Copy/paste, screenshot, screen capture/screen sharing, screensaver, window decorations and operations, notifications, multimedia/3d acceleration, video and input device drivers, support for multiple screens, screen rotation/dpi/hdr/adaptive frame rate, etc. Some features are part of the Wayland spec and need to be implemented in compositors, some are Gnome-only fixes, and the rest is simply swept under the carpet.
I generally wouldn’t trust Michael Larabel as a reliable source of under-the-hood or development news. At best he’s good at reporting new processors on the market.
X11 isn’t really abandonware in the sense that no one is supporting it. There are still pretty regular bugfixes being added to it (see https://gitlab.freedesktop.org/xorg/xserver ), and in particular GLX commands are still added when drivers support new OpenGL extensions.
Is there a certain threshold of commits before it’s “active”? I would hope that, with the protocol and implementation becoming very stable from decades of development, it wouldn’t take absolutely constant (IE, daily) development work to maintain XOrg.
Wayland just feels like people want it because it’s new and shiny. As time goes on, it keeps getting more and more of the cruft that X11 was blasted for. Almost as if to be featureful, a certain amount of machinery is really needed.
It’s more that there’s no release manager, so it’s looking like it’s stuck in a DOSBox-like state where the last released version is ancient and anyone who needs more can build a nightly.
I am also a bit disappointed in Wayland. An unfulfilled promise that’s now more than 10 years old. It was conceived to be a clean replacement for X11 which has more lines of code than the kernel itself. But it has only caused pain, And we will lose the most important feature of X11, network tranparancy. Which in the world of ultra fast internet, is quite an important feature.
I wish they took the X11 protocol and made an X12 version which would address the problematic code base in a better way rather than allowing ‘client side decorations’.
I don’t like that the Wayland extension for floating window management makes server-side decorations optional, but Wayland is designed for more than just desktops.
It makes no sense to hack around elements of a desktop windowing paradigm being required for situations where Wayland is already seeing use, like In-Vehicle Infotainment consoles and Sailfish-based smartphones.
Wayland IS “X12”. What happens is that today, that network transparency makes no sense because we paint everything in the application instead of doing it in the server, which means that you must send the whole window bitmap over and over again, so other methods like VNC are much more efficient. In the old days the widget library sent high-level commands like “paint a line here”, “fill this rectangle/triangle/whatever with this color”, “write this text with this font that you already have in the X server here”… but today all that work is done by the application, and a whole “bitmap” is sent to the X server using shared memory. If you want to use a remote session, you can’t use shared memory, which means sending bitmaps over and over again over the network… which is exactly what VNC or Teamviewer already does, but with greater efficiency because they can send “blurred, quick versions” of the picture, and then refine them when the network is slow.
Network transparency outside corporate LANs is pretty much dead. Modern X11 no longer supports it (in theory it does but it only works well wit old apps, that use server side rendering, no multimedia or 3d). Even if an application runs it is going to perform very poorly.
We use network transparency all the time for CAD software but that’s not your typical home deployment and for performance and security reasons we don’t use X11 for remote access.
At the same time, Wayland is definitely NOT X12 as it is not an upgrade to X11, so don’t worry about the future of the latter. It is a different product for different applications. Maybe my laptop will run it someday (or maybe not) but for sure it is not going to be used in my corporate network running all the commercial production tools.
At this point, I think it’s time for the entire tech industry to admit a few things, in terms of Unix-based/Unix-like systems & graphics:
1. Trying to share a common graphics stack between the various *nix systems doesn’t really work very well. Inevitably, the development will become monopolized by one community, causing breakage & feature-lacking on the other platforms.
2. Canonical was right to pursue Mir in the fashion that they decided to pursue it.
3. The rest of the industry was wrong to lambaste Canonical over the initial closed development of Mir -too many chefs will ruin the soup. They were also wrong to withdraw their support of Mir by reversing their decision to provide graphic drivers for it.
4. Nvidia was right about EGLStream.
5. Mark Thomas’s Y Window System should have been given a thorough assessment by the industry as a successor to the X Window System.
6. There have been many other display systems that we conceived long before the Wayland protocol that should’ve been further developed. This could have resulted in a replacement display system already being fully functional & deployed by now.
As is the nature of such things, I’m sure that there’re many who would disagree with me on some or all of these points.
“6. There have been many other display systems that we conceived long before the Wayland protocol that should’ve been further developed. This could have resulted in a replacement display system already being fully functional & deployed by now.”
*** EDIT ***
6. There have been many other display systems that *were* conceived long before the Wayland protocol that should’ve been further developed. This could have resulted in a replacement display system already being fully functional & deployed by now.
3. Canonical wasn’t lambasted for NIHing Wayland. They were lambasted for making outright false claims about Wayland’s shortcomings to justify the use of their in-house protocol for Mir instead of using Wayland as the compositor-to-application protocol and writing extensions. (ie. They were lambasted for making Mir yet another attempt to capture the ecosystem with something only they had the right to sell proprietary licenses to.)
4. EGLStreams isn’t superior to GBM… it just allows the compositor less ability to dictate how the hardware should be configured, making implementing KWin on top of it sort of like the ugly hacks Chrome extensions had to use in the early days because the API didn’t provide for the correct solution.
“3. Canonical wasn’t lambasted for NIHing Wayland. They were lambasted for making outright false claims about Wayland’s shortcomings to justify the use of their in-house protocol for Mir instead of using Wayland as the compositor-to-application protocol and writing extensions. (ie. They were lambasted for making Mir yet another attempt to capture the ecosystem with something only they had the right to sell proprietary licenses to.)”
Back while all of this was happening, I read both sides. Canonical had reasons that they no longer wanted to use Wayland. The Wayland team said that those reasons weren’t valid because they were lies. At that point, I considered the whole situation to be a “your word against mine” situation, because the Wayland team’s argument didn’t convince me that Canonical was lying about them. Additionally, the bottom line is that Wayland didn’t really provide what Canonical actually needed. Now that so many years has passed, I’m more inclined to believe that Canonical was right. In addition to that, it seems that this is the perfect time for all other *nix platforms to break away & develop their own display system, because Wayland will most certainly be a pain for every *nix platform that isn’t Linux -and that’s if a fully functional Wayland implementation is ever even completed.
“4. EGLStreams isn’t superior to GBM… it just allows the compositor less ability to dictate how the hardware should be configured, making implementing KWin on top of it sort of like the ugly hacks Chrome extensions had to use in the early days because the API didn’t provide for the correct solution.”
I think I’ll take the word of a company who creates some of the world’s most high performant GPUs over everyone else on this particular subject. To date, there isn’t a single Mesa (or otherwise opensource) GPU driver that comes anywhere near the performance of Nvidia’s drivers.
Nvidia’s drivers literally cripple your monitor’s color gamut on Linux. I replaced an old Nvidia card with an RX580 and have generally been much happier with performance.
demetrioussharpe,
While I concur that nvidia’s drivers are far more performant than the open source drivers, we’ve got to be extremely careful drawing conclusions based on that. Domant companies sometimes play tricks to make it seem like others are at fault for apparent shortcomings, but it’s not always as it seems.
Consider microsoft deliberately writing code to break competing products even though they were compatible. Or the intel compiler & libaries intentionally taking inefficient code paths on AMD CPUs to make AMD’s CPUs perform worse running the same code. Nvidia may or may not be that devious, but they could be guilty of omitting crucial hardware programming specs such that the FOSS developers won’t be able to take advantage of full performance of the hardware.
The point being performance deficits may have little to do with merits, skills, and qualifications of FOSS developers. I don’t think we can automatically take the word of companies without due diligence.
I think you’ve missed my point. The guy claimed that GBM is superior to EGLStream. However, the most high performance GPU manufacturer in existence today wanted to go with EGLStream. Clearly, I’m going to take their word about EGLStream being better than GBM than some guy who isn’t making the most high performance GPUs or some open source community who’s drivers haven’t ever been the most high performance drivers. Lets be clear, while its great that Mesa drivers exist, no one can say that they’re truly better than what GPU manufacturers can produce. So, if the most performant GPU developer wants to use EGLStream, then it might be a good idea to listen to them & follow suit, instead of coming up with bs stories about GBM being better. Luckily, they DO produce proprietary drivers, because there’s never going to be a point where open source drivers for Nvidia GPUs will reach the performance level of Nvidia’s drivers.
In reply to demetrioussharpe:
I claimed that EGLStreams is a more locked down API which, like with VSync on X11, forces you to live with quirks of the nVidia binary driver’s internal architecture.
I believe I read it in one of these two discussions:
https://lists.freedesktop.org/archives/wayland-devel/2016-March/027577.html
https://dri.freedesktop.org/~cbrill/dri-log/?channel=wayland&highlight_names=&date=2019-02-21#t-1155
demetrioussharpe,
With all due respect, your paragraph shows that you’re kind of missing my point. You are using the fact that nvidia has the fastest drivers for it’s own proprietary hardware to make conclusions about the merits of two projects that don’t necessarily follow from that fact.
I don’t have enough hands-on experience to objectively say what project is best, however my comment to you wasn’t about that. It was about your methodology for defending one over the other. Your methodology is flawed and I gave other examples to highlight why it’s flawed. The fact that nvidia has the fastest drivers for it’s own hardware is not surprising and does not prove in any factual sense that another project couldn’t perform just as well or even better with the inside information that nvidia has about it’s own hardware.
If you want to bet on nvidia because they control the proprietary hardware and software, that makes sense to me. But this is not the same as concluding their developers or projects are better since that’s a tangential point.
From reading everything that’s been posted in the links, including all of the related emails, it doesn’t seem as though EGLStreams were actually a vendor lockin API. It seems that open source developers were fishing for leverage to gain more information about how Nvidia were using the API in order to better understand how to improve open source drivers on Nvidia hardware. The fact that Nvidia had it working shows that any vendor could use the API & still keep their IP shielded in an opaque box.
@Alfman you’re further missing my point about performance. My point isn’t simply that Nvidia’s drivers are better on their own hardware. My point is that Nvidia drivers on Nvidia hardware out perform other vendor’s drivers on their own hardware. Intel has some very talented people. However, at no point would I take their view over Nvidia’s, because Intel drivers on Intel hardware still come nowhere near the performance of Nvidia’s drivers on Nvidia hardware. My point is that Nvidia has already proven that they’re more capable of creating a better software/hardware tech stack for graphics. So, I’d be more inclined to take their opinion as being the better route -unless you can show me where any other vendor that’s working on Wayland has a better performing tech stack. Because at this point, the company with the better tech stack might be the one to listen to.
demetrioussharpe,
Well what can I say, you are still resorting to a logical fallacy. You are judging X to be true based on Y without providing any evidence for Y to necessitate X. In this specific case the fact that intel doesn’t have GPU hardware that competes with nvidia GPUs is not in and of itself proof that nvidia beats intel at software.
I’m really not trying to change your mind about which is better, you’ve already made up your mind. Nevertheless your logic hinges on assumptions that may or may not be true. Unless you want to resort to bias, logically you must admit there’s a possibility that non-nvidia developers could be better at software components and still end up being disadvantaged because nvidia’s developers have deeper access to sophisticated hardware & programming specs.
> I think I’ll take the word of a company who creates some of the world’s most high performant GPUs over everyone else on this particular subject. To date, there isn’t a single Mesa (or otherwise opensource) GPU driver that comes anywhere near the performance of Nvidia’s drivers.
There are a few major mistakes here.
https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Generic-Allocator-2019
Nouveau in mesa is in fact one of Nvidia own drivers. Before Nvidia locks out firmware access the Nouveau driver use to be inside 90 percent of the performance of the Nvidia closed source driver. Same Nvidia chipsets today that don’t have have the firmware restriction Nouveau driver is faster than the Nvidia closed source driver for them(yes the cards are still made)
When Nvidia switch to signed firmware on the cards they also added code 43 to their windows drivers and equal error to their Linux binary drivers for their consumer cards when you use them in pass-though. So unless you know what you are doing you are not using consumer cards with VM passthrough.
Please note Nouveau is a GBM driver its developed for the embedded arm based Nvidia boards where performance is quite critical. The reality here is the Nvidia has been making GBM drivers. If EGLStreams is truly better why has Nvidia not implemented it in Nouveau for their embedded devices as well.
> Luckily, they DO produce proprietary drivers, because there’s never going to be a point where open source drivers for Nvidia GPUs will reach the performance level of Nvidia’s drivers.
This is also not true. If you go back to the old Nvidia chipsets where Nouveau can in fact run power management the Nouveau driver is faster than the new closed source Nvidia drivers for the same card. These cards are still made for marketing displays and so on. There is a high odds that the reason why Nouveau mesa driver does not perform with modern Nvidia cards is purely due to Nvidia crippling access to signed firmware.
The issue is not being able to get high end cards that have been open source driver stack compatible really to duke it out. New AMD cards and future Intel cards could change this in a big way.
Nvidia like it or not has been total ass with firmware access. Do take note of that generic allocator from 2019 this was basically taking the best bits Nvidia was getting from EGLStream and porting it to a GBM solution. When GBM is the best ideas of GBM and the best ideas of EGLStreams so GBM is the better solution in a lot of ways.
What is Nvidia biggest problems with GBM.
1) Open source kernel code required.
2) No driver based market separation.(as in no more code 43 errors or the like)
Yes some of the reason why early wayland compositor developers were not highly interested in a EGLStream support is when you know Nvidia is already making a GBM driver why are they spitting their driver development team in two. So were hoping by applying pressure that Nvidia would simple just get behind their GBM driver and make everyone life simpler. Of course that underestimates how much Nvidia wants to market split to make money.
Nouveau isn’t one of Nvidia’s drivers. They merely used the Nouveau driver as an open source vehicle to work on a memory allocator that they intend to share. As for access to firmware, Nvidia has always maintained the position of keeping proprietary details secret. Old cards? Sure, the Nouveau driver eventually caught up to the performance of Nvidia drivers that were no longer being maintained, but there’s never been a point in time where the Nouveau has been a better driver than the current Nvidia driver of that time. As for why Nvidia split their driver team in two, have you ever considered the idea that maybe they wanted to do a test to see just how far GBM could be extended in order to bring it up to speeds with their proprietary driver without completely stopping work on their proprietary driver (which is already known to be highest performing driver for their hardware)?
demetrioussharpe
https://github.com/NVIDIA/tegra-nouveau-rootfs
Tegra chips don’t have a closed source driver from Nvidia any more.
https://www.phoronix.com/scan.php?page=news_item&px=MTA4NjA
Nouveau is the Nvidia Tegra platforms 3d acceleratered driver, Because it is in fact faster than the old closed source options.
>As for why Nvidia split their driver team in two, have you ever considered the idea that maybe they wanted to do a test to see just how far GBM could be extended in order to bring it up to speeds with their proprietary driver without completely stopping work on their proprietary driver (which is already known to be highest performing driver for their hardware)?
That is not the story. On arm platforms Nvidia dropped their closed source binary driver in the bin in 2013 because the open source driver was the highest performing item as well as allowing vendors to pass government audits of products due to having full source code. Yes the arm platform driver is GBM.
Please note arm platforms being soc chips Nvidia don’t have the market separation problem.
Nvidia works on Nouveau because they need it for their arm platforms. Then Nvidia cripples Nouveau by not providing the signed firmware to activate the cards power management to allow the card to move off base clocks.
Of course if lets say you want to run Nouveau fairly against Nvidia binary driver on x86 you need to go in and lock the gpu on its slowest clockspeed for both drivers. Then you find something horrible that the Nvidia binary driver is not fast there are areas where Nouveau is faster. The reality is why is Nouveau the recommend and support driver by Nvidia for Tegra platforms is that it performs well. Why is Nouveau not the supported driver for x86 platforms simple it will screw up their market separation.