Why in 2019, Linux still have problem with "certain" GPUs ?

[BravoV]

Don't want to derail another discussion thread, its just I read, starting from this post and the next one ...

 -> https://www.eevblog.com/forum/general-computing/installing-linux/msg2768422/#msg2768422

Cmiiw, as I'm not programmer nor Linux user, is it as simple as the GPU manufacturers just don't want to open or reveal, on how to access their GPU to their full capabilities ?

Or something else ? 

[ataradov]

is it as simple as the GPU manufacturers just don't want to open or reveal, on how to access their GPU to their full capabilities ?

Pretty much. You have to run vendor's drivers, which are closed binaries tested on a very limited set of hardware configurations and kernel versions. Vendors have huge turnaround times, and there is no way for community to fix anything, so you jut have to sit and wait when you have a problem.

There are similar issues in a world of Windows, but at least there there are not so many kernels that get updated too often.

And in case of Windows both MS and GPU vendors essentially coordinate releases. Neither thing is ready until both work together.

[BravoV]

You have to run vendor's drivers, which are closed binaries tested on a very limited set of hardware configurations and kernel versions. Vendors have huge turnaround times, and there is no way for community to fix anything, so you jut have to sit and wait when you have a problem.

What are the dis-advantages, "IF" they just post all the bell & whistles for accessing the GPU ? I'm imagining, its like reading a MCU's datasheet, say for example like most ARM MCUs datasheets that reveal down to bits for bare metal access. 

Isn't that good for their users, say if there is a common problem, its just matter of time the community (I wish) will come up with the fixes or workarounds, especially for high priorities problems/bugs, or even better develop much better one (again, I hope), personally I think the chances are pretty good right ?

Again, what dis-advantages if they reveal it ? Exposing their IP ? C'mon, its been decades that GPU has evolved from dumb rasterizer into todays powerful silicon, that they should have geniuses, that can design a GPU from zero, while still proprietary design, that at the end publishing the method to access their GPU optimally, will not reveal anything secret sauce inside ?  Its not that hard, right ?

Again, I could be wrong or naive, but can't help it that now I see the current scene this way.

[ataradov]

What are the dis-advantages, "IF" they just post all the bell & whistles for accessing the GPU ?

Details of the register set will disclose details of the internal implementation, which is not great if everyone is an enemy trying to steal your stuff. Or trying to sue you for violating their patents.

Plus companies license a lot of stuff from third parties.

say for example like most ARM MCUs datasheets that reveal down to bits for bare metal access. 

Go and try to find details on the touch controller or RF range measurement block in Atmel/Microchip MCUs.

[BravoV]

What are the dis-advantages, "IF" they just post all the bell & whistles for accessing the GPU ?

Details of the register set will disclose details of the internal implementation, which is not great if everyone is an enemy trying to steal your stuff. Or trying to sue you for violating their patents.

Plus companies license a lot of stuff from third parties.

say for example like most ARM MCUs datasheets that reveal down to bits for bare metal access. 

Go and try to find details on the touch controller or RF range measurement block in Atmel/Microchip MCUs.

Ok, noted, so basically we have to live with the current situation, as I don't see how this change in direction significantly in near future ? 

[Karel]

AMD has made available datasheets and register info for their GPU's.
They also have a small team working on Linux drivers (much smaller than their windows team) and usually, they release their open-source graphics drivers for linux after the hardware has been released on the market.
Add the time for the kernel and distro maintainers to integrate it, and you see why AMD drivers are always delayed.
But the quality of the open-source AMD drivers is pretty good. Everything works out of the box. No broken display when updating or changing a kernel.
On the desktop, it's just nvidia that breaks Linux' balls. So, if you want a nice Linux experience, use an AMD GPU but pay attention not to use the latest models (because of the delayed appearance of drivers).
I completely understand why Linus gave the finger to nvidia:

[Ed.Kloonk]

Don't want to derail another discussion thread, its just I read, starting from this post and the next one ...

 -> https://www.eevblog.com/forum/general-computing/installing-linux/msg2768422/#msg2768422

Cmiiw, as I'm not programmer nor Linux user, is it as simple as the GPU manufacturers just don't want to open or reveal, on how to access their GPU to their full capabilities ?

Or something else ? 

There are a couple of reasons. First is the problem of releasing source code for peer review would reveal a dog turd of rushed kludge and security oversight which would be too embarrassing for them.

The second problem is the actual programming mindset. MS, for example wanted to speed up the Windows UI. So they set about putting more and more of the code in the Kernel (where it doesn't belong!) and then they got caught. Big time. After thousands of machines got hacked.

The joke of it is MS has always stipulated how we all should code for their platform for their own reasons.

[Jeroen3]

It all comes down to monetary reasons.
The chip vendor sells most single cards to people with Windows, for 3D applications (games).
The chip vendor also sells pallets of cards for scientific calculations, these are more likely to run linux clusters.

Why would the chip vendor make something with no monetary benefit?
A lone wolf linux user is not going to make a ripple in sales.

Now the card vendor could do something here too, like specify if the open source driver is still compatible, as sometimes it is not. (Xtreme Gamer Edition  )

Again, what dis-advantages if they reveal it ? Exposing their IP ? C'mon, its been decades that GPU has evolved from dumb rasterizer into todays powerful silicon, that they should have geniuses, that can design a GPU from zero, while still proprietary design, that at the end publishing the method to access their GPU optimally, will not reveal anything secret sauce inside ?  Its not that hard, right ?

I'd assume something like Nvidia new "raytracing" is using some new things they'd rather keep hidden from their competitors as long as possible.
Writing an open source driver does not follow that goal. Also, reference manuals are tightly moderated. You'd have to spend valuable times creating a version suitable for release. It's easier to not publish at all, or hide behind strict "partner contracts" (NDA).

[Nominal Animal]

GPU access is also not just a simple register file, since they are actually massively parallel sets of processing cores, with usually more than one simultaneously usable video output.  One needs to know how the device was intended to be used, because the combinatoric explosion of possibilities makes it utterly impossible to discover (except by luck -- even reverse-engineering at this scale needs dedicated hardware and incentives open-source developers simply do not have).

A rough analogy would be to be given all the components for a fully working computer, but without the motherboard layout, wiring, or schematic; just the components.  It would be a pretty frustrating task to discover the proper layout/schematic/wiring for the given components, especially when working computers are already available, and nobody is paying you to do that work anyway.  Just think about the bypass capacitors a typical processor has!

The business/competitive model for Nvidia and ATI was based on proprietary drivers with secret sauce.  AMD has always been more open toward libre open source, probably because as a processor manufacturer, all their secret sauce was inside their processor and designs, and having their customers know exactly how to use the hardware to the fullest was in AMD's interests all along.

It is interesting to note that it took about a decade after AMD's acquisition of ATI Technologies, before they could open-source their drivers.  They did open some of the hardware access documentation earlier, helping the open-source driver development.  I bet there were some heated discussions inside AMD/ATI at that time; it was such a hard turn for the business model!

It is funny to note that Nvidia has just recently (August 2019) published some of the hardware access documentation, with the intent to help open-source driver development (especially nouveau).  Unfortunately, the kind of information that can help make a driver stable and fully functional, will probably never be included in this information, because it is too close to the internal "secret sauce" Nvidia still thinks it needs to compete.

[nctnico]

is it as simple as the GPU manufacturers just don't want to open or reveal, on how to access their GPU to their full capabilities ?

Pretty much. You have to run vendor's drivers, which are closed binaries tested on a very limited set of hardware configurations and kernel versions. Vendors have huge turnaround times, and there is no way for community to fix anything, so you jut have to sit and wait when you have a problem.

There are similar issues in a world of Windows, but at least there there are not so many kernels that get updated too often.

OTOH you don't have to update the Linux kernel every week. On a desktop system I don't update the kernel at all if the computer works just fine. The trick with Linux is to read which hardware and kernel are supported by proprietary drivers and stick to that. If you venture off the beaten path then you are on your own.

[RoGeorge]

nVidia drivers for Linux, by nVidia: 
https://www.nvidia.com/Download/driverResults.aspx/153226/en-us
https://www.nvidia.com/en-us/drivers/unix/

[Black Phoenix]

OTOH you don't have to update the Linux kernel every week. On a desktop system I don't update the kernel at all if the computer works just fine. The trick with Linux is to read which hardware and kernel are supported by proprietary drivers and stick to that. If you venture off the beaten path then you are on your own.

Even if you update, GRUB gives you 2 kernel back selection when loading in case the latest breaks something.

[nctnico]

OTOH you don't have to update the Linux kernel every week. On a desktop system I don't update the kernel at all if the computer works just fine. The trick with Linux is to read which hardware and kernel are supported by proprietary drivers and stick to that. If you venture off the beaten path then you are on your own.

Even if you update, GRUB gives you 2 kernel back selection when loading in case the latest breaks something.

That shouldn't be a problem because the drivers are built as modules and each kernel version has it's own modules. The previous kernel will load the drivers built for that kernel.

[Nominal Animal]

nVidia drivers for Linux, by nVidia: 
https://www.nvidia.com/Download/driverResults.aspx/153226/en-us
https://www.nvidia.com/en-us/drivers/unix/

Do you realize that if you use proprietary drivers, nobody can help with kernel issues anymore?
If your machine crashes with Nvidia drivers, Nvidia is the only one who can help?

(Sometimes you can find a kernel developer with that exact hardware and kernel version, and they might have an idea why that happens, but this is rarer than winning in a lottery.)

Because the Linux kernel is monolithic, there are no internal limitations on the silliness a kernel driver can do.  When proprietary drivers were allowed, the developers soon figured a way to mark kernels where such drivers had been used since booting tainted, because it is basically impossible to debug stuff when a part of it is a black box that can do anything but you cannot open it to find out if it malfunctioned and caused the issue or not.

Which means, if you use proprietary drivers, the kernel developers will not help you.  Not because they don't want to, but because it is too frustrating to try to help in that situation.

Because of this, I will not recommend proprietary drivers to any new Linux users.  In my opinion, it is like teaching a kid to ride a bicycle, when one or both of the wheels are about to blow.  Ensuing bruises aren't funny, even if they show that on Youtube.

[Mechatrommer]

https://www.makeuseof.com/tag/use-amd-nvidia-gpus-linux/

nouveau is much, much slower than the proprietary Nvidia drivers, especially with newer graphics cards. Support for the newest Nvidia products is also quite lacking — it takes a lot of time to recreate.

yes teach a kid with 4 wheels bicycle but it can only go that fast, kid's bicycle fast, with plastic wheel bearing... i really feel sorry for all those people who had to go to the trouble of reverse engineering graphics card. what i wonder is why GPU's manufacturers took this slow to introduce their product to Linux environment. GPU is just a small part in peripherals. i'm talking about all the devices that are meant to be connected to a PC. when i look at a product/device, goto website, there's only Windows driver, Linux driver, none. look at that product, same. why dont every manufacturers will provide driver for both Windows and Linux? my only guess is maintaining compatibility across 1001 type of Linuxes is simply a nightmare, or... Linux market is just not profitable. either due to very small users population, or Linux only profitable at very small area such as IT, or the business or code model of the Linux itself is not that appealing (make your secret sauce / IP open? well thats not good!)

[nctnico]

nVidia drivers for Linux, by nVidia: 
https://www.nvidia.com/Download/driverResults.aspx/153226/en-us
https://www.nvidia.com/en-us/drivers/unix/

Do you realize that if you use proprietary drivers, nobody can help with kernel issues anymore?
If your machine crashes with Nvidia drivers, Nvidia is the only one who can help?

This is a non-issue. Just getting your head wrapped around the way the drivers work and where the bug is will take at least a week for a very experienced software engineer. Let alone fixing the bug (which could be hardware related when it comes to a driver). Being able to fix problems in software yourself is highly overrated. Especially when it comes to the kernel. I know my way around in the Linux kernel pretty well but that is the result of months worth of (paid) time.

And I strongly disagree with not using proprietary drivers. Manufacturers test their drivers thouroughly and fix issues quickly because they will need to support professional Linux users. So far my experience with manufacturer supplied drivers (Matrox and Nvidia) for video cards has been very good where it comes to speed and stability. Even on embedded ARM systems you'll have to rely on manufacturer supplied drivers which work with a certain kernel version and system libraries.

[Nominal Animal]

Do you realize that if you use proprietary drivers, nobody can help with kernel issues anymore?
If your machine crashes with Nvidia drivers, Nvidia is the only one who can help?

This is a non-issue.

Thousands of bug reports, blog posts, and mailing list messages disagree.

Even those who work with Cuda because they need the GPU resources for HPC tasks I've talked to, tend to curse Nvidia every once in a while.  Sure, they say that Nvidia isn't that bad, but talking to them whenever they have issues, tells me their problems unsurprisingly often involve the Nvidia drivers or support libraries.

And I strongly disagree with not using proprietary drivers. Manufacturers test their drivers thouroughly and fix issues quickly because they will need to support professional Linux users. So far my experience with manufacturer supplied drivers (Matrox and Nvidia) for video cards has been very good where it comes to speed and stability.

I myself, and many others I've talked to about this kind of driver issues, have the exact opposite experience.

In particular, none of the manufacturers that provide binary-only drivers have "fixed issues quickly".  Their most typical response is that they no longer support that product, because they have a newer version of the hardware out.  For Nvidia, the Linux responses I've heard of have been less than supportive, and closer to "please switch to Windows, our support is so much better there" than anything else.

Granted, my experience with Nvidia graphics drivers is at least five years old (I got fed up enough and just decided to exclude Nvidia from the things I help with), and at least three for the Cuda stuff.  But I don't think things change in the corporate world faster than that.

Even on embedded ARM systems you'll have to rely on manufacturer supplied drivers which work with a certain kernel version and system libraries.

That is completely different: they at least provide the full sources.  (Unless they enjoy breaking the GPL, like Qualcomm, and rely on nobody having enough interest to sue them.)

The SBC systems I currently have run on Samsung Exynos 5422 (Odroid HC1), Amlogic S805 (Odroid C1+), Amlogic S805X-AC (La Frite), and Allwinner H5 (Orange Pi Zero Plus).  All three manufacturers are pushing support into the mainline Linux kernel (and there are linux-exynos, linux-meson, and linux-sunxi projects, respectively, to support that; but to see the actual contributions, look at contributor domains at LKML).  So, the situation wrt. embedded ARM systems is very similar to AMD, although incomplete; and completely opposite to Nvidia.

In fact, I have a stinking feeling the Nvidia "documentation dump" in August was pretty much a stunt, to ensure they get some big contract related to HPC done; very much like what Microsoft did with OOXML -- whose only reason for existence was to avoid Microsoft from being excluded from some very lucrative government contracts requiring native storage support in some standardized open format.

The only manufacturers I know insist on providing their own "SDKs" based on specific versions of the Linux kernel, GCC, and binutils, are Realtek and Qualcomm, and their support is worse than shit anyway.  Anybody using their boards, knowing their history with Linux and Linux support, has no sympathy from me.

[dferyance]

When proprietary drivers were allowed, the developers soon figured a way to mark kernels where such drivers had been used since booting tainted, because it is basically impossible to debug stuff when a part of it is a black box that can do anything but you cannot open it to find out if it malfunctioned and caused the issue or not.

I've had many instances in my career where I wished I could have that attitude. Granted it is very different when hired to do a job vs volunteering your time for free.

Take your typical user-mode application.... having 3rd party binary code interact with it is common -- possibly the norm. I've seen crash dumps of an application I worked on having a ton of 3rd party DLLs running within it. Sometimes anti-virus, video card libraries, to something way more obscure. Was the crash my code or the DLLs or some odd interaction? Hard to say; I had to figure out anyway. Sometimes users delete critical files or do other dumb things to cause the program to crash.

Also web applications can have browser plugins modify them, or security software man in the middle the SSL. Basically, if you write software the people run on their own PCs, there will always be the possibility that something they installed caused your application to malfunction. That doesn't stop software vendors from having to support it anyway.

[ataradov]

I've had many instances in my career where I wished I could have that attitude. Granted it is very different when hired to do a job vs volunteering your time for free.

Even if you are hired as a Linux kernel developer, you still can't dig around in the driver binary, including for debugging reasons. They mark the kernel as 'tainted' largely for a legal reason. When you download the driver, you agree to a EULA, which limits your ability to do things with it. And in some countries this reverse engineering for debugging is illegal.

[nctnico]

Do you realize that if you use proprietary drivers, nobody can help with kernel issues anymore?
If your machine crashes with Nvidia drivers, Nvidia is the only one who can help?

This is a non-issue.

Thousands of bug reports, blog posts, and mailing list messages disagree.

Even those who work with Cuda because they need the GPU resources for HPC tasks I've talked to, tend to curse Nvidia every once in a while.  Sure, they say that Nvidia isn't that bad, but talking to them whenever they have issues, tells me their problems unsurprisingly often involve the Nvidia drivers or support libraries.

But this situation is already beyond just using the video card for it's primary purpose: rendering video for a desktop/workstation system.

[Nominal Animal]

Do you realize that if you use proprietary drivers, nobody can help with kernel issues anymore?
If your machine crashes with Nvidia drivers, Nvidia is the only one who can help?

This is a non-issue.

Thousands of bug reports, blog posts, and mailing list messages disagree.

Even those who work with Cuda because they need the GPU resources for HPC tasks I've talked to, tend to curse Nvidia every once in a while.  Sure, they say that Nvidia isn't that bad, but talking to them whenever they have issues, tells me their problems unsurprisingly often involve the Nvidia drivers or support libraries.

But this situation is already beyond just using the video card for it's primary purpose: rendering video for a desktop/workstation system.

What the hell is wrong with you?

I wrote that "Thousands of bug reports, blog posts, and mailing list messages disagree."  This refers to bug reports of applications, desktop environments, and the entire machine glitching or keeling over, when doing ordinary stuff with proprietary Nvidia graphics drivers in Linux.  See any Linux distribution support forum, Freedesktop.org bugzillas and mailing lists, and various Linux mailing lists.

After that, I continued that even Linux users forced to use Nvidia proprietary drivers, because they need Cuda, curse out the support and the drivers, even when they say they think the drivers are okay.  This shows that even these users' experiences are worse than their opinion about the Nvidia drivers.  The intent of this paragraph was to point out that even users who do not complain about the drivers on public fora but state their opinion as "the drivers are okay", have curse-worthy issues with the Nvidia proprietary drivers.

Fortunately, this forum has ignore lists.  Plonk; one more to mine.

[BravoV]

Pick your poison. Choose NV if you want tightly optimized drivers but can live with bad compatibility and closed source implementation, choose AMD if you care about open source but you don't need to extract the last bit of performance out of your hardware.

Either way, you won't get the quality of a Windows driver until there comes a day where Linux kernel and X system and key user space frameworks only come with a few flavors and configurations, all dictated by a single party like FSF or LF. It's just impossible to release a single binary that works with all different configurations. This applies to both fully closed source NV driver and closed source AMD user space Pro driver.

All my GPUs are AMD's, and reading thru the net all this years, the performance difference at the same price range is not earth shattering, at least to my perception even at Windows platform, CMIIW.

Currently I'm in preparation stage to move host OS to Linux, as I still depend on Windows, it will be run in virtualization as I still use depend on Win 3.1, XP for some weird ass apps, and current main rig on Win 7 x64. 

[nctnico]

Do you realize that if you use proprietary drivers, nobody can help with kernel issues anymore?
If your machine crashes with Nvidia drivers, Nvidia is the only one who can help?

This is a non-issue.

Thousands of bug reports, blog posts, and mailing list messages disagree.

Even those who work with Cuda because they need the GPU resources for HPC tasks I've talked to, tend to curse Nvidia every once in a while.  Sure, they say that Nvidia isn't that bad, but talking to them whenever they have issues, tells me their problems unsurprisingly often involve the Nvidia drivers or support libraries.

But this situation is already beyond just using the video card for it's primary purpose: rendering video for a desktop/workstation system.

What the hell is wrong with you?

Well your comments went into the direction of developing software which is a more likely scenario to run into driver / library issues.  The proprietary NVidia drivers have worked perfectly fine for me for many years and the machine is on 24/7. Sure that is just one sample but during my research into what videocard to buy it didn't seem like NVidia would give me lots of trouble (as in blocking issues). You can't convince me the NVidia drivers work for no-one on Linux. Then again I'm not using the machine to play games or do really hefty 3D stuff.

[Mechatrommer]

no, it just happened your choosen hardware (among the pool of peripherals) to be compatible with your choosen system. if game and 3D is not your intention, why dont just use built in MoBo's GPU? ($0 cost 0 compatibility headache) or maybe you dont have any? i'm sure there are still many 1GB GDDRAM card out there for sale at super cheap, like (on par with) my faithful 10yrs old ATI HD4650 or NVIDIA Quadro 4000 (HP brand approved).

[BravoV]

Well your comments went into the direction of developing software which is a more likely scenario to run into driver / library issues.  The proprietary NVidia drivers have worked perfectly fine for me for many years and the machine is on 24/7. Sure that is just one sample but during my research into what videocard to buy it didn't seem like NVidia would give me lots of trouble (as in blocking issues). You can't convince me the NVidia drivers work for no-one on Linux. Then again I'm not using the machine to play games or do really hefty 3D stuff.

Although I didn't research deep enough on this matter, but briefly my impression that nVidia problems on Linux, is at the bleeding edge performance or features at 3D, computing or high end games stuffs as those people invested on expensive top end GPUs, mostly not those low end ones that causing the headaches, also not on avg Joe's low demanding 2D applications too.

CMIIW