The abrupt merging of Nouveau
Dave Airlie probably thought he had enough on his plate when he generated
the DRM pull request for 2.6.33. This tree
contained 203 commits touching 122 different files, and adding over 9,000
lines of code. One of the key features aimed at the kernel is the new
"page flipping ioctl()," helpfully described in the commit message
as "The ioctl takes an fb ID and a ctrc ID and flips the crtc to the
given fb at the next vblank.
" In English, it means that a specific
video output can be quickly switched from one region of video memory to
another, allowing for clean video changes without the "tearing" that
results from display of a video buffer which is being changed.
Other changes for DRM this time around include support for Intel's "Ironlake" GPU and "Pineview" Atom processor, and a great deal of work supporting kernel mode setting on Radeon GPUs. Radeon, it seems, only lacks good power management support at this point; it will likely lose its "staging" designation before the end of this development cycle.
Linus was not impressed by any of that, though. Instead, he had one concern: the fact that the Nouveau driver - a reverse-engineered driver for NVIDIA chipsets - was not a part of the pull request. Nouveau had been discussed at the 2009 Kernel Summit, and it was generally agreed that this code should find its way into the mainline as soon as possible. 2.6.33 is the first merge window since the summit, and Linus clearly had expected some action on that front. When he didn't get it, he made his disappointment known.
One might wonder what the problem with Nouveau was. The world is full of out-of-tree Linux drivers; recent efforts have reduced their number considerably, but they still exist and Linus does not normally complain about them. Certainly Nouveau has a higher profile than most other out-of-tree drivers; it is the only hope for a free driver for a large percentage of available machines. But the real problem is that Fedora (at least) has been shipping this driver without doing enough (in Linus's opinion) to get it upstream. In Linus's words:
But not only is Fedora not following the rules, I know that Fedora people are actively making excuses about not following the rules. I know Red Hat actually employs (full-time or part-time I have no idea) some Nouveau developer, and by that point Red Hat should also man up and admit that they need to make "merge upstream" be a priority for them.
A number of reasons for the non-merging of Nouveau have been given, ranging from "not ready yet" and "unstable user-space API" to "we haven't found the time yet." The real blocker in recent times, though, has been the binary blob loaded into some NVIDIA GPUs by the driver. This chunk of code, known as the "voodoo" or "ctxprogs," was obtained by watching the proprietary drivers in action. Since nobody in the Nouveau project wrote this code, nobody has been willing to sign off on it; it's not at all clear that it can be legally distributed. Linus has not been impressed by this reason either, but the fact remains: developers take the Signed-off-by: line seriously and are not willing to attach it to something which might be legally questionable.
The obvious answer, one which has been applied in other situations, is to pull the firmware out of the driver and load it into the kernel at run time. And that is exactly what happened with Nouveau: Ben Skeggs put in an intensive effort to remove ctxprogs and use the firmware loading API to get it when the driver loads. Dave then put together the "DRM Nouveau pony tree" and requested that it be pulled for 2.6.33. Linus, of course, did exactly that.
Potential users will still have to get the "ctxprogs" from elsewhere. For whatever reason, pointers to "elsewhere" are hard to find, but your editor happens to know that the firmware can be found in the Nouveau git tree. Simply grabbing the right version and placing it in the local firmware directory should be sufficient.
All of this marks significant progress for Nouveau, but a dependence on firmware of dubious origin is likely to inhibit the adoption of this driver in the long term. So it was good to learn (via an LWN comment posting) that the contents of the ctxprogs blob are not quite as obscure as many of us had thought:
It seems that things are moving quickly on this front too; on December 15, Ben announced the availability of a replacement firmware for NVIDIA GeForce 6/7 hardware. This is a first posting for this code; doubtless testers will encounter some problems. But it sounds very much like the hardest problems have been overcome, at least for this particular variant of the hardware. With luck, NVIDIA's firmware will not be needed for much longer. In the longer term, it might even turn out to be possible to program interesting functions into the hardware, extending its capabilities in surprising ways.
Once upon a time, Linux users had to be very careful about which hardware
they bought. Over the years, most of those problems have gone away; it is
now easy to find systems which are completely supported by free software.
One of the biggest exceptions has been in the area of graphics. Vendors
like Intel and ATI/AMD have made the decision that their hardware should be
supported with free drivers (most
of the time) and have invested resources to make that
happen. NVIDIA has been rather less cooperative, and support for its
hardware has suffered accordingly. It would appear that the driver problem
is getting close to a solution, but we should never forget the effort which
was required to get to this point. NVIDIA would be far more worthy of our
future commercial support if it had not made that effort necessary.
| Index entries for this article | |
|---|---|
| Kernel | Device drivers/Nouveau |
| Kernel | Nouveau |
Posted Dec 15, 2009 20:47 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (9 responses)
References:
-jef
Posted Dec 15, 2009 20:50 UTC (Tue)
by corbet (editor, #1)
[Link] (8 responses)
The real point being that, while said work has held things up in the past, it was not blocking the merge for 2.6.33.
Posted Dec 15, 2009 20:56 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (5 responses)
All I am suggestion is that if you are going to quote Linus verbatim you should be be quoting Dave's rebuttal in an effort to show some balance... because the truth of the situation is tied up in the communication between those two people. If you aren't making an effort represent the dialog between the two of them..then you are misrepresenting the truth.
-jef
Posted Dec 15, 2009 21:30 UTC (Tue)
by corbet (editor, #1)
[Link] (3 responses)
Now, it could have been about the technical history of Nouveau, though LWN has covered that before. It could also have been about the legitimacy of Fedora shipping a driver that it had no intention of merging, but that didn't seem interesting. I wanted to talk about this week's events and the future.
If I have badly misrepresented things, I apologize.
Posted Dec 15, 2009 22:01 UTC (Tue)
by jspaleta (subscriber, #50639)
[Link] (1 responses)
You could have just focused on the posts in the thread that talked to the current legal problems concerning signing off on the binary blob as part of a merge. Both of the Dave Arlie references I gave above include some discussion about the sign-off issue which you could have selectively quoted from. There's something significantly important there I think in the premise that Red Hat legal review has a higher bar to meet on sign-off into the upstream kernel than what is required to include in Fedora.
And if you wanted to be overly sensational there's the short lived Alan/Linus sidebar discussion concerning what the agreed on rules concerning sign-off and merge actually are such as the following:
-jef
Posted Dec 15, 2009 23:00 UTC (Tue)
by jwboyer (guest, #23296)
[Link]
Posted Dec 15, 2009 22:13 UTC (Tue)
by rahvin (guest, #16953)
[Link]
Posted Dec 16, 2009 12:21 UTC (Wed)
by alex (subscriber, #1355)
[Link]
In this case I agree with Jon, the focus of the article was fine.
Posted Dec 15, 2009 22:01 UTC (Tue)
by Tracey (guest, #30515)
[Link] (1 responses)
As much as I wanted to be able to use the nouveau driver I couldn't; it just wasn't ready(tearing, crashing. etc).
When time is permitting, I like to test out new things, and I've been trying to stay on top of fedora's nouveau drivers(usually getting the rawhide versions): but I still haven't been able to get the newest nouveau drivers from fedora to work.
For fedora users there are two ways to get decent 3d graphics to run on newer(past 3-4 years) nvidia cards. The first one is to go to nvidia's site and download nvidia's drivers, which I have avoided for a few years now. The second way is to use the rpm-fusion repository and install the nvidia drivers in a way that(I find) is less intrusive to the system.
I can understand red hat's position on this: That binary blob belongs to nvidia. The red hat / fedora developers have their hands tied on this. Unless Linus has some personal assurance from nvidia that nvidia won't be it's usual jerky self; distributing nvidia's property is not a good thing.
Posted Dec 15, 2009 22:47 UTC (Tue)
by nybble41 (subscriber, #55106)
[Link]
In any event the Nouveau team appears to be well on their way to creating their own replacement, which should make the uncertain legal status of the captured blob irrelevant.
Posted Dec 15, 2009 21:25 UTC (Tue)
by ajb (subscriber, #9694)
[Link] (7 responses)
Posted Dec 15, 2009 21:28 UTC (Tue)
by corbet (editor, #1)
[Link] (6 responses)
Next time please just send us an email at lwn@lwn.net? That helps to keep the comment tree cleaner and more interesting.
Posted Dec 15, 2009 23:01 UTC (Tue)
by chrish (guest, #351)
[Link] (5 responses)
Just a suggestion.
Posted Dec 15, 2009 23:09 UTC (Tue)
by corbet (editor, #1)
[Link] (3 responses)
Posted Dec 16, 2009 16:53 UTC (Wed)
by Trelane (subscriber, #56877)
[Link] (1 responses)
Posted Dec 20, 2009 3:44 UTC (Sun)
by giraffedata (guest, #1954)
[Link]
But here in the comment editor I see the line is now there!
Posted Dec 31, 2009 13:45 UTC (Thu)
by speculatrix (guest, #62766)
[Link]
:-D
Posted Dec 17, 2009 4:23 UTC (Thu)
by daniels (subscriber, #16193)
[Link]
Posted Dec 15, 2009 23:02 UTC (Tue)
by MattPerry (guest, #46341)
[Link] (10 responses)
Then let Linux sign off on it if he's so eager to get it in there. I can't blame the Nouveau developers for not wanting to sign off on that binary blob.
Posted Dec 15, 2009 23:02 UTC (Tue)
by MattPerry (guest, #46341)
[Link] (9 responses)
Posted Dec 15, 2009 23:10 UTC (Tue)
by alextingle (guest, #20593)
[Link] (4 responses)
Posted Dec 16, 2009 0:22 UTC (Wed)
by dirtyepic (guest, #30178)
[Link] (3 responses)
Posted Dec 16, 2009 6:57 UTC (Wed)
by quotemstr (subscriber, #45331)
[Link] (2 responses)
Posted Dec 16, 2009 19:24 UTC (Wed)
by dwheeler (guest, #1216)
[Link] (3 responses)
Posted Dec 16, 2009 20:28 UTC (Wed)
by dkg (subscriber, #55359)
[Link] (2 responses)
Posted Dec 17, 2009 6:03 UTC (Thu)
by TRS-80 (guest, #1804)
[Link]
Posted Dec 24, 2009 21:56 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Dec 15, 2009 23:20 UTC (Tue)
by Banis (guest, #59011)
[Link] (61 responses)
In short, Redhat makes the choice to not ship fully functioning drivers for Nvidia hardware. Since other OS vendors are able to do so it would seem the problem resides within Redhat not Nvidia.
Posted Dec 16, 2009 0:00 UTC (Wed)
by eli (guest, #11265)
[Link]
Posted Dec 16, 2009 0:25 UTC (Wed)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Dec 17, 2009 21:12 UTC (Thu)
by louai (guest, #58033)
[Link] (1 responses)
Posted Dec 24, 2009 16:28 UTC (Thu)
by glup (guest, #62317)
[Link]
Catalyst is improving fast and AMD is clearly seeing the linux market as something that they should invest to. Too bad Catalyst development model is a lot slower than what nvidia appears to have. It loosk a lot like nvdia is using better version control system for parallel development. :)
Posted Dec 16, 2009 0:27 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (41 responses)
So, when your kernel crashes because of the binary nonsense from Nvidia, how exactly are Linux developers or Red Hat supposed to help you without access to the source code?
The rules in the Linux kernel are open source. These are the only rules that matter here.
Nvidia are full of shit, IMHO. If they are worried about copyright, they have no case. Stuff has been reversed engineered, so the value of what they wrote already diminished significantly. If they are worried about patents, they can always give an IBM style licence, that covers their stuff for anyone that ships under and open source licence. Then they'll know nobody can take their precious stuff and run. If they are worried about trade secrets, see reverse engineering once again. In short, they would sell more graphics chips/cards if they decided to open source their stuff. It will not hurt their Windows business one bit.
Two other graphics vendors, Intel and AMD, are doing open source. Nvidia have no excuse.
Posted Dec 16, 2009 3:29 UTC (Wed)
by dbenamy (guest, #39458)
[Link] (40 responses)
Posted Dec 16, 2009 3:35 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (2 responses)
Posted Dec 16, 2009 7:43 UTC (Wed)
by Bluehorn (subscriber, #17484)
[Link] (1 responses)
I guess, AMD and Intel are big enough to own patent pools which make it possible to defend against patent lawsuits. Of course, they will still have a hard time against patent trolls.
It's probably just balancing free drivers vs. the risk of patent lawsuits. Maybe Nvidia knows they are violating a patent and don't want to disclose it?
Posted Dec 16, 2009 21:18 UTC (Wed)
by bojan (subscriber, #14302)
[Link]
Posted Dec 16, 2009 4:30 UTC (Wed)
by elanthis (guest, #6227)
[Link] (34 responses)
It has to do with market strength. Video drivers -- especially Open ones -
The ATI hardware is damn nice. Intel's hardware is even pretty damn well
NVIDIA giving up their driver tech will literally level the playing field.
Why would a company possibly want to do that for absolutely no gain?
The Free Software camp will claim this is unethical of NVIDIA. If NVIDIA
If and when the Open Source drivers become a commodity -- much like Open
In other words, until ATI's drivers can trounce NVIDIA's, NVIDIA is not
Open drivers' advantages are pretty low compared to NVIDIA's (on the
Posted Dec 16, 2009 5:40 UTC (Wed)
by cventers (guest, #31465)
[Link] (8 responses)
I think it is entirely appropriate that the FOSS community should apply any and all forms of leverage available to alter the driver landscape in a way that favors our open development practices. It's great to do that in collaboration with the manufacturers, but for those that stand in the way of progress, all options should be on the table.
I'm a strong capitalist, which means that I recognize the real end of capitalism isn't so much about turning a monetary profit but is more about driving the marginal cost of everything towards zero... to not have to work for the things we want. We should want to commoditize the driver market, the same way we've done for other markets.
Posted Dec 16, 2009 8:19 UTC (Wed)
by jmm82 (guest, #59425)
[Link] (7 responses)
Open Source DOES try and force hardware vendors to distribute their code,
I would guess until enough of the market share shifts to open source for
Again I just made this up so I expect to be corrected, but I do not see the
IMO Open Source is Socialism and Red Hat(etc.) is the government. It just
Ubuntu 9.10 Flash driver issue. I finally fixed it after three hours, but
I did not mean to write this much or be offensive to Red Hat or Intel which
Posted Dec 16, 2009 12:15 UTC (Wed)
by cventers (guest, #31465)
[Link] (6 responses)
Socialism doesn't work with scarcity. But ideas are free!
Posted Dec 16, 2009 17:49 UTC (Wed)
by drag (guest, #31333)
[Link] (5 responses)
Pretty much everything works better when individuals are allowed to do as
"Socialism" in the way that it means that people work together and
It's when you start creating rules and people try to exert authority over
The basic take-away is that when you put a small amount of people in charge
Posted Dec 20, 2009 4:08 UTC (Sun)
by giraffedata (guest, #1954)
[Link] (4 responses)
I don't see where socialism enters into the open source situation.
Socialism requires a central government to determine what each person's contribution to society should be (and enforce it). There isn't anything like that in open source.
I do see a social responsibility or altruism angle, where someone voluntarily contributes code or licenses with GPL in order to bring about a better world for everyone, but that's basically welfare, which goes hand in hand with capitalism, not socialism.
Posted Dec 20, 2009 4:21 UTC (Sun)
by jmm82 (guest, #59425)
[Link]
Posted Dec 24, 2009 22:15 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (2 responses)
Actually, it's probably better described as Stalinism - where the government takes everything in the name of the people and then the elite use it as their own personal property.
Just like fascism, in fact.
In fact, also pretty much like the current "capitalist" setup - where the government and their cronies are walking off with all our money TODAY. What are the recent boom and current bust iof not yet another means for the already-rich to get even richer?
Cheers,
Posted Dec 26, 2009 21:21 UTC (Sat)
by giraffedata (guest, #1954)
[Link] (1 responses)
Neither socialism, communism, nor capitalism imply that government employees take stuff that rightfully belongs to others or that rich people get stuff that rightfully belongs to non-rich people, so whether that's in fact what happens when societies attempt to set up these economic systems, it really isn't relevant to the question of whether the existing open source economy is socialist, capitalist, or whatever.
Posted Jan 19, 2010 20:29 UTC (Tue)
by personman (guest, #63100)
[Link]
Posted Dec 16, 2009 6:25 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (18 responses)
I have no idea how accurate this is:
http://www.behardware.com/news/10342/market-share-for-gra...
But, it doesn't seem to support Nvidia being far ahead of the competition based on the drivers with secret sauce. The criteria used when selecting a graphics solution for a particular machine is complex, I'm quite sure. It cannot be reduced to who's got a better driver. And it is rarely made by the end user (only enthusiasts do that).
When it comes to Linux, binary only drivers are dreck. Every time you have a problem with your kernel, the first question by support is: is it tainted? If yes, you are out of luck, because nobody's going to touch your problem with a ten foot pole.
Posted Dec 16, 2009 10:24 UTC (Wed)
by ikm (guest, #493)
[Link] (6 responses)
Posted Dec 16, 2009 11:02 UTC (Wed)
by nye (subscriber, #51576)
[Link] (5 responses)
Add me to that list.
I like to play games occasionally so I need drivers that provide reasonable accelerated 3D performance without huge amounts of work, or problems with instability. If the drivers were up to scratch I'd happily switch to ATI, but it looks like that's years away, and I'm not even sure that gap is actually closing.
Posted Dec 16, 2009 21:23 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (4 responses)
Posted Dec 16, 2009 21:35 UTC (Wed)
by ikm (guest, #493)
[Link] (3 responses)
Posted Dec 16, 2009 22:08 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (2 responses)
Posted Dec 16, 2009 22:37 UTC (Wed)
by ikm (guest, #493)
[Link] (1 responses)
Posted Dec 16, 2009 23:13 UTC (Wed)
by bojan (subscriber, #14302)
[Link]
Posted Dec 16, 2009 14:18 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (10 responses)
On the other hand, sometimes my favorite distribution decides it's time to get rid of this binary driver that was working very well, and time for me to become a beta-tester of this half-baked open source replacement that keeps crashing.
As soon as my PC crashes, an squad of experienced and talented kernel developers with nothing better to do with their life immediately notices that my kernel is not tainted. After a few minutes they knock on my door. They immediately identify the faulty driver, track down the bug to this hardware configuration of mine they had never seen before, write and test the appropriate patch, re-compile the kernel for me and install it on my machine. While leaving, they thank me so much for being such a helpful beta-tester and good open-source citizen.
Please give me a break. I like the open-source ideology. I really do - as long as it does not "taint" facts.
Posted Dec 16, 2009 21:20 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (9 responses)
Posted Dec 16, 2009 22:24 UTC (Wed)
by tseaver (guest, #1544)
[Link] (1 responses)
Posted Dec 16, 2009 23:28 UTC (Wed)
by bojan (subscriber, #14302)
[Link]
Look, I understand that if things don't work with the current open source driver, people will run proprietary drivers. I did exactly that for many of my users (example: before nouveau, there was nv, which didn't have good support for dual head, so I _had_ to give my users Nvidia driver so that they can use the second screen).
But, but, but... If Nvidia released their driver as open source when they should have, everyone would have a better solution and it would be fully supported by kernel devs too. The only reason all this stuff had to be painfully reverse engineered is because Nvidia refuse to do the right thing. So, yeah, of course it's not as good as Nvidia stuff (yet). The guys working on nouveau are doing heroic work, IMHO.
*) You can look at kernel bugzilla and verify that many people running Debian, Ubuntu, Fedora etc. kernels _do_ get their problems heard and resolved. You can also verify that in e.g. Red Hat bugzilla, indeed, kernel developers employed by Red Hat help users regularly. The patches usually end up being applied upstream.
Posted Dec 17, 2009 10:29 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (6 responses)
If you are an average Joe then you will never get help, open-source or not.
If you are a big company willing to pay then you can get help sometimes, open-source or not.
Of course open-source is much much better for all types of consumers *in the long term*. But when you have a piece of hardware to get working *right now* it does not really matter.
Posted Dec 17, 2009 22:52 UTC (Thu)
by bojan (subscriber, #14302)
[Link]
Bullshit.
Posted Dec 18, 2009 8:15 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (4 responses)
That's not my direct experience. If I (as an individual user) interact
nicely with the Open Source maintainers - i.e. get the information they
ask for as fast as I can, describe the bug not my idea of the fix, and
generally follow Simon
Tatham's guide to bug reporting - I get solutions to my problems. This
is far better than I ever got from a company issuing binary
drivers.
Posted Dec 18, 2009 14:29 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (3 responses)
Did it cross your mind that the average Joe does not even speak English?
Posted Dec 18, 2009 14:39 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (2 responses)
So let's get this straight: the average Joe doesn't speak English, yet is able to (somehow) navigate an English-only driver download site, and follow binary driver install instructions, that only come in English? Yet, they're incapable of finding enough help with English to file useful bug reports?
I've done my share of helping non-English speakers work through a non-technical friend who speaks both (usually very bad) English and their language file decent bug reports. Generally, it's not too difficult - Google Translate and similar software tools work well in finding the words needed to describe symptoms, and the technical information is cut-and-paste only anyway, and usually incomprehensible to English speakers, too. Heck, I've even had the fun of working entirely through Google Translate to find a bug; IME, open source driver developers are quite happy to work with you over a language barrier, so long as you're happy to try and make things work.
Posted Dec 18, 2009 17:23 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (1 responses)
Are you aware that some Linux distributions ship binary drivers, or make their installation just a few native language clicks away?
Posted Dec 18, 2009 17:41 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
Are you aware that distributions where someone has bothered to translate packages from English to another language are also distributions where you can interact with speakers of that language on the distribution bugtracker? What's more, the people you interact with, in your language, are generally helpful in getting your bug report into shape, then translating it and funnelling information between your language and the developer's preferred language.
Seriously, I've seen bug reports handled and fixed from distributions I didn't even know existed, precisely because I don't even know the writing system used by the distro's native language, let alone the language. But, someone who spoke the right language took a report from their bug tracker, did some basic triage, determined it was a genuine bug, and sent the report upstream, with a note explaining that it was all machine translated, and apologising for the poor English. A back and forth ensued, getting technical data from the bug reporter, and the bug got fixed.
Posted Dec 16, 2009 6:36 UTC (Wed)
by eru (subscriber, #2753)
[Link] (1 responses)
Would it really? Drivers are by definition hardware-dependent. ATI hardware would be sufficiently different from NVIDIA hardware that little of the NVIDIA driver code would be useful there, and porting attempts could probably produce buggy and inefficient code.
One thing I find interesting is this situation sets up almost a controlled test of open source vs proprietary development: Assuming ATI and Intel have provided full hardware info (and continue to do so for new hardware in the future), the supposed superiority of the open process should eventually produce superior Linux drivers for them.
Posted Dec 16, 2009 6:55 UTC (Wed)
by quotemstr (subscriber, #45331)
[Link]
But drivers need to expose OpenGL and DirectX interfaces to applications, but GPUs are simply highly parallel processors capable of generic computation. The portion of the driver that implements these APIs in terms of the generic facilities all GPUs provide is almost certainly useful across disparate hardware.
Posted Dec 16, 2009 9:53 UTC (Wed)
by smurf (subscriber, #17840)
[Link]
We don't ask them to give up any driver tech. They need not disclose a single byte of code.
We only need (or want, really) the hardware specs, firmware opcodes, things like that.
Posted Dec 16, 2009 23:31 UTC (Wed)
by mikov (guest, #33179)
[Link]
Posted Dec 22, 2009 0:58 UTC (Tue)
by ceplm (subscriber, #41334)
[Link] (1 responses)
Posted Dec 22, 2009 9:38 UTC (Tue)
by Kamilion (subscriber, #42576)
[Link]
As a hardware geek, I can tell you, I've crashed the nvidia driver hundreds of times in a *DAY* just trying to find a stabilized overclock -- and considering nVidia has classically been the Chip of The Overclocker, it does not surprise me in the least to see nVidia as the leading cause of vista crashes when the G80 was released.
... What scares me more than pie charts is that Microsoft has automated collection of millions of machines, all dumping into these huge QA databases, and NOBODY seems to stop and think, "Hey, Quickbooks just crashed and Windows wants to send a partial memory dump to Microsoft's QA database..."
Someday, some sneak's going to mine that DB for all it's worth. That'll be one interesting day. There could be just about anything in there, considering the general quality of the 3rd party code in that ecosystem.
Posted Dec 16, 2009 16:56 UTC (Wed)
by Trelane (subscriber, #56877)
[Link] (1 responses)
Posted Dec 16, 2009 21:34 UTC (Wed)
by bojan (subscriber, #14302)
[Link]
Posted Dec 16, 2009 1:11 UTC (Wed)
by gdt (subscriber, #6284)
[Link]
It was never that easy -- for a long time there was a tradeoff between going with the graphics performance but higher maintenance costs of NVIDIA hardware and their closed-source software, or choosing a lesser performing option with open source's better maintainability (ie: Intel). But now that conventional wisdom is a mess. NVIDIA hardware is well off the pace, likely to get worse, and the company's ongoing survival is risk to the ongoing maintenance which their closed-source drivers require. Intel changed their graphics engine for PowerVR and offer a closed-source driver with poor software maintenance. Intel have just cancelled their own graphics core and are yet to describe the future direction of Intel graphics hardware. That leaves ATI/AMD. Nice hardware for this generation and looking good for the next. The open source driver seems to be coming along well, with the manufacturer issuing programming specifications. AMD are starting to look good as the choice for Linux systems, offering both performance and maintainability, a combination we haven't seen together for a very long time. [And no, I'm not a fanboi of any of the above. I've got a lot of respect for Intel's contributions to X, and still find it difficult to think that any company could be so silo-ed such that one part of the business could so comprehensively counter the strategic direction of another part of the same company. I'm also very impressed by the technical achievement which is NVIDIA's driver: a lot of what X is currently doing already exists in the NVIDIA driver. But the thought of NVIDIA's finances forcing the abandonment of that driver, and thus being tied to a particular historic Linux distribution, is just scary to administrators of large cutting-edge desktop installations. In a sense, that serves the CGI firms right -- if they had requested an open source driver in the past then it would have happened, now they reap the consequences of that lack of foresight.]
Posted Dec 16, 2009 1:47 UTC (Wed)
by josh (subscriber, #17465)
[Link] (4 responses)
Posted Dec 16, 2009 4:19 UTC (Wed)
by kragil (guest, #34373)
[Link] (3 responses)
Posted Dec 20, 2009 9:27 UTC (Sun)
by johnflux (guest, #58833)
[Link] (2 responses)
Posted Dec 21, 2009 12:13 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Dec 22, 2009 15:43 UTC (Tue)
by hammers (guest, #62633)
[Link]
Really ? You used to work for IMG ? And you come out with a comment like that ?
Really ??
Posted Dec 16, 2009 6:39 UTC (Wed)
by SEJeff (guest, #51588)
[Link] (2 responses)
Cluebat, you just got hit with it.
Posted Dec 16, 2009 8:30 UTC (Wed)
by alankila (guest, #47141)
[Link]
I am hoping that with nvidia there will remain the opportunity to use the proprietary driver even if nouveau is able to drive the same thing. More choice is for the better, even choice between free and closed.
Posted Dec 19, 2009 14:25 UTC (Sat)
by anton (subscriber, #25547)
[Link]
Why did ATI change their policy in the unwelcome direction? Maybe
the market force of the free software users is not big enough (or at
least ATI management thought so); many Linux users obviously care
little for free software and bought Nvidia based on the availability
of their proprietary driver.
Why did AMD change the policy in the welcome direction? Apparently
the market force of the free software users is big enough for AMD to
care, even if ATI didn't.
Posted Dec 16, 2009 9:10 UTC (Wed)
by niner (subscriber, #26151)
[Link] (2 responses)
So now I switched to an ATI/AMD card with free radeon drivers and finally,
Posted Dec 16, 2009 11:12 UTC (Wed)
by nye (subscriber, #51576)
[Link] (1 responses)
It must be obvious that such problems are not normal, or nobody would be able to use that hardware.
Posted Dec 16, 2009 11:42 UTC (Wed)
by niner (subscriber, #26151)
[Link]
Both problems were acknowledged and conscious decisions by the developers.
Well I did not. I bought hardware (Radeon HD 4870) that at least has some
Posted Dec 31, 2009 2:04 UTC (Thu)
by robert_s (subscriber, #42402)
[Link] (2 responses)
Ah, so you're suggesting Redhat should ship operating systems they are unable to debug and properly support.
Posted Dec 31, 2009 3:02 UTC (Thu)
by foom (subscriber, #14868)
[Link] (1 responses)
Posted Dec 31, 2009 7:47 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Dec 16, 2009 0:51 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (14 responses)
Posted Dec 16, 2009 2:35 UTC (Wed)
by dlang (guest, #313)
[Link] (13 responses)
it's not merging tux on ice (I'm not sure that's a good thing anyway), but it is yet another case of him pointing out that this is not as complicated as it is being made out to be. If he does this enough something will snap (which may be Linus writing his own suspend code and merging it as on option, such things have happened before)
Posted Dec 16, 2009 3:01 UTC (Wed)
by bojan (subscriber, #14302)
[Link] (2 responses)
I'll also bet $5 that the whole thing would have been improved faster, had Linus decided to involve Nigel directly, by merging TuxOnIce.
Instead we have the uswsusp kludge (1000 moving parts or something?) and the old, slow and ugly swsusp. I hope Linus really gets annoyed one of these days :-)
Posted Dec 16, 2009 5:16 UTC (Wed)
by cventers (guest, #31465)
[Link] (1 responses)
Posted Dec 16, 2009 6:56 UTC (Wed)
by bojan (subscriber, #14302)
[Link]
Posted Dec 16, 2009 9:32 UTC (Wed)
by mjthayer (guest, #39183)
[Link] (9 responses)
For suspend to disk, I can see the difficulties - taking a clean snapshot of user space, where you
Posted Dec 16, 2009 10:46 UTC (Wed)
by rsidd (subscriber, #2582)
[Link] (6 responses)
On my current machine, suspend-to-RAM is all I need. Though suspend-to-disk (uswsusp, not tuxonice) works too.
Posted Dec 16, 2009 11:03 UTC (Wed)
by mjthayer (guest, #39183)
[Link] (5 responses)
Posted Dec 16, 2009 13:33 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
Posted Dec 16, 2009 13:47 UTC (Wed)
by mjthayer (guest, #39183)
[Link] (3 responses)
Posted Dec 16, 2009 14:53 UTC (Wed)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Dec 17, 2009 18:39 UTC (Thu)
by mjthayer (guest, #39183)
[Link] (1 responses)
Posted Dec 17, 2009 18:49 UTC (Thu)
by mjg59 (subscriber, #23239)
[Link]
Performing a full resume cycle is hard. You need to reprogram the memory controller, bring the
Posted Dec 16, 2009 11:59 UTC (Wed)
by nhippi (subscriber, #34640)
[Link]
And that is how things are done in ARM land. Some machines go even further
> and if there is too much hardware that you don't know you can reliably
Using VGA bios for display adapters was kinda mandatory before Kernel
Posted Dec 16, 2009 20:42 UTC (Wed)
by mgedmin (subscriber, #34497)
[Link]
IIRC Matthew Garrett had a very nice explanation on his blog, but I cannot
Posted Dec 16, 2009 14:02 UTC (Wed)
by iznogood (guest, #51845)
[Link] (6 responses)
Posted Dec 16, 2009 15:17 UTC (Wed)
by nye (subscriber, #51576)
[Link] (5 responses)
Posted Dec 16, 2009 17:28 UTC (Wed)
by iznogood (guest, #51845)
[Link] (4 responses)
Posted Dec 16, 2009 22:07 UTC (Wed)
by airlied (subscriber, #9104)
[Link] (3 responses)
They can also tell from running the program and watching its inputs and outputs, so they can see what register state ends up where in the saved context and work out what bits of the program copied it there etc.
Posted Dec 16, 2009 22:29 UTC (Wed)
by iznogood (guest, #51845)
[Link] (2 responses)
The main question is that i though that the firmware
REnouveau really helps a lot if you want to know what to put in the
I though it might be some unofficial nvidia help there to get this done...
Posted Dec 16, 2009 23:25 UTC (Wed)
by airlied (subscriber, #9104)
[Link] (1 responses)
This isn't the shader engine or anything like it, its a simple processor that just copies data from processor registers to VRAM and vice-versa, its like a really simple offload engine.
So its a fairly simple processor and working out its opcodes once you know what its copying and to where wasn't that hard, the simpler opcode were okay, the problem at least with G80 opcodes is the non-trivial ones (I think 2 left) are proving quite hard to figure out.
Posted Dec 16, 2009 23:35 UTC (Wed)
by iznogood (guest, #51845)
[Link]
Its really enlightening to know this kind of stuff (at least for me). Any
Thanks in advance
Posted Dec 17, 2009 1:04 UTC (Thu)
by Anssi (subscriber, #52242)
[Link]
There's a link to a firmware tarball at http://nouveau.freedesktop.org/wiki/InstallDRM
If you grab the firmware from the git tree instead, you also need to convert the files to binary format, e.g.
The abrupt merging of Nouveau
http://article.gmane.org/gmane.linux.kernel/925574
http://article.gmane.org/gmane.linux.kernel/925587
That falls under the "not ready yet" excuse listed in the article :)
KMS etc.
KMS etc.
It seems you wanted a different focus to the article than I did. The article wasn't about why Nouveau hadn't been upstreamed until now; some of that was covered with the kernel summit discussion, and it lacks relevance now. The article is why Nouveau was upstreamed now, and what the remaining issues are. That's why the bulk of the article concentrates on Linus's tantrum and ctxprogs.
KMS etc.
KMS etc.
http://article.gmane.org/gmane.linux.kernel/925580
http://article.gmane.org/gmane.linux.kernel/925880
KMS etc.
KMS etc.
The links are there
conversation which is where I go when I want to get into the details of the
thread (or watch a flamewar ;-). Much as I trust the LWN editorial staff
it's nice they provide the links to the direct source material so I can
always review it for myself.
KMS etc.
KMS etc.
The abrupt merging of Nouveau
Fixed.
Typo fixed
Typo fixed
It's not the first time that's been suggested. It's a good idea, it's just a matter of doing it. Even better would be a "report typo" or "send to the editors" button. One of these days...
Typo fixed
Typo fixed
I set out to post (as I have before) that I don't understand how adding a line of instruction to the comment editor page could be so hard that it's even worth talking about (as opposed to doing) for three years.
Typos as comments
Typo fixed
Typo fixed
The abrupt merging of Nouveau
> developers take the Signed-off-by: line seriously and are not willing to
> attach it to something which might be legally questionable.
s/Linux/Linus/ (nt)
s/Linux/Linus/ (nt)
s/Linux/Linus/ (nt)
s/Linux/Linus/ (nt)
The "nt" marker is cargo-culted all over the place, even to forums where it's just noise (like this one).
All right, I'll ask the obvious. What the heck is "(nt)"? Is it short for "(Non-technical)"?
(nt)?
(nt)?
(nt)?
(nt)?
Wol
The abrupt merging of Nouveau
The abrupt merging of Nouveau
want in technology. If you do not value that enough to choose another
graphics card or deal with unstable software, then please find another
distribution. I for one value Fedora's stance and choose to run it rather
than the alternatives.
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
is patented and sues them? I, of course, would like them to open the drivers,
but ignoring the legal and business reality doesn't help.
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
all it means is that NVIDIA has to put things through a legal review
process like ATI has done to ensure that NVIDIA does not knowingly release
information they are bound not to.
- are not a commodity. A lot of drivers exist, but most of them are shit.
Intels drivers are crappy, even their proprietary Windows ones. ATI's
drivers have a horrifically bad history even on Windows. NVIDIA has had
its goofs, but overall their drivers have been simply fantastic for many
years. Their driver team is superb. Maybe they're better funded, maybe
the company provides them better documentation, or maybe NVIDIA just
managed to hire the better team -- why they have better drivers is not
important, but the fact that they do have such soundly superior drivers is
extremely important.
done, given the market it aims for. Both Intel and ATI have problems
delivering that hardware to users in a usable package due to shoddy
drivers, however. I can point to 3 series bugs in the latest Intel Windows
drivers, and nobody who's ever used FGLRX can deny the flakiness of ATI's
drivers.
ATI drivers with NVIDIA's memory manager, GLSL/HLSL compilers,
optimizations, and general architecture would pretty much eliminate any
advantage NVIDIA has over ATI.
NVIDIA doesn't need help from the community developing its drivers. It
makes more than enough to afford the salaries of its driver team. It will
get no benefit from Open Source drivers. It will simply lose its edge.
is knowledge and learning that results in superior drivers, says the FSF,
then NVIDIA should improve and enrich mankind by sharing that knowledge,
and that not sharing that information is a direct and intentional attack on
the progress and future of humanity. That's all fine and good to think
like that if you want. NVIDIA -- and most other companies -- aren't in the
business of enriching mankind, unfortunately, and aren't going to risk
their marketable strengths for idealism, especially when their share-
holders are not the kind of people that accept knowledge-withholding as
unethical.
Source web servers or programming languages or kernels or GUI toolkits --
then and only then will the cost/benefit ratio of releasing Open drivers
even start to look advantageous for a market leader like NVIDIA.
ever going to Open their drivers.
practical side of things, at least). There are a few niche markets where
Open is actually a bullet point used when evaluating a product. There are
cases when the community can improve the driver more easily and more
cheaply than the vendor. There are cases where being included upstream in
the Linux kernel or userland graphics stack increases market share.
Unfortunately, video drivers are not one of those places. The binary
NVIDIA driver is still hugely popular even for regular ol' Linux users
because its feature set, performance, and stability outweighs the costs of
having a binary blob in their kernel. The average Linux desktop user has
already proven that Open or being upstreamed are not prerequisites to
purchase. Much like the early history of Linux, then, it is only by
turning the market for video drivers into one of commodities instead of one
of luxuries that Open will become the standard and proprietary will fade
away.
The abrupt merging of Nouveau
The abrupt merging of Nouveau
competition to create the best product at the lowest price. The Invisible
Hand should force the market to release the source.
not because they want to, but because the market forces them to have to in
order to compete.
graphics cards(desktops) Nvideo will not release source.
relation to Capitalism here.
so happens that socialism works in software because distribution of code is
free, but supporting the code is not. And that is why people pay healthy
sums to Red Hat for support instead of using CentOS. Intel(etc) piggy
backs to sell server hardware, but Nvidea gives nada because there is no
graphics card on most servers.
I do Linux for a living. A normal desktop user will not be able to use
Ubuntu 9.10. The reason, a closed source Adobe Flash driver again linux
has little pull right now on the desktop.
are companies I respect.
The abrupt merging of Nouveau
The abrupt merging of Nouveau
they please. They will take time to work together and get along and form
orginizations simply because it's in their best interest.
"Capitolism" in the way that people will automatically create a system for
exchanging currency and creating businesses if left to their own devices
are pretty much exactly the same thing. Creating social networks and
creating a monetary system (whether it be code or credit) and a work-reward
system is as natural to humans as breathing.
one another in order to try to drive people to follow in their own
particular viewpoint of the world is when bad shit starts happening.
a large amount of people you have a break down and inefficiencies. When
people are allowed to do things on their own in a distributed manner then
that is when we can reach highest efficiencies.
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
Wol
Socialism is a mixture of capitalism and communism (Marx thought it was a stepping stone on the way to communism). So for open source to be socialist, it would still need a central authority to direct some resources. And I don't see one.
The abrupt merging of Nouveau
In my opinion, open source is anarchist, and anarchism is properly understood as a decentralized, cooperative, collectivist, libertarian-socialism.The abrupt merging of Nouveau
Decision making is largely done collectively and cooperatively, in a participatory fashion, rather than a central authority atop a hierarchy.
Socialism only requires a centralized authority if you are referring to authoritarian socialism. Libertarian-socialism (anarchism) is a different deal. My two cents...
-Andy
AnarchismToday.org
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
NVIDIA giving up their driver tech will literally level the playing field. [...]
Drivers
Drivers
NVIDIA giving up their driver tech will literally level the playing field.
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
No other vendor has choose to support Linux as a primary driver platform.
You mean like how Intel supports all their graphics chipsets before they even get released to the public, and releases actual *documentation* for their chipsets, not just drivers? Not to mention driving much of the innovation in the X Window System.
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
run great on Linux desktops with fglrx. Once the open source 3d drivers catch
up enough to reliably run compiz on them I'll switch fulltime. Nvidia is not
the only video card company that makes hardware work relatively well with
Linux. Up until recently, Matthew Tippett was a very important resource to
help see this through.
The abrupt merging of Nouveau
Actually ATI released 3D programming information for the r100 and r200
families of graphics chips (powering the graphics cards up to the
Radeon 9250) a long time ago, and we have had 3D drivers for these
cards for a very long time. Then they changed their policy, and did
not release information for their later cards until they were bought
by AMD. The r100 and r200 information reportedly helped in reverse
engineering the r300/r400 and so we have enjoyed free drivers for
these cards with 3D acceleration after a while.
The abrupt merging of Nouveau
The abrupt merging of Nouveau
to work at acceptable speed? I switched my desktop from NVidia to ATI this
year, because I just could not bear the slowness any longer. Being able to
watch konsole printing a screen full of text for half a second boosts your
working performance immensely. I also liked especially how they removed
video acceleration with the GeForce 6xxx line without giving a proper
replacement in the driver. Chances of getting HD videos to work are 0 when
the X server takes > 60% CPU time to get the fully rendered image to the
screen.
even in 2009 I can scroll in vim without waiting for ages for the screen
to redraw and even HD video works fluidly. Basics that actually work!
Who'd have thought?
The abrupt merging of Nouveau
Are you sure you weren't using the nv driver?
The abrupt merging of Nouveau
For both the answer was: buy a new graphics card from the 8xxx series.
There the drivers do accelerate video and anti aliased fonts.
usable support by free drivers which in both regards surpass both NVidia's
and AMD's proprietary offers.
The abrupt merging of Nouveau
I suspect Nvidia would be perfectly happy to help RedHat debug and support the drivers, perhaps
dependent upon some payment being made, and probably requiring an NDA. Apple seems to have
no trouble shipping binary nvidia drivers that work (I bet they either actually have the source code
to the driver available in house or at least work very closely with the nvidia developers to ensure it
functions properly).
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of...
The abrupt merging of...
The abrupt merging of...
The abrupt merging of...
The abrupt merging of...
The abrupt merging of...
about doing suspend? Why is there more to suspend to RAM than just turning every piece of
hardware that you know that you reliably can to the lowest power setting that you know how to,
and if there is too much hardware that you don't know you can reliably suspend, just failing? Or
does the problem lie in deciding where a given piece of hardware lies? Or is it religious reasons of
wanting to use BIOS ACPI code at all costs?
may have things like the X server doing things that user space shouldn't normally do, remembering
current kernel state and reconstructing it on next boot.
The abrupt merging of...
The abrupt merging of...
would already be doing what I said...)
The abrupt merging of...
The abrupt merging of...
that the last doesn't apply to the CPU, but I don't know much about DRAM) that this can't be done
by driver code without reading ACPI information?
The abrupt merging of...
kernel can't put code there, so performing suspend to RAM on commodity x86 without firmware
assistance is impossible.
The abrupt merging of...
> The kernel can't put code there, so performing suspend to RAM on commodity x86 without
> firmware assistance is impossible.
Is there really no known way to do this without assistance from the ACPI BIOS? I'm no expert, but
my understanding was that DOS extenders did this all the time to switch from protected back to
real mode at a time when there was no ACPI.
The abrupt merging of...
from scratch as far as it's concerned. It's up to the BIOS to check a flag to determine whether it's a
cold power on or a resume.
embedded controller up, dump values back into the thermal monitoring hardware and any number
of low-level initialisations. Only once that's been done does control get passed back to the OS,
which has absolutely no idea how any of that hardware works.
The abrupt merging of...
> hardware that you know that you reliably can to the lowest power setting
> that you know how to
and power on hardware only when they are under use, rather than only
powering them down on explicit "suspend" event.
> suspend, just failing? Or is it religious reasons of wanting to use BIOS
> ACPI code at all costs?
Modesetting. I believe on X86 it is kinda tricky to suspend some devices
using ACPI BIOS and others from kernel drivers. To efficiently use driver-
based suspend the ACPI usage should be stopped completely.
The abrupt merging of...
devices before you suspend the USB controller). And you have to make sure
userspace processes won't be trying to wake devices up behind your back.
find it at the moment.
The abrupt merging of Nouveau
The abrupt merging of Nouveau
The abrupt merging of Nouveau
it is doing there exactly ? With REnouveau you just get the state of the card
and its registers before and after a test. How does this help in this case ?
The abrupt merging of Nouveau
The abrupt merging of Nouveau
runs on the GPU so you need to know some "GPU assembly language" or
something
like that. I mean just reading a few regs does not help a lot in that case.
You really need to understand the chip architecture, its not x86 or
something. And its totally undocumented. That is what i meant before and i
was wondering how they do it.
registers
to draw something for example, but i can not understand how it works on the
firmware case.
On the other hand i know nothing about that stuff so what i say might be
totally wrong
The abrupt merging of Nouveau
The abrupt merging of Nouveau
chance to point me at some docs of any kind for GPU internals ?
The abrupt merging of Nouveau
> editor happens to know that the firmware can be found in the Nouveau git
> tree. Simply grabbing the right version and placing it in the local
> firmware directory should be sufficient.
"objcopy -Iihex -Obinary filename.ctxprog.ihex filename.ctxprog".