NVIDIA Loses Huge GPU Order Due To Linux Blob

[hal2k1]

Like was so quickly done on AMD cards? ...oh wait a second...

Basically, it appears to me that most in the Linux world would rather have an open driver then one that actually, you know, works.

The closed drivers don't work. They kind-of implement their range of features to a standard (OpenGL, VDPAU, whatever) with quirks and exceptions and straight-out bugs. Because they implement a replacement for most of the layers of the Linux graphics stack, the issues with the Linux graphics stack itself cannot be fixed. Where the Linux world desires to introduce new features in the area of graphics, such as KMS and Wayland, the vendors of the proprietary drivers refuse to co-operate, and try to frustrate such new developments/improvements. New hardware (for Windows 8 machines) may require code signing of the kernel and drivers, and so the proprietary blobs simply won't work at all on new hardware.

The proprietary drivers are quite broken, they can't be fixed by Linux developers themselves, and they hold Linux development back. Everyone involved in Linux, even the graphics card vendors, would be far better off without the proprietary blobs.

[hal2k1]

Translation: You can't even determine if the problem was distribution specific or not.

And out of curiosity, with how many third party IP NVIDIA has obtained over the years, how exactly would they go about making an open source driver? And what, exactly, do they gain (IE: profit) by doing so?

Linux kernel developers don't want nvidia's code (which is mainly written for Windows). Linux kernel developers want programming specifications for nvidia's hardware, so that Linux kernel developers can write their own open source drivers for Linux. Since this code would be Linux kernel code, Linux kernel developers would be responsible for distributing and maintaining it.

Nvidia would become an acceptable solution for hardware meant to run Linux. Hardware which runs Linux represents the majority of computer hardware.

[hal2k1]

I'm pretty sure they have third-party licensed IP in their drivers and hardware.

Even simple stuff like video codecs.

Linux kernel developers don't want nvidias driver code, they want programming specifications.

No IP (especially hardware IP) is divulged by programming specifications, and hence "third-party licensed IP in their drivers and hardware" is not an issue.

If there is IP embedded in video codec hardware decoders, then people who buy that hardware get a license to use that hardware included in the purchase price, even if they run Linux.

http://en.wikipedia.org/wiki/Implied_license

"Implied licenses often arise where the licensee has purchased a physical embodiment of some intellectual property belonging to the licensor"

Poeple who run computer hardware still have to purchase that hardware, even if they use it to run Linux.

[kobblestown]

If there is IP embedded in video codec hardware decoders, then people who buy that hardware get a license to use that hardware included in the purchase price, even if they run Linux.

http://en.wikipedia.org/wiki/Implied_license

"Implied licenses often arise where the licensee has purchased a physical embodiment of some intellectual property belonging to the licensor"

Poeple who run computer hardware still have to purchase that hardware, even if they use it to run Linux.

Wouldn't this same argument apply to the S3TC situation? Why does the Mesa team refuse to turn it on by default then?

[liam]

Pretty much.

I still have yet to read on this site a compelling reason for NVIDIA to do all these things people here are clamoring for.

There are some things I would like to see too, but none of them revolve around NVIDIA promoting my religion of choice.


This is one of the reasons that Android never took off. Consumers don't like functioning binary blobs and demand vendors respect the open source community. Hence Android is mired in the 1% of mobile markets. ...oh wait a second...

Funny you should mention the drivers of Android. That is one of the weakest areas in the stack. Much of Android's input lag can be blamed on the drivers. Look up a paper about optimising android user interaction by, iirc, xiao feng (intel engineer). The event thread is one of the big time sucks.

[hal2k1]

Wouldn't this same argument apply to the S3TC situation? Why does the Mesa team refuse to turn it on by default then?

The same arguement would apply only if the patentable aspect of S3TC was implemented in hardware.

If it is implmented in software, then it would be safe to use in Linux only if the owner of the patent had promised not to sue other Linux vendors, such as this group:
http://www.openinventionnetwork.com/licensees.php

BTW, isn't the S3TC patent now owned by the HTC Corporation?

http://en.wikipedia.org/wiki/S3_Texture_Compression

In September 2011, Intel employee Ian Romanick mentioned that the S3TC patent had been marked as invalid in patent litigation between Apple and HTC, the latter of which acquired S3 and all of their patents. If the patent does prove to be invalid, it would be a simple matter of enabling support for it in Mesa 3D, a popular open source OpenGL-compatible computer graphics library.

HTC Corporation is an OIN licensee (see list linked above).

http://www.openinventionnetwork.com/pat_license.php

Licensee grants license to other current and future licensees

– All licensee patents and applications for the Linux System

Therefore, all OIN licensees can legally enable S3TC in Mesa. Unfortunately, this is not "everyone who makes Linux". So, if the S3TC patent does prove to be valid, one would need to be an OIN licensee in order to have a license to use it in Linux. Since not everyone who uses Mesa is an OIN licensee, and Mesa developers have to assume that it is valid, then they have to leave it disabled by default, and let the OIN licensees enable it if they want to.

[gamerk2]

The closed drivers don't work. They kind-of implement their range of features to a standard (OpenGL, VDPAU, whatever) with quirks and exceptions and straight-out bugs. Because they implement a replacement for most of the layers of the Linux graphics stack, the issues with the Linux graphics stack itself cannot be fixed. Where the Linux world desires to introduce new features in the area of graphics, such as KMS and Wayland, the vendors of the proprietary drivers refuse to co-operate, and try to frustrate such new developments/improvements. New hardware (for Windows 8 machines) may require code signing of the kernel and drivers, and so the proprietary blobs simply won't work at all on new hardware.

The proprietary drivers are quite broken, they can't be fixed by Linux developers themselves, and they hold Linux development back. Everyone involved in Linux, even the graphics card vendors, would be far better off without the proprietary blobs.

Question then: Why do both NVIDIA and AMD drivers work for other OS's then, but struggle so much on Linux, even in BASIC functionallity [such as audio playback and power states].

My point being: Why did it take so bloody long for HDMI audio playback on Evergreen GPUs to be implemented? Its a standard Realtek audio chipset for crying out loud!

Can't help but wonder if the underlying Linux architecture is at fault in some cases...

[archibald]

Question then: Why do both NVIDIA and AMD drivers work for other OS's then, but struggle so much on Linux, even in BASIC functionallity [such as audio playback and power states].

My point being: Why did it take so bloody long for HDMI audio playback on Evergreen GPUs to be implemented? Its a standard Realtek audio chipset for crying out loud!

Can't help but wonder if the underlying Linux architecture is at fault in some cases...

These explanations are already elsewhere on the forums, but here they are again (subject to correction by anybody who knows better than me):

HDMI code couldn't be released because the review of the code developed within AMD said that it presented too much of a risk to the Digital Rights Management on other platforms: if AMD release too much information in areas like this then it might be possible to break the content protection on the board (which would cause the major film studios to find a new common purpose: suing AMD).

Power managament is partly due to lack of developers, partly due to developers being unwilling to work on it when they know that better documentation might be forthcoming.

[johnc]

The closed drivers don't work. They kind-of implement their range of features to a standard (OpenGL, VDPAU, whatever) with quirks and exceptions and straight-out bugs. Because they implement a replacement for most of the layers of the Linux graphics stack, the issues with the Linux graphics stack itself cannot be fixed. Where the Linux world desires to introduce new features in the area of graphics, such as KMS and Wayland, the vendors of the proprietary drivers refuse to co-operate, and try to frustrate such new developments/improvements. New hardware (for Windows 8 machines) may require code signing of the kernel and drivers, and so the proprietary blobs simply won't work at all on new hardware.

The proprietary drivers are quite broken, they can't be fixed by Linux developers themselves, and they hold Linux development back. Everyone involved in Linux, even the graphics card vendors, would be far better off without the proprietary blobs.

The situation is definitely unfortunate but the heart of the problem is that the kernel and the video driver are under two different, incompatible licenses. And it doesn't seem that there's really any good (realistic) way to resolve this issue. There almost needs to be some kind of creative third way to make the two play better together.

Making a stronger nouveau may help to make a "good enough" out-of-the-box experience... but for those of us who really want to get everything out of our video cards (a large majority of NVIDIA customers probably), we're pretty much going to need the proprietary driver... and so none of this really helps us.

On Android, the manufacturers have a relatively narrow, infrequently-changing configuration that they can target (with ICS being a bit of an exception to that). We don't really have that situation in the desktop space unfortunately.

Linux kernel developers don't want nvidias driver code, they want programming specifications.

No IP (especially hardware IP) is divulged by programming specifications, and hence "third-party licensed IP in their drivers and hardware" is not an issue.

This may be true, but I was responding to the people (in this thread and others) who are demanding that there be no binary blobs in Linux... and that NVIDIA should open source their driver code completely. I recognize this may not be a ubiquitous view, or a view that Linus or other kernel devs share, but it is definitely something that many do believe.

[bridgman]

For HDMI, the support under discussion was for the hardware that mixes digital audio onto the HDMI video outputs, not for the audio controller itself. That in turn touches on a large number of consumer standards, and while it seemed intuitively obvious that we should be able to release the code Alex implemented it turned out to be a lot harder than expected.

We went through legal review a few times (and learned a lot about HDMI licensing along the way), cutting the code down a bit more each time, but never got to the point where we had something that seemed to work from a licensing perspective. Once zajec started working on the audio support we looked for a fast way to help, cut the code down to just register definitions and snippets, then took that through review and released it.