I've stated multiple time that I'm not biblical about open source software and I'll use the proprietary solutions if there is no good open source alternative. However nvidia is a special case(as usual). My laptop has a low end mobile nvidia gpu which is anything but special or demanding(mx250 to be exact). The laptop itself is dual screen(the Asus zenbook duo series) and nouveau worked out of the box, no issues whatsoever. I mean there were some but they were unrelated to the gpu driver. In essence I never really needed to deal with the proprietary drivers. My workstation is a bit different in that regard. The GPU was the one thing in it that I cheaped out on - an oldish quadro model from 2017-18. But again the nouveau drivers worked perfectly and all 3 monitors worked perfectly fine. I did however plan on playing with CUDA a bit and decided to install the proprietary drivers. Big mistake. It took me a whole weekend to recover from the tons and tons of problems that came with them. So in that regard, I think that if a distro offers them out of the box, the chances of wasting so much time in fixing and getting things to work may be a good thing. That said, I'm not entirely sure that forcing people to use a proprietary driver by default in a linux distro is a wise idea. A much better option would be for the users to decide on their own which one they want to use.
What problems did you even run into that would cause you to lose a whole weekend? If we’re dealing with anecdata, I never had an experience that bad even when having to use bumblebee/primusrun/etc on a laptop; my last desktop Linux install was with an RTX 2060 and it was pretty much painless using X.
Also, it’s not defaulting to installing the driver anyways - as described in the article and its sources, what Fedora is actually planning to do is to change GDM’s udev rules to select the Wayland session by default if the proprietary drivers are running.
Pff lost track of it all. Probably 15 things went wrong along the way, some obvious and some very subtle problems, iirc I even recompiled the kernel at one stage. I've read that the newer ones(2060 being among them), the process is far less painful. I just checked and I'm on a Quadro M5000 which is from 2015(I found it dirt cheap so I went with it).
The headline is confusing. The proposal is if you are already using the NVIDIA driver, to default to Wayland instead of Xorg. Previously Xorg was the default with the NVIDIA driver. Non-proprietary drivers should still be the preferred choice for Fedora users, avoiding NVIDIA hardware if at all possible.
>Wayland still reliably caused lockups a few minutes in.
How do you know this (that it was wayland)? I have never had a lockup caused by anything other than swapping, across multiple machines with Intel graphics.
It does sound a lot like GPU hangs and it is hardware specific so it's most likely on the driver side.
I had the exact same issue than you had with my igpu a while back (something like 2 years ago), there was a bug in Intel's driver that was causing gpu hangs.
The strange thing is that it happened on Intel hardware about 10 years apart. From that I deduced it wouldn't be the driver (and it works flawlessly with Xorg), but maybe Intel's GPU change less over time than I assumed.
I think it was earlier this year. I saw some post on HN about Manjaro + Wayland and decided to try it out. In the end I ditched it due to not being able to do screen sharing.
On firefox it works out of the box.
On Slack as well.
On chromium it's still hidden behind the flag: chrome://flags/#enable-webrtc-pipewire-capturer
On Zoom it's more complicated. For whatever reason it uses gnome's private screenshot API to share screen
Now that Gnome secured this API, it's not working at all, even for Gnome users...
The web version allows to share the screen, but their web version is really not great.
I use Intel graphics + Xorg + Fedora 35 and it's all rock-solid. (I doubt Wayland would have been any different in that regard, but I need remote X despite certain people claiming that remote X is a useless appendix that no one still uses).
Does anyone remote their entire desktop via X forwarding? I'm not sure if that is even possible. What would be the advantages over something like Xvnc?
You can still run XOrg with the old XOrg-accelerated intel driver or modesetting atop KMS, so even staying within Intel+XOrg you can have very different rendering paths.
I used to run the XOrg-accelerated stuff as it was faster and used less power on my laptop, but once my machine got new enough for SNA it became too buggy vs. modesetting.
When the pandemic started, Zoom only worked on x.org. They've since added Wayland support but googling for it shows the client is still behind on screen sharing. That may just be a harder problem to solve in Wayland without zoom itself acting as a compositor?
Linux sessions utilizing Wayland can only share an entire desktop or whiteboard. In order to share just a specific application, you will need to launch your Linux session with Xorg instead.
The web-based version of Zoom can do screensharing on Wayland just fine in Mozilla Firefox or Chromium. On Chromium based browsers, you need to turn on PipeWire WebRTC through the chrome flags mechanism (chrome://flags/#enable-webrtc-pipewire-capturer).
The Zoom application needs to be adapted to work through the Wayland screencast portal interface to get things working properly (including sharing audio!). I've tried to report this to Zoom, but I'm not enough for them to realize it's a problem...
If you (or anyone else here reading this) is a Zoom customer, please file support tickets asking for this to be fixed. I gave them all the technical details on how to fix this at the beginning of this year, so they know what they need to do.
Are you a Fedora dev? Do you have an impression that NVIDIA is getting to be a bit more cooperative with the desktop Linux development community these days, like with the changes related to GBM that made this decision possible for Fedora?
Yeah, they definitely are. Though they're still not cooperative enough to make it so NVIDIA hardware has a good basic level of performance with the OSS drivers. :(
While this Change currently describes the effort for GNOME, KDE Plasma is likely to also be ready for Fedora Linux 36 for this. There a couple of other blockers to deal with, but hopefully those are squared away in time...
I am not so sure that GBM support was motivated primarily by the Linux desktop community. It's rather a symptom of industry-wide trends.
I work in the automotive industry, where we buy high-end, high-margin SoC SKUs - not a lot of them (compared to phones, primarily), but enough to have some sway. Within the industry, most OEMs are moving toward inhouse platform-shaped development and have a desire to make their code increasingly reusable and hardware-agnostic, as well as lower integration costs for third-party app content. This drives the adoption of open source commodity stack technologies and standards like Wayland, and means hardware vendors now have to demonstrate or offer support for them - with a single code path. It then replaces vendor-proprietary stuff like nVidia's EGLStreams previously used for similar cross-process compositing use cases as Wayland is now. In the past, vendors were asked to solve the problem for the OEM as they saw fit on their hardware.
I've personally requested vendors to provide GBM support on the Orin SoCs by writing it into requirements. I know nVidia previously started incorporating limited GBM support in their GPGPU product line, probably due to similar customer asks in that industry, but I don't know it well.
For the Linux desktop community the takeway is that it has a massive impact beyond just the Linux desktop - by being a leader in the commodification of technologies everyone just ends up adopting, especially as embedded development trends toward a similar complexity level as desktops and phones with similar feature requirements. Accordingly it deserves support from those who have these technologies in their supply chain.
I've heard a rumor the main reason for Nvidia's reluctance to open source their driver is that they use it to enable/disable features. So the same board can be GeForce or Quadro, depending on what the driver tells it to be. Is this true?
Also I'd be skeptical to some extend on this. Maybe back in time when a chip fail ratio was lower was a case. But now, there is a quite measurable amount of chips not passing requirements for a high tier cards, but can be used in the lower models (with limited amount of cores etc or worse thermal efficiency).
"A developer driver inadvertently included code used for internal development which removes the hash rate limiter on RTX 3060 in some configurations," the company said in a statement. "The driver has been removed."[1]
So it's hard to tell when it's binning, and when it's hobbling.
“It’s not just a driver thing,” said Bryan Del Rizzo, Nvidia’s head of communications, last month. “There is a secure handshake between the driver, the RTX 3060 silicon, and the BIOS (firmware) that prevents removal of the hash rate limiter.”
Probably fairly true. Nvidia tries to differentiate their offerings a LOT with software driven features
I feel a lot of this comes down to them using closed source software that they either don't have the code to, or aren't privileged to distribute. Libraries are a common spot for this to appear
Yeah, so GeForce/Quadro used to be a software only difference. Later on (around Fermi/Kepler) it became a hardware difference but cards could still be modded by means of board straps and package traces.
Kepler could literally have all its cores enabled with a simple bridge on one laser cut. That's fun but very hit or miss, the more cores are disabled the higher the likelihood they're actually defective so it was binned lower.
Maxwell can have their Hwid modded but performance will be lower than actual Quadros.
Newer cards have an even bigger performance difference, more hardware differences I think.
Wouldn't it be fun if NVidia could sell a "firmware upgrade" for your GPU, in this time where GPU prices are through the roof and they cannot supply the market adequately?
Of course, I'd hate that in normal times, but if they now made me an offer to "upgrade" my 1060 (to moderately higher performance, but still lower end), I'd probably take it.
AFAIK there’re only 4 differences between GeForce and Tesla/Grid: more and faster VRAM, more FP64 GFlops on most GPUs, unlimited count of nvenc encoding streams versus 2 on GeForce, and support for virtualization. Only the first two are hardware differences, the other 2 are software.
Another thing about virtualization, it sounds ridiculous but nVidia charges non-trivial per-user fee to allow people to use the hardware they already own. Specifically, for virtual workstation they want $450 per concurrent user. That’s on top of the $3000-$12000 purchase price of these GPUs.
Wow I did not know this. I've been thinking about picking up an Nvidia card to play with vgpu on vsphere - so it sounds like this would be impossible without an additional license fee?! What a bummer.
> fee to allow people to use the hardware they already own.
IBM does that with mainframes, but, at least, it’s hardware they own that they shipped in the box for you to rent out when needed or to buy and enable.
Dumb question: Closed-source doesn't mean encrypted. What stops people from disassembling and reverse-engineering the blob?
Of course, distributing a "cracked" driver would breach licensing agreements and violate copyright (and possibly other laws), so it's out of the question for any kind of professional use. However, if Nvidia uses it to differentiate services, wouldn't there be a significant risk of private consumers (gamers, hobbyists, etc) using such a driver to "upgrade" their cards for personal use?
AFAIK it is both closed source and encrypted. Otherwise we would already have nouveau with black market firmware extracted from the official driver than unlocks power and clock management (something that nouveau can't do, reason why it's so slow to be useless on modern cards)
I’ve been “daily driving” F35 with Wayland on Nvidia for the last couple weeks and it’s been an… OK experience. The only real show stopper for me now is that GNOME night light doesn’t work (Nvidia issue) and screen sharing in some select applications. I’ve worked around the former by setting the color temperature on the monitor itself.
Another big deal is there’s no hardware video decode support in Firefox. I don’t have integrated graphics, so I rely on Nvidia’s VDPAU implementation that doesn’t work on Wayland. This really stinks!
I’m really on the fence about it and I keep thinking of switching back to Xorg.
Regarding the video decode support in Firefox, I've got a working solution to that (a VA-API implementation backed by NVDEC). Just waiting for some Firefox patches to land to release it.
No sure it works on wayland though, not tested it there.
Tried Wayland recently on Fedora 35 with an AMD GPU and found that it causes issues with a lot of Proton games that I don't have on X.org. So, Wayland is still a "no thanks" for me.
Same. I had weird issues when playing Diablo II: Resurrected with menu items not being clickable or other jank that was not present with xorg. It's almost there though. I'm excited when features like this are pushed as defaults because it means more feedback, more pressure to fix remaining issues.
Anyone know if Nouveau can operate in integrated-only mode? And if so how can that be confirmed? The only reason I use Nvidia drivers is to use integrated-only graphics mode.
62 comments
[ 3.5 ms ] story [ 128 ms ] threadAlso, it’s not defaulting to installing the driver anyways - as described in the article and its sources, what Fedora is actually planning to do is to change GDM’s udev rules to select the Wayland session by default if the proprietary drivers are running.
The actual change proposal is: https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVI...
Discussion: https://lists.fedoraproject.org/archives/list/devel@lists.fe...
I aint touching that with a 10 foot pole anytime soon.
How do you know this (that it was wayland)? I have never had a lockup caused by anything other than swapping, across multiple machines with Intel graphics.
Manjaro, clean install on my Intel laptop. Login with wayland, freezes for up to a minute at a time, sometimes it locks up completely.
Reboot and login with Xorg. Flawless.
Manjaro, clean install on my AMD laptop. Login with wayland. Flawless.
Intel tends to break randomly its Linux driver for some of its gpus, it's quite annoying.
I'll happily blame Intel as well, but the point is: I only see this problem with Wayland, sticking to Xorg and it's smooth sailing.
On firefox it works out of the box. On Slack as well.
On chromium it's still hidden behind the flag: chrome://flags/#enable-webrtc-pipewire-capturer
On Zoom it's more complicated. For whatever reason it uses gnome's private screenshot API to share screen Now that Gnome secured this API, it's not working at all, even for Gnome users... The web version allows to share the screen, but their web version is really not great.
Can you not do that with XWayland? Genuinely curious. I've never used/needed remote X, so I am not up to date with the capabilities.
There are remote Wayland options, though. I think Waypipe (https://gitlab.freedesktop.org/mstoeckl/waypipe) is one?
I used to run the XOrg-accelerated stuff as it was faster and used less power on my laptop, but once my machine got new enough for SNA it became too buggy vs. modesetting.
https://support.zoom.us/hc/en-us/articles/201362153-Sharing-...
Linux sessions utilizing Wayland can only share an entire desktop or whiteboard. In order to share just a specific application, you will need to launch your Linux session with Xorg instead.
The Zoom application needs to be adapted to work through the Wayland screencast portal interface to get things working properly (including sharing audio!). I've tried to report this to Zoom, but I'm not enough for them to realize it's a problem...
* https://twitter.com/Det_Conan_Kudo/status/135988702055492403...
* https://twitter.com/Det_Conan_Kudo/status/140481481290384589...
* https://twitter.com/Det_Conan_Kudo/status/144619684654890189...
If you (or anyone else here reading this) is a Zoom customer, please file support tickets asking for this to be fixed. I gave them all the technical details on how to fix this at the beginning of this year, so they know what they need to do.
I wont touch any nvidia nor x.org with a 10ft pole anymore.
Are you a Fedora dev? Do you have an impression that NVIDIA is getting to be a bit more cooperative with the desktop Linux development community these days, like with the changes related to GBM that made this decision possible for Fedora?
While this Change currently describes the effort for GNOME, KDE Plasma is likely to also be ready for Fedora Linux 36 for this. There a couple of other blockers to deal with, but hopefully those are squared away in time...
I work in the automotive industry, where we buy high-end, high-margin SoC SKUs - not a lot of them (compared to phones, primarily), but enough to have some sway. Within the industry, most OEMs are moving toward inhouse platform-shaped development and have a desire to make their code increasingly reusable and hardware-agnostic, as well as lower integration costs for third-party app content. This drives the adoption of open source commodity stack technologies and standards like Wayland, and means hardware vendors now have to demonstrate or offer support for them - with a single code path. It then replaces vendor-proprietary stuff like nVidia's EGLStreams previously used for similar cross-process compositing use cases as Wayland is now. In the past, vendors were asked to solve the problem for the OEM as they saw fit on their hardware.
I've personally requested vendors to provide GBM support on the Orin SoCs by writing it into requirements. I know nVidia previously started incorporating limited GBM support in their GPGPU product line, probably due to similar customer asks in that industry, but I don't know it well.
For the Linux desktop community the takeway is that it has a massive impact beyond just the Linux desktop - by being a leader in the commodification of technologies everyone just ends up adopting, especially as embedded development trends toward a similar complexity level as desktops and phones with similar feature requirements. Accordingly it deserves support from those who have these technologies in their supply chain.
Tegra drivers (incl Xavier) already had GBM since years, with the nvgpu driver stack.
Doesn't mean you don't need to explicitly spell it out in Orin requirements though :-)
Thanks Eike
Also I'd be skeptical to some extend on this. Maybe back in time when a chip fail ratio was lower was a case. But now, there is a quite measurable amount of chips not passing requirements for a high tier cards, but can be used in the lower models (with limited amount of cores etc or worse thermal efficiency).
"A developer driver inadvertently included code used for internal development which removes the hash rate limiter on RTX 3060 in some configurations," the company said in a statement. "The driver has been removed."[1]
So it's hard to tell when it's binning, and when it's hobbling.
[1] https://www.theverge.com/2021/3/16/22333544/nvidia-rtx-3060-...
“It’s not just a driver thing,” said Bryan Del Rizzo, Nvidia’s head of communications, last month. “There is a secure handshake between the driver, the RTX 3060 silicon, and the BIOS (firmware) that prevents removal of the hash rate limiter.”
I feel a lot of this comes down to them using closed source software that they either don't have the code to, or aren't privileged to distribute. Libraries are a common spot for this to appear
Kepler could literally have all its cores enabled with a simple bridge on one laser cut. That's fun but very hit or miss, the more cores are disabled the higher the likelihood they're actually defective so it was binned lower.
Maxwell can have their Hwid modded but performance will be lower than actual Quadros.
Newer cards have an even bigger performance difference, more hardware differences I think.
Of course, I'd hate that in normal times, but if they now made me an offer to "upgrade" my 1060 (to moderately higher performance, but still lower end), I'd probably take it.
AFAIK there’re only 4 differences between GeForce and Tesla/Grid: more and faster VRAM, more FP64 GFlops on most GPUs, unlimited count of nvenc encoding streams versus 2 on GeForce, and support for virtualization. Only the first two are hardware differences, the other 2 are software.
Another thing about virtualization, it sounds ridiculous but nVidia charges non-trivial per-user fee to allow people to use the hardware they already own. Specifically, for virtual workstation they want $450 per concurrent user. That’s on top of the $3000-$12000 purchase price of these GPUs.
IBM does that with mainframes, but, at least, it’s hardware they own that they shipped in the box for you to rent out when needed or to buy and enable.
Of course, distributing a "cracked" driver would breach licensing agreements and violate copyright (and possibly other laws), so it's out of the question for any kind of professional use. However, if Nvidia uses it to differentiate services, wouldn't there be a significant risk of private consumers (gamers, hobbyists, etc) using such a driver to "upgrade" their cards for personal use?
The firmware itself truly is signed and so on
Another big deal is there’s no hardware video decode support in Firefox. I don’t have integrated graphics, so I rely on Nvidia’s VDPAU implementation that doesn’t work on Wayland. This really stinks!
I’m really on the fence about it and I keep thinking of switching back to Xorg.
NVIDIA’s VDPAU successor seems to be Vulkan Video. So those issues are going away at some point in the future at least.
No sure it works on wayland though, not tested it there.
[1] https://wiki.archlinux.org/title/NVIDIA_Optimus#Use_Intel_gr...