Weekly Edition
Return to the Kernel page
| |||||||||||||
The abrupt merging of Nouveau
The merge window is normally a bit of a hectic time for subsystem
maintainers. They have two weeks in which to pull together a well-formed
tree containing all of the changes destined for the next kernel development
cycle. Occasionally, though, last-minute snags can make the merge window
even more busy than usual. The unexpected merging of the Nouveau driver is the
result of one such snag - but it is a story with a happy ending for all.
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:
I'm pissed off at distribution people. For years now, distributions
have talked about "upstream first", because of the disaster and
fragmentation that was Linux-2.4. And most of them do it, and have
been fairly good about it.
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:
[W]e know a lot about ctxprogs these days, including their purpose
[context switching], what they do [save/restore PGRAPH state], and
most of their opcodes. There are still some unknowns that prevent
us from writing new ctxprogs from scratch right now, but we're
working on that and it *will* be resolved in the proper way. Which
is throwing out nvidia's progs and writing our own prog generator.
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. (Log in to post comments)
The abrupt merging of Nouveau Posted Dec 15, 2009 20:47 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
I think in fairness you should probably have also quoted some of the detailed explanations Dave gave in the thread concerning the technical blockers associated with ongoing DRM and KMS work that needed to stabilize.
References:
-jef
KMS etc. Posted Dec 15, 2009 20:50 UTC (Tue) by corbet (editor, #1) [Link] That falls under the "not ready yet" excuse listed in the article :)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.
KMS etc. Posted Dec 15, 2009 20:56 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
Smiley faces won't protect you....
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
KMS etc. Posted Dec 15, 2009 21:30 UTC (Tue) by corbet (editor, #1) [Link] 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.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.
KMS etc. Posted Dec 15, 2009 22:01 UTC (Tue) by jspaleta (subscriber, #50639) [Link]
You made it a point to talk about prior excuses... you didn't have to put those sentences in or link to Linus's post where he goes over the excuses that he's heard in the past. All of that is historical context that you decided to include. I want to make sure that the contextual view isn't overly one-sided since you decided to include it.
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
KMS etc. Posted Dec 15, 2009 23:00 UTC (Tue) by jwboyer (subscriber, #23296) [Link]
I think the article was fine. Most of the points you brought up were covered last week on LWN already. A rehash of an article that rehashes lkml would be rather silly.
KMS etc. Posted Dec 15, 2009 22:13 UTC (Tue) by rahvin (subscriber, #16953) [Link]
I thought the summary was more appropriate than trying to re-convey an entire conversation that anyone could find on LKML. Can't satisfy everyone though.
The links are there Posted Dec 16, 2009 12:21 UTC (Wed) by alex (subscriber, #1355) [Link]
The very first Linus link takes your to the Gmane archive of the
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.
In this case I agree with Jon, the focus of the article was fine.
KMS etc. Posted Dec 15, 2009 22:01 UTC (Tue) by Tracey (guest, #30515) [Link]
I run fedora on a couple of fedora systems with nvidia graphics.
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.
KMS etc. Posted Dec 15, 2009 22:47 UTC (Tue) by nybble41 (subscriber, #55106) [Link]
As I understand the issue, it's not known that the blob is actually nVidia's "property". Most of it isn't actually included in their binary drivers, for example, and is most likely generated at runtime based on the local configuration. That would make it similar to the output of a compiler.
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.
The abrupt merging of Nouveau Posted Dec 15, 2009 21:25 UTC (Tue) by ajb (guest, #9694) [Link]
'many of us had been thought' ? :-)
Typo fixed Posted Dec 15, 2009 21:28 UTC (Tue) by corbet (editor, #1) [Link] Fixed.Next time please just send us an email at lwn@lwn.net? That helps to keep the comment tree cleaner and more interesting.
Typo fixed Posted Dec 15, 2009 23:01 UTC (Tue) by chrish (subscriber, #351) [Link]
Maybe adding something ("Please send typos directory to lwn@lwn.net") to that effect in the message at the top of the "Comment editor" instead of posting it after typos submitted in comments would be a good idea... It'd probably be more effective.
Just a suggestion.
Typo fixed Posted Dec 15, 2009 23:09 UTC (Tue) by corbet (editor, #1) [Link] 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 Posted Dec 16, 2009 16:53 UTC (Wed) by Trelane (guest, #56877) [Link]
One of these days, pow, right to the moon? :) And we'll have a pony tree in every pot?
Typos as comments Posted Dec 20, 2009 3:44 UTC (Sun) by giraffedata (subscriber, #1954) [Link] 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.But here in the comment editor I see the line is now there!
Typo fixed Posted Dec 31, 2009 13:45 UTC (Thu) by speculatrix (guest, #62766) [Link]
are you simply waiting for someone to merge the "submit typo" patches upstream, and if so is it merely an excuse
:-D
Typo fixed Posted Dec 17, 2009 4:23 UTC (Thu) by daniels (subscriber, #16193) [Link]
'Please send typos directory to lwn@lwn.net'? Oh, the irony. :)
The abrupt merging of Nouveau Posted Dec 15, 2009 23:02 UTC (Tue) by MattPerry (guest, #46341) [Link]
> 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.
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.
s/Linux/Linus/ (nt) Posted Dec 15, 2009 23:02 UTC (Tue) by MattPerry (guest, #46341) [Link]
s/Linux/Linus/
s/Linux/Linus/ (nt) Posted Dec 15, 2009 23:10 UTC (Tue) by alextingle (guest, #20593) [Link]
You a kuro5hin refugee? The (nt) marker is a dead givaway.
s/Linux/Linus/ (nt) Posted Dec 16, 2009 0:22 UTC (Wed) by dirtyepic (subscriber, #30178) [Link]
that practice is far older than kuro5hin.
s/Linux/Linus/ (nt) Posted Dec 16, 2009 6:57 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
> that practice is far older than kuro5hin.
The "nt" marker is cargo-culted all over the place, even to forums where it's just noise (like this one).
(nt)? Posted Dec 16, 2009 19:24 UTC (Wed) by dwheeler (guest, #1216) [Link] All right, I'll ask the obvious. What the heck is "(nt)"? Is it short for "(Non-technical)"?
(nt)? Posted Dec 16, 2009 20:28 UTC (Wed) by dkg (subscriber, #55359) [Link]
(nt) means "no text", as in: "if you've read the subject line here, you don't need to read the body of my comment, as it contains no additional text."
(nt)? Posted Dec 17, 2009 6:03 UTC (Thu) by TRS-80 (subscriber, #1804) [Link]
The other usage I've seen is to put a $ at the end of the subject to indicate that's the end of the message.
(nt)? Posted Dec 24, 2009 21:56 UTC (Thu) by Wol (guest, #4433) [Link]
Especially used when the comment is rejected if it has no text (hence n/t - a no-text comment!)
Cheers,
The abrupt merging of Nouveau Posted Dec 15, 2009 23:20 UTC (Tue) by Banis (guest, #59011) [Link]
Linux admins are still required to be careful in hardware selection. And with respect to modern graphics hardware, as has been the case for years, the only choice is Nvidia. No other vendor has choose to support Linux as a primary driver platform. Yes, they don't play by the opensource rules, instead they play by the rules that everyone else on the planet uses. It would be nice if sites like the would get that and remove the extreme bias in their reporting. This article was great until the last paragraph when it went off the deep end.
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.
The abrupt merging of Nouveau Posted Dec 16, 2009 0:00 UTC (Wed) by eli (guest, #11265) [Link]
No, Fedora is doing the right thing -- paying attention to the freedom we
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 Posted Dec 16, 2009 0:25 UTC (Wed) by nix (subscriber, #2304) [Link]
You appear to have forgotten that ATI exists. This shows the extreme bias in your comment.
The abrupt merging of Nouveau Posted Dec 17, 2009 21:12 UTC (Thu) by slougi (subscriber, #58033) [Link]
Unfortunately Ati's drivers are nowhere close to Nvidia's in terms of performance, functionality, or stability. In a production environment the proprietary Nvidia driver has been the only workable one for me for a rather long time.
The abrupt merging of Nouveau Posted Dec 24, 2009 16:28 UTC (Thu) by glup (guest, #62317) [Link]
That is dangerous comment because it might be history today already.
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. :)
The abrupt merging of Nouveau Posted Dec 16, 2009 0:27 UTC (Wed) by bojan (subscriber, #14302) [Link]
> Yes, they don't play by the opensource rules, instead they play by the rules that everyone else on the planet uses.
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.
The abrupt merging of Nouveau Posted Dec 16, 2009 3:29 UTC (Wed) by dbenamy (guest, #39458) [Link]
And what if Nvidia opens their driver and someone finds something in it that
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 Posted Dec 16, 2009 3:35 UTC (Wed) by bojan (subscriber, #14302) [Link]
And Intel/AMD don't face the same how?
The abrupt merging of Nouveau Posted Dec 16, 2009 7:43 UTC (Wed) by Bluehorn (subscriber, #17484) [Link]
> And Intel/AMD don't face the same how?
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?
The abrupt merging of Nouveau Posted Dec 16, 2009 21:18 UTC (Wed) by bojan (subscriber, #14302) [Link]
I'll bet $5 they have cross licensing agreements, just like everyone else in the industry.
The abrupt merging of Nouveau Posted Dec 16, 2009 4:30 UTC (Wed) by elanthis (guest, #6227) [Link]
It has little or nothing to do with patents or litigation risks. At most
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.
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
The abrupt merging of Nouveau Posted Dec 16, 2009 5:40 UTC (Wed) by cventers (guest, #31465) [Link]
The problem is that proprietary drivers do cause major headaches when it comes to adapting and upgrading your infrastructure. If some major hardware vendor is dragging its feet or doesn't want to commit resources to make sure its drivers work in your new sandbox, it puts a brick wall in your path.
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.
The abrupt merging of Nouveau Posted Dec 16, 2009 8:19 UTC (Wed) by jmm82 (guest, #59425) [Link]
I am no economist, but I am pretty sure Capitalism depends on public
competition to create the best product at the lowest price. The Invisible Hand should force the market to release the source.
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
The abrupt merging of Nouveau Posted Dec 16, 2009 12:15 UTC (Wed) by cventers (guest, #31465) [Link]
I've always found Free Software / Open Source to be so fascination... the marriage of capitalism and socialism into an extremely effective vehicle for improving everyone's lives. This dynamic will only continue to grow.
Socialism doesn't work with scarcity. But ideas are free!
The abrupt merging of Nouveau Posted Dec 16, 2009 17:49 UTC (Wed) by drag (subscriber, #31333) [Link]
The word your looking for is 'Freedom'.
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
The abrupt merging of Nouveau Posted Dec 20, 2009 4:08 UTC (Sun) by giraffedata (subscriber, #1954) [Link] 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.
The abrupt merging of Nouveau Posted Dec 20, 2009 4:21 UTC (Sun) by jmm82 (guest, #59425) [Link]
Corperations do not hire subsystem maintainers as good philantropists.
The abrupt merging of Nouveau Posted Dec 24, 2009 22:15 UTC (Thu) by Wol (guest, #4433) [Link]
That's not socialism, that's communism ...
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,
The abrupt merging of Nouveau Posted Dec 26, 2009 21:21 UTC (Sat) by giraffedata (subscriber, #1954) [Link] 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.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.
The abrupt merging of Nouveau Posted Jan 19, 2010 20:29 UTC (Tue) by personman (guest, #63100) [Link] In my opinion, open source is anarchist, and anarchism is properly understood as a decentralized, cooperative, collectivist, libertarian-socialism.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 Posted Dec 16, 2009 6:25 UTC (Wed) by bojan (subscriber, #14302) [Link]
You seem to be claiming that Nvidia is some kind of leader because their drivers are the best.
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.
The abrupt merging of Nouveau Posted Dec 16, 2009 10:24 UTC (Wed) by ikm (subscriber, #493) [Link]
I buy NVIDIA hw precisely (and only) because of good drivers. So elanthis has got point, even if that alone is not the sole reason and/or not enough to be an actual market leader.
The abrupt merging of Nouveau Posted Dec 16, 2009 11:02 UTC (Wed) by nye (guest, #51576) [Link]
>I buy NVIDIA hw precisely (and only) because of good drivers
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.
The abrupt merging of Nouveau Posted Dec 16, 2009 21:23 UTC (Wed) by bojan (subscriber, #14302) [Link]
OK, that's two. I'm sure Nvidia's market share went up 5 points already ;-)
The abrupt merging of Nouveau Posted Dec 16, 2009 21:35 UTC (Wed) by ikm (subscriber, #493) [Link]
You forgot to count-in the initial poster :)
The abrupt merging of Nouveau Posted Dec 16, 2009 22:08 UTC (Wed) by bojan (subscriber, #14302) [Link]
Sugar! Sorry. In latest news, Nvidia up 10 points ;-)
The abrupt merging of Nouveau Posted Dec 16, 2009 22:37 UTC (Wed) by ikm (subscriber, #493) [Link]
Is this exponential? We could find some more followers, ya'know! :)
The abrupt merging of Nouveau Posted Dec 16, 2009 23:13 UTC (Wed) by bojan (subscriber, #14302) [Link]
Absolutely! For every one person that picks Nvidia because they have the best drivers, the percentage points of market share go up exponentially. And it can go above 100%, of course :-)
The abrupt merging of Nouveau Posted Dec 16, 2009 14:18 UTC (Wed) by marcH (subscriber, #57642) [Link]
> 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.
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.
The abrupt merging of Nouveau Posted Dec 16, 2009 21:20 UTC (Wed) by bojan (subscriber, #14302) [Link]
When you get help with you closed source driver from _one_ kernel developer, please let me know. I would really like to know how they're doing it.
The abrupt merging of Nouveau Posted Dec 16, 2009 22:24 UTC (Wed) by tseaver (subscriber, #1544) [Link]
If you aren't running the latest vanilla kernel, you can't expect to get support from kernel developers anyway. The overwhelming majority of Linux desktop users are running distro-maintained kernels, which the kernel develoeprs (rightly) don't try to support. At that point, the tradeoff is suddenly very different: I *prefer* the open driver, but I won't use it if it interferes with my use of the hardware (breaks resume, whatever).
The abrupt merging of Nouveau Posted Dec 16, 2009 23:28 UTC (Wed) by bojan (subscriber, #14302) [Link]
Except from kernel developers that are employed by your distro, right?*
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.
The abrupt merging of Nouveau Posted Dec 17, 2009 10:29 UTC (Thu) by marcH (subscriber, #57642) [Link]
> When you get help with you closed source driver from _one_ kernel developer, please let me know.
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.
The abrupt merging of Nouveau Posted Dec 17, 2009 22:52 UTC (Thu) by bojan (subscriber, #14302) [Link]
> If you are an average Joe then you will never get help, open-source or not.
Bullshit.
The abrupt merging of Nouveau Posted Dec 18, 2009 8:15 UTC (Fri) by farnz (guest, #17727) [Link] 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.
The abrupt merging of Nouveau Posted Dec 18, 2009 14:29 UTC (Fri) by marcH (subscriber, #57642) [Link]
> That's not my direct experience.
Did it cross your mind that the average Joe does not even speak English?
The abrupt merging of Nouveau Posted Dec 18, 2009 14:39 UTC (Fri) by farnz (guest, #17727) [Link] 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.
The abrupt merging of Nouveau Posted Dec 18, 2009 17:23 UTC (Fri) by marcH (subscriber, #57642) [Link]
> 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,
Are you aware that some Linux distributions ship binary drivers, or make their installation just a few native language clicks away?
The abrupt merging of Nouveau Posted Dec 18, 2009 17:41 UTC (Fri) by farnz (guest, #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.
Drivers Posted Dec 16, 2009 6:36 UTC (Wed) by eru (subscriber, #2753) [Link] NVIDIA giving up their driver tech will literally level the playing field. [...]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.
Drivers Posted Dec 16, 2009 6:55 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
Graphics drivers are far from hardware-dependent these days. Sure, they have their device-specific parts.
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.
The abrupt merging of Nouveau Posted Dec 16, 2009 9:53 UTC (Wed) by smurf (subscriber, #17840) [Link] NVIDIA giving up their driver tech will literally level the playing field.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.
The abrupt merging of Nouveau Posted Dec 16, 2009 23:31 UTC (Wed) by mikov (subscriber, #33179) [Link]
Very well said, very well!
The abrupt merging of Nouveau Posted Dec 22, 2009 0:58 UTC (Tue) by ceplm (subscriber, #41334) [Link]
Just that you won't get swallowed in awe over nVidia drivers, let me remind you of http://arstechnica.com/hardware/news/2008/03/vista-capabl...
The abrupt merging of Nouveau Posted Dec 22, 2009 9:38 UTC (Tue) by Kamilion (guest, #42576) [Link]
Just so nobody gets swallowed in awe over pie-charts -- don't forget that all the 'benchmarkers' out there tend to bench on windows because that's where the tools are.
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.
The abrupt merging of Nouveau Posted Dec 16, 2009 16:56 UTC (Wed) by Trelane (guest, #56877) [Link]
If you're looking for patent infringements and not able to go into binary code to find it, you're gonna get replaced by someone who can.
The abrupt merging of Nouveau Posted Dec 16, 2009 21:34 UTC (Wed) by bojan (subscriber, #14302) [Link]
Exactly. How else would patent infringements be found in proprietary software anyway. The "can't have open source because we may be violating patents" excuse is just that. And a bad one too.
The abrupt merging of Nouveau Posted Dec 16, 2009 1:11 UTC (Wed) by gdt (guest, #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.]
The abrupt merging of Nouveau Posted Dec 16, 2009 1:47 UTC (Wed) by josh (subscriber, #17465) [Link] 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 Posted Dec 20, 2009 9:27 UTC (Sun) by johnflux (guest, #58833) [Link]
How is that a fail? Intel does support of their chipset, but the graphics chip you linked to is done by Imagination Technologies. Intel has little say on whether Imagination Technologies release their drivers, although they have been trying to pressure them. (I used to work for Imagination Technologies)
The abrupt merging of Nouveau Posted Dec 21, 2009 12:13 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]
Intel's failure is primarily in branding. I used to be able to point to Intel as the brand you can trust and buy to be working out of the box with free and open source drivers in all Linux distributions. That's not the case anymore.
The abrupt merging of Nouveau Posted Dec 22, 2009 15:43 UTC (Tue) by hammers (guest, #62633) [Link]
"Intel has little say on whether Imagination Technologies release their drivers, although they have been trying to pressure them"
Really ? You used to work for IMG ? And you come out with a comment like that ?
Really ??
The abrupt merging of Nouveau Posted Dec 16, 2009 6:39 UTC (Wed) by SEJeff (subscriber, #51588) [Link]
Funny... ATI didn't used to get it until AMD bought them but ATI gfx cards
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.
Cluebat, you just got hit with it.
The abrupt merging of Nouveau Posted Dec 16, 2009 8:30 UTC (Wed) by alankila (subscriber, #47141) [Link]
I'd like to point out that once the open-source drivers catch up "enough" then fglrx will in all likelihood stop supporting your card. And in my case it took over a year before the open-source driver actually was good enough to replace fglrx for me, so I went a year with horrible 2d performance and very flaky 3d.
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.
The abrupt merging of Nouveau Posted Dec 19, 2009 14:25 UTC (Sat) by anton (guest, #25547) [Link] 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.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.
The abrupt merging of Nouveau Posted Dec 16, 2009 9:10 UTC (Wed) by niner (subscriber, #26151) [Link]
If NVidia's drivers are so great, then why can't they even get 2d graphics
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.
So now I switched to an ATI/AMD card with free radeon drivers and finally,
The abrupt merging of Nouveau Posted Dec 16, 2009 11:12 UTC (Wed) by nye (guest, #51576) [Link]
Or maybe you could have just fixed whatever is broken in your setup?
It must be obvious that such problems are not normal, or nobody would be able to use that hardware.
The abrupt merging of Nouveau Posted Dec 16, 2009 11:42 UTC (Wed) by niner (subscriber, #26151) [Link]
I am sure.
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
The abrupt merging of Nouveau Posted Dec 31, 2009 2:04 UTC (Thu) by robert_s (subscriber, #42402) [Link]
"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."
Ah, so you're suggesting Redhat should ship operating systems they are unable to debug and properly support.
The abrupt merging of Nouveau Posted Dec 31, 2009 3:02 UTC (Thu) by foom (subscriber, #14868) [Link] 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 Posted Dec 31, 2009 7:47 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Apple is not shipping a GPL'ed kernel.
The abrupt merging of... Posted Dec 16, 2009 0:51 UTC (Wed) by bojan (subscriber, #14302) [Link]
Now, if Linus would abruptly merge TuxOnIce, that would be really something :-)
The abrupt merging of... Posted Dec 16, 2009 2:35 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
you missed the fit that Linus threw in the last couple of weeks about the suspend process.
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)
The abrupt merging of... Posted Dec 16, 2009 3:01 UTC (Wed) by bojan (subscriber, #14302) [Link]
The main point being the fact that people have argued _years_ ago that TuxOnIce should be merged (which was and still is a superior implementation), which would give us _better_ suspend/resume and hibernate/thaw then. And we wouldn't have to suffer through current blank-screen/slow/pick-up-app-memory-from-swap thing for all these years.
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 :-)
The abrupt merging of... Posted Dec 16, 2009 5:16 UTC (Wed) by cventers (guest, #31465) [Link]
Somebody should give Linus a computer he thinks is neat but that fails horribly under the existing suspend code.
The abrupt merging of... Posted Dec 16, 2009 6:56 UTC (Wed) by bojan (subscriber, #14302) [Link]
Or, force him to do a quick and slick presentation in front of a lot of (to him) important people, using many apps with lots of state, after he arrived by plane that afternoon. Having a machine that can reliably, quickly and beautifully thaw and get into all the apps, while experiencing no lag due to page faults, would be a definite advantage :-)
The abrupt merging of... Posted Dec 16, 2009 9:32 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
That gives me a chance to ask a really naive question I've been saving up :) What is so difficult
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?
For suspend to disk, I can see the difficulties - taking a clean snapshot of user space, where you
The abrupt merging of... Posted Dec 16, 2009 10:46 UTC (Wed) by rsidd (subscriber, #2582) [Link]
What you describe would not save much power I think. Switch off LCD, spin down disk, reduce CPU to lowest state, power down what peripherals you can -- would at most double your battery life. A suspended laptop can go days before it drains. And suspend-to-RAM works well on most laptops these days. Suspend-to-disk is the problem and it is what tuxonice is about.
On my current machine, suspend-to-RAM is all I need. Though suspend-to-disk (uswsusp, not tuxonice) works too.
The abrupt merging of... Posted Dec 16, 2009 11:03 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
What is missing then that is drawing power? (Obviously I realise something must be, or people
would already be doing what I said...)
The abrupt merging of... Posted Dec 16, 2009 13:33 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]
DRAM refresh and CPU, mostly.
The abrupt merging of... Posted Dec 16, 2009 13:47 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
And are those components not sufficiently well known, or not sufficiently well identifiable (I know
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... Posted Dec 16, 2009 14:53 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Suspending the CPU means that when power is reapplied it'll jump to its default start address. The
kernel can't put code there, so performing suspend to RAM on commodity x86 without firmware assistance is impossible.
The abrupt merging of... Posted Dec 17, 2009 18:39 UTC (Thu) by michaeljt (subscriber, #39183) [Link]
> Suspending the CPU means that when power is reapplied it'll jump to its default start address.
> 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... Posted Dec 17, 2009 18:49 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
In S3, the processor has no stored state. "Resume" is equivalent to the machine being turned on
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.
Performing a full resume cycle is hard. You need to reprogram the memory controller, bring the
The abrupt merging of... Posted Dec 16, 2009 11:59 UTC (Wed) by nhippi (subscriber, #34640) [Link]
> 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 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
The abrupt merging of... Posted Dec 16, 2009 20:42 UTC (Wed) by mgedmin (subscriber, #34497) [Link]
You also have to suspend everything in the right order (e.g. suspend USB
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.
IIRC Matthew Garrett had a very nice explanation on his blog, but I cannot
The abrupt merging of Nouveau Posted Dec 16, 2009 14:02 UTC (Wed) by iznogood (guest, #51845) [Link]
Can someone explain how did they know what the firmware was doing and how they managed to reverse engineer it ? (If this is what they did)
The abrupt merging of Nouveau Posted Dec 16, 2009 15:17 UTC (Wed) by nye (guest, #51576) [Link]
Presumably using Renouveau - http://en.wikipedia.org/wiki/Renouveau
The abrupt merging of Nouveau Posted Dec 16, 2009 17:28 UTC (Wed) by iznogood (guest, #51845) [Link]
ok but the firmware is supposed to run inside the GPU. How can we know what
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 Posted Dec 16, 2009 22:07 UTC (Wed) by airlied (subscriber, #9104) [Link]
They change a bit, watch what breaks, repeat a lot.
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.
The abrupt merging of Nouveau Posted Dec 16, 2009 22:29 UTC (Wed) by iznogood (guest, #51845) [Link]
OK thanks for the reply.
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...
The abrupt merging of Nouveau Posted Dec 16, 2009 23:25 UTC (Wed) by airlied (subscriber, #9104) [Link]
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.
The abrupt merging of Nouveau Posted Dec 16, 2009 23:35 UTC (Wed) by iznogood (guest, #51845) [Link]
Man, thanks so much.
Its really enlightening to know this kind of stuff (at least for me). Any
Thanks in advance
The abrupt merging of Nouveau Posted Dec 17, 2009 1:04 UTC (Thu) by Anssi (subscriber, #52242) [Link]
> 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.
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.
|
|||||||||||||