Nvidia Driver not yet supported for Linux Kernel 5.9
forums.developer.nvidia.com
forums.developer.nvidia.com
[1] https://www.engadget.com/intel-xe-gpu-gamers-130000411.html
[2] Yes, ImgTec/PowerVR is getting back into the discrete GPU game! https://www.imgtec.com/blog/back-in-the-high-performance-gam...
AMD even redesigned the silicon to isolate HDCP from rest of the core to be able to open video encoders and other HDCP facing hardware to open drivers.
Also, AMD's open driver's written by a different team in AMD. So they're not exactly 3rd party drivers.
Intel on the other hand typically has their drivers in released kernels long before their hardware is released. Intel's New GPUs haven't been released yet, but they first started adding support in early 2019 [2]. I can't find it now, but I remember hearing a story about Intel removing drivers from the kernel tree for some hardware that they cancelled.
If you want to use a modern high-end GPU in Linux, your only real choice continues to be Nvidia. Their drivers are not open source, but at least they work at launch (except maybe with a 5.9 kernel?).
This is why Intel entering into the high-end GPU space is so exciting. Soon we may have a high-end option with good open source drivers while the part is still high-end.
[1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....
[2] https://www.forbes.com/sites/jasonevangelho/2019/02/18/intel...
Nvidia has a history of problems in Linux. I can still remember having to log out of my X session just to change monitor layout; which is something you do alot with a laptop and external displays. Took them several years to fix!
I've experienced intel boards where I had trouble getting anything but the newest fedora with custom kernel parameter to even get the installer running. But most of the time intel has very good upstream support, so it is normally a pretty safe bet.
With AMD there are sometimes delays getting full support for a new generation upstreamed (e.g. hdmi audio and such), so it is usually good to Google for Linux reviews first.
In general AMD has superb open source support for their cards, if not immediately at launch, and I recommend them for Linux users who want the least amount of hassle.
I've seen people recommending Nvidia to Linux on YouTube (and now here), and I honestly think it's a disfavor to anyone interested in Linux.
I have been using a Polaris based card for years (card released in 2017), and the drivers were submitted in 2016. The kernel drivers were ready at launch and key features like HDMI audio were all working out of the box. Now, you might need to install a modern kernel for everything to work- but that is the Linux way.
It is true that the initial performance was not super great- maybe about 70% of the possible performance, however this was addressed by subsequent improvements to mesa (userspace portion)
AMD has even gone out of their way to support older, obsolete graphics cards that were released before AMD adopted the open source first strategy.
Source: https://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-P...
Compare to Intel where you have initial basic support landing around 2 years before launch with incremental improvements following. This is the correct way to do open source drivers.
Unfortunately AMD totally missed the boat on ML.
When you build a processor that literally has "do 4x4 matrix multiplication" as an assembly statement, you'll get far superior ML performance compared to everyone else. (Except Google's TPUs, which have larger matrix-multiplication arrays)
The open-source OpenGL drivers are very good.
I know ML is where the current money is at, but coprocessors in general seem to be applicable to far more problems than just machine learning and graphics.
What if AMD actually acquires Xilinix?
Everybody thought it's about CPU-FPGA integration but, they may pull something very, very different.
https://www.xilinx.com/support/documentation/white_papers/wp...
True, a systolic processor can be built out of these components, but I doubt it'd be anything as fast as a proper matrix-multiplication unit that NVidia is putting out. And that's after the complications associated with FPGA programming.
----------
Xilinx's FPGAs are a combination of LUTs (4-bit or 6-bit look-up tables), Routing, and "DSP Slices" (prefabricated multipliers). The bulk of your math is still going to be performed in the DSP Slice.
Where FPGAs win is that their LUTs and Routing tables allow you to create custom high-speed glue-logic between these DSP slices. But when it comes to something like a regular Convolutional neural net, the routing is very straightforward.
------
I'm not really a deep learning expert. I know that FP16 seems to be pushed by NVidia. This INT8 stuff seems odd to me (there's no way INT8 gets the same dynamic range as FP16), but I'm also not really sure if the dynamic range is needed or useful in deep learning applications.
The only consolation for me is that I/O over PCI ends up being my ultimate bottleneck. If AMD did a full-on integration with their infinity fabric, it could actually be a game changer. For me, in my weirdo niche.
----------
AMD's GPU Infinity Fabric seems to be a different infinity fabric from their CPU. CPU Infinity Fabric is ~50GB/s, but the GPU Infinity Fabric is GPU-to-GPU links of ~90GB/s.
Realistically, PCIe 4.0 and 5.0 will be the path forward for standard PCs. There will always be incredible application-specific solutions (such as NVLink / NVSwitch on the DGX), but the general computer user will wait for the open standards to support such speeds before adopting them.
At the moment, GPU-to-GPU communications probably will scale better than CPU-to-GPU comms. CPUs just aren't built for the bandwidth (outside of POWER9 / POWER10).
https://www.arm.com/company/news/2020/09/nvidia-to-acquire-a...
Are FOSS drivers available? If not, ImgTec/PowerVR is worthless and they can come back from whence they came.
EDIT:
Their webpage for their current gpus list no drivers at all (where is a generic user supposed to find them?) and no mention of Linux at all.
That's not promising at all. If they want to become a failure again, they're on the right track.
IMG 's drivers aren't exactly known for their quality and Intel GPU are / will be competing with a process node disadvantage.
You're right that PowerVR drivers are likely to suck. However, you're wrong about Intel being at a process node disadvantage, because their GPUs are going to be fabricated by TSMC :-O
Only one of their specific SKUs out of dozen are fabbed by TSMC, and it was a very late addition to the lineup. As long as Intel operate their own leading edge Fab, Intel's incentive is and always will be to fully utilise their own fab capacity as much as possible in order to gain economy of scale.
What we need is a stable driver API in Linux.
Is that deliberate to fuck with nVidia?
Nvidia is trying to put the blame on Linux, but Intel and AMD don't have these issues because they open sourced and upstreamed their drivers (for AMD they mostly did), which is the way to work with open source.
Linux has always been fighting an uphill battle, but as it becomes more and more relevant it is becoming increasingly difficult to fight against it. Intel understands this, and AMD understands this.
The wording by Nvidia is telling for how they view Linux I think. In fairness it's probably very costly for them to go open source (one time cost at least).
So it's not the driver that is incompatible, it is Linux. And that led to the grandparent comment asking if Linux people are "deliberate to fuck with nvidia".
If nvidia had said "our driver is incompatible with the newest Linux kernel" then we probably wouldn't been having this thread.
nVidia probably saw this coming, but doesn't care that much to proactively work on it.
Most of those running ML applications don't have to update the kernel very promptly, and they only have to wait until mid-November, according to nVidia. This few months of delay couldn't possibly hurt nVidia to any meaningful degree.
it's a little frustrating that things which used to be kosher, like nvidia and nvidia_uvm linking are all of a sudden not because they got caught up in this crossfire.
Seems like petty behaviour to break users hardware just because you disagree with driver licensing.
It's not a war. It's an open source project with a clear API, and a company that doesn't keep up with the API.
1. "Programs" (as defined by the GPL) can be legally separate works and share the same address space (on a platform where this arrangement is highly unusual)
2. Separate GPL Programs hosted in the same address space can share linked symbols determined to not be "internal APIs" (in a world where the Supreme Court might run roughshod over this and just say all API implementation is copyright-infringing)
3. "Operating system kernel" and "GPU driver for that self-same kernel" can be considered, regardless of address space colocation, to be separate GPL Programs.
This interpretation is highly unusual but holds primarily because Linus Torvalds and every other major kernel contributor endorsed it. Whether or not this constitutes promissory estoppel, implied license, or something else is up to Nvidia legal to decide; but it's highly likely that nobody with standing to challenge what would otherwise be an obvious GPL license violation is actually in a position to do so. Hence, Nvidia has access to a market they shouldn't.
> Home > Accelerated Computing > CUDA > CUDA Setup and Installation
However, what I don't see is that nVidia should have any obligation (ethical, legal or otherwise) of any sort to provide a Linux driver at all. The demands of Linux developers and users alike seem particularly entitled.
Linux is the only mainstream kernel, free or proprietary, which doesn't have a sane and supported driver interface. And while I can see some of the justifications for it, I think after nearly 20 years they are starting to wear a little thin. The way other out of tree subsystems, like ZFS, have been treated is appalling. Deliberately using the GPL as a cudgel to beat other projects into submission is just plain nasty, and to treat other open source projects this way is spiteful and unnecessary.
I don't believe OpenBSD or FreeBSD has such an interface either, and I'd classify those as mainstream kernels.
> However, what I don't see is that nVidia should have any obligation (ethical, legal or otherwise) of any sort to provide a Linux driver at all.
Well, they don't. But they have a commercial need for Linux support: their recent revenue growth has been in datacenter usage of GPUs, and Linux support is necessary for that computing environment. To that end, IMHO NVidia is the entity that needs to align its development practices to support the existing Linux driver community rather than Linux needing to align its process to accommodate NVidia's wishes.
This isn't to say that Linux has been right in its treatment of other external entities: the treatment of ZFS, as you note, does seem to be driven more by spite than actual technical reasons. But in the case of NVidia, there is definitely a good deal of fault on NVidia's side that needs to be acknowledged.
A freeze for a couple of years seems like a reasonable compromise to me. It's not forever, but it's long enough for third-parties to develop, validate and support a product for. The closest Linux gets to this is vendor kernels which are both vendor-specific, and highly-custom and badly dated. This at least gets you something reasonably current and supported to work with.
Also, imagine Linux didn't enforce GPL. Would Nvidia be more motivated to upstream their driver? Not in the least. They don't care about GPL. What they want is to have a leverage over the market and charge more for industrial usage, by forcing usage of the blob on their terms (which upstreamed driver would prevent by giving ability to use the hardware to anyone on any terms). That's their whole motivation in this as far as I understand.
About 2: I have no idea how difficult this is. Microsoft makes it look easy, but on the other hand, Apple is about to remove any 3rd party code out of their kernel.
About 1: I believe that this hurts more than it helps. Expecting nVidia to move their OS-agnostic codebase into the Linux kernel sounds like a massive effort with no real benefit for them. That seems unlikely to happen. With, for example, OpenZFS, this might be possible if Oracle relicenses their last open-source version. Still, I don't see the Android OEMs budging on their stance of releasing binary blobs alongside their SoCs.
Android is currently the largest install base of Linux kernels across the world, and the lack of a stable ABI means that none of these devices can run the latest and greatest Linux version ever during their lifetime. It is easy to shove all the blame over to Qualcomm, Mediathek, etc. but we also have to see it as a failure of Linux as a platform.
Not every participant of a platform will always play nice, and these kinds of issues could all be solved by providing a stable ABI.
Nouveau is already upstream. Nvidia should just stop messing it up and allow it to access GPU registers for proper reclocking. So there is no valid argument about difficulty at all. It's purely political and anti-competitive on Nvidia's part.
But given that nVidia makes billions every year selling hardware to companies to run CUDA on Linux I would argue that it's nVidia that's acting entitled rather than the Linux developers.
Imagine if that behaviour would be done by Google, Microsoft or others - constantly breaking Mozillas or anyone elses code until they'd change their software license.
That's been the case for Linux users for quite a while already. Only those who are stuck with CUDA lock-in need to deal with this mess these days.
Nouveau developers expressed all this best:
> Moral of the story... just get an Intel or AMD board and move on with life. NVIDIA has no interest in supporting open-source, and so if you want to support open-source, pick a company that aligns with this.
https://www.phoronix.com/forums/forum/linux-graphics-x-org-d...
The vast majority of Linux use is on servers. When servers need GPUs it's usually for machine learning or other computation. Nvidia currently holds almost all of that market.
All dropping Nvidia support would accomplish is forcing everyone in that market to switch to Windows. Cloud revenue would drop significantly for Linux companies like RedHat, which would in turn mean they have less spare money to work on desktop distros. So as much as I despise Nvidia, until AMD/RTG get their shit together AND (yes, we need both) Intel's dGPUs come out (and don't suck), we desperately need Nvidia support.
But in general I agree, the sickening CUDA lock-in situation has to change. AMD and Intel are working on it so things are improving, though slowly.
Instead of improving and opening up, they locked down and obfuscated everything and went downhill from there.
My next GPU won't be an nVidia. I'll be back to red team and be happy (I'm an AMD/ATI soft-fanboy. Love their design choices and hardware more).
If they want to be #1 in AI, they must realize AI at scale takes place primarily on Linux.
CentOS 8 still uses 5.8 for example and will use it for a long time.
I manage such systems and unless something explicitly needs 5.9, we won't upgrade them. If it's working, it's working. Everything is isolated from outside network so, external threats are not very important. We're also an academic installation so, there's nothing sensitive inside.
Edit: This doesn't mean that we won't security-patch our systems. That's done pretty quickly and regularly. It's different.