Open-Source NVIDIA Driver Goes Stable On Linux 231
An anonymous reader writes "The open source Nouveau driver, a reverse-engineered incarnation of NVIDIA's official proprietary driver for Linux, has reached its biggest milestone. The Nouveau driver is now being considered stable within the Linux kernel and leaving the staging area, with the pledge of a stable ABI. Phoronix has summarized the state of the Nouveau driver, which works fine if you don't care about performance or are fine with running hardware that's a few generations old."
Nothng but Hate (Score:5, Insightful)
It's amazing to me that there is so much flame out there for this. None of you could do this, Not a single one of you have tried, and yet, this small group of dedicated people have actually figured out a piece of proprietary hardware to the point of having their code included in the Linux kernel? Way to go guys.
Software freedom trumps proprietorship every time. (Score:5, Insightful)
Software freedom is important for its own sake. You're better off with a less functional free implementation than a more powerful and reliable proprietary implementation in numerous practical ways programmers and users have known for decades.
If the proprietor stops supporting something and they're all you've got to depend on, you're out of luck left with an ugly choice to run increasingly obsolete code or (apparently needlessly) do without that functionality at all. Proprietors control your computer and tell you what you can do with it. Free software gives you the freedom to control your own computer. One can learn to program and understand the Nouveau source code: maintain the code to work on more OSes and work with more hardware, free from the fear of DRM (digital restrictions management). If you're not a programmer, like most computer users aren't, you can still help the effort by giving programmers what they need to help you in return. Often that's money, equipment, good bug reports, documentation translations, and writing documentation for the software.
We're better off relying on each other in freedom than we are depending on a proprietor. Socially, we can't build a better future for ourselves by relying on secret software. We should be allowed to fully own and control our computers and we'll get there with software freedom.
Nvidia should have told their customers how to fully use the equipment they sold. Nouveau hackers are remedying that deficiency. I'm grateful for the valuable work Nouveau hackers are doing for all of us.
Why all the hate /.? (Score:5, Insightful)
Seriously guys why all the hate? Sure it doesn't work for everyone, it works on old hardware. But here's the deal, it works and is sufficient for day to day use. Here's the amazing and nerdy part of it too, they REVERSE ENGINEERED IT. Something as complicated as a video card. That's no small feat and they should be congratulated for their efforts to make linux just that much better. Start hating when you contribute something with any significance at all. BTW I'm not a kernel developer, just a nerd that appreciates a feat such as this.
No, nVidia isn't stupid (Score:5, Insightful)
They realize their top notch drivers are a big selling point of their hardware. You'll find more than a couple people who have the opinion that AMD has good graphics hardware, crippled by poor drivers.
nVidia will only discontinue Linux drivers if the market shrinks to such a size that it is no longer worth it. If Linux becomes an "embedded only" OS or something they'll stop. However so long as it is being used a reasonable amount, they'll keep making drivers for it (they also have FreeBSD and Solaris drivers to give you an idea).
Particularly since it is a big market for their GPGPU stuff. When people get a big multi-card Tesla system, they sometimes want to run Linux on it. That is only doable with first flight drivers that have all the features supported, work with the latest hardware, and give up nothing in terms of speed.
Re:No, nVidia isn't stupid (Score:5, Insightful)
Don't forget that render farms are a major franchise for NVidia and Linux pretty much owns that space.
Your comments could've been said in 1991 of Linux (Score:5, Insightful)
Re:"a reverse-engineered incarnation" (Score:5, Insightful)
Now for my other question, since you are basically snatching the data from a binary blob which i'm sure is full of proprietary code, after all if it wasn't they could just FOSS the thing, do you worry about DMCA? i know that AMD can't release full specs on their GPUs because protected path isn't theirs and would break DMCA and since Nvidia cards i'm sure have protected path as well do you have to worry about legal ramifications? or have you set up the project in some place that doesn't recognize software patents?
What nouveau development does is feed data through the API and look at the I/O ports and what data they get. The developers are feeding data they "own" [e.g. the address of a frame buffer they created] and then retrieving it after it is transmuted. Virtually all devices in a system (e.g. disk controllers, etc.) have a port list so just having that is not novel (i.e. not patentable). Since nVidia isn't publishing a document on the port list, no copyright either. Might be claimed as a proprietary trade secret, but it's okay to reverse engineer in this manner [reverse engineer is a protected activity under the right "clean room" circumstances].
The "clean room" methodology has been court tested many times. In this instance, we have three groups that do not communicate, except in controlled ways. Group A does the above "port probing" and writes a document of their findings. Group B writes an API document using only Group A's report. Group C uses the API document generated by Group B to write the device driver code.
If you ARE Mr Peres I would like to say I admire your guts, frankly I wouldn't want to go within 100 yards of anything to do with video as long as all these crazy patents and lawsuits are going on. And how about hardware acceleration of video? How can you do that without ending up in the whole H.26x patent minefield?
No doubt nVidia has a license to H.264 patents. Under the exhaustion doctrine, anyone can benefit from using the API to output H.264 video. If that were not the case, any end user [even using nVidia's proprietary driver], would be required to pay H.264 patent licensing fees. Likewise for the use of one's home entertainment system.
However, that doesn't mean some folks don't try. Lodsys [a patent troll] licensed a patent to Apple. Apple incorporated the technology under an API that software developers can use. Lodsys has been trying to extract license fees from all software developers that use the Apple API. Apple is intervening in court to stop Lodsys using the exhaustion doctrine as the basis for their challenge against Lodsys in defense of the developers.
Frankly I think its a shame that such questions even have to be asked as while i have no problems with proprietary software and use both FOSS and proprietary software every day i do NOT support software patents but as long as that minefield exists I am curious how you intend to approach feature parity with the blob driver without stepping into the whole patent mess since one of the big uses of GPUs is video processing and that's patented up the wazoo.
It's not so much the patent mess (as I mentioned above), but rather the difficulty of deducing the port list, API doc, etc. using the clean room method. The 2D case is [relatively] easy enough. The 3D case [with a large number of acceleration modes, etc.] is a lot more work, many more test cases, etc. Sheer scope of such an undertaking is the biggest limiting factor.
Re:"a reverse-engineered incarnation" (Score:5, Insightful)
Congratulations, you are an idiot!
On Linux, you have a small piece of proprietary software running on an open source system entirely controlled by the developer. Most of reverse engineering is non-interactive, by running a driver/hardware combination while its interactions are watched by other software.
On Windows, everything but your own code is proprietary, including reverse-engineering tools themselves, and you have no way to modify most of the environment or include any kind of automated logging. You are pretty much forced to single-step through giant blobs while watching disassembled code in a multitude of little windows.