ATI Releases Drivers for XFree 4.3.0 428
Kyouryuu writes "ATI has finally released official drivers for XFree 4.3.0 and updated their Linux drivers to 3.7.0 for supported XFree versions, several months after the originally proposed release date of April last year. Although Schneider Digital has previously made available unofficial drivers, Linux users who have ATI Radeon cards can now benefit from an official release. Unfortunately, ATI still insists on using RPM exclusively and keeping the drivers closed source."
closed source != bad always (Score:3, Interesting)
So what if the drivers are closed source? ATI cant and wont expose the low level details of their hardware's functionality to competitors. Whats the difference anyway? It is naive to think that you could even understand, let alone improve, what the engineers - who know the hardware intimately - have written? And by the way, Nvidia does not publish its source either...
Re:closed source != bad always (Score:2, Interesting)
However, open source == better bug finding/fixing (Score:3, Interesting)
Remember the Win2000 source leak. Someone noticed a fairly simple programming error (signed instead of unsigned variable IIRC). That person didn't have an initimate knowledge of Windows 2000, but they still found a bug. This is the type of situation where more eyes make for better code.
Re:closed source != bad always (Score:3, Interesting)
Re:closed source != bad always (Score:5, Interesting)
Anyway I like Open Source drivers. BTW: Don't forget to sign the Intel Support of Centrino Under Linux Petition [petitiononline.com]. See more details about Linux on Centrino laptops [tuxmobil.org].
Re:closed source != bad always (Score:5, Interesting)
It's naive to think ATI's competitors don't have a much better understanding of their hardware than whatever can be gleaned from their drivers' sources, especially if you consider that they can already reverse-engineer the binaries better than any random Joe, seeing as they have actual money to sink into it. And there's the thing about them making the same sort of hardware.
Having the source would greatly benefit the little people though. These cards will sometime go End-Of-Live, and the manufacturer won't support them.
Perhaps the source won't be released to hide the fact these "engineers - who know the hardware intimately" make code that is in fact cruddy at times, and that it contains bugs than random Open Source jockeys can fix.
Though it's likelier that the drivers simply contain patented/copyrighted stuff they sublicensed from third-parties that are paranoid about anyone seeing it.
Re:Not just RPM... (Score:3, Interesting)
Whay has RPM got to do with anything? (Score:4, Interesting)
RPM -> Good!
Closed source -> Bad!
It's still an improvement (Score:2, Interesting)
Re:closed source != bad always (Score:4, Interesting)
Re:closed source != bad always (Score:5, Interesting)
I wanted to plug my laptop into a 1600x1200 LCD using DVI. If you select "linux laptop driver download" at the ATI site, it says "go ask the manufacturer." Oh, goody, corporate marketing BS fingerpointing.
But IBM doesn't support 1600x1200 over DVI on my laptop. Why? Who knows. Supposedly under Windows you can get it by hacking the registry. But IBM doesn't feel like supporting it. More corporate BS.
So you go back to the ATI site and download the Mobile FireGL driver, if you're persistent enough to think of trying it on the M9 Radeon chip. Turns out it does work, but they won't tell you that due to even more corporate marketing BS.
You find that it almost works, but makes a sparkling or shimmering effect from random bit errors at 1600x1200. From the open source radeon driver mailing list, it appears that the fix is very simple. But ATI got it wrong and of course a closed source driver can't be fixed. Of course you could try to contact the ATI engineers, tell them the solution, and maybe they'll send you a fix. In your dreams.
Meanwhile the open source radeon driver runs 1600x1200 over DVI just fine. Some versions did create the shimmering effect, so somebody posted to a mailing list and helped the developer figure out what was wrong and it got fixed.
So yeah, closed source is different.
Curious (Score:2, Interesting)
Too bad they lost me as a customer long ago (Score:5, Interesting)
Re:closed source != bad always (Score:4, Interesting)
Re:closed source != bad always (Score:1, Interesting)
This is not true. The real reason the graphics cards makers don't want to open things up is due to the high-end market.
See, the high-end market pays THOUSANDS of dollars for a single graphics card that can do one thing better: draw lines. The difference between these thousand-dollar monstrosities and the consumer cards?
The driver.
That's it. Nothing else. In consumer cards, the driver detects if the user is drawing lines and purposely slows down. The professional drivers don't have this misfeature.
So, if they open up their drivers, all the sudden they can't gouge their customers any longer as some driver hacker will make a driver that doesn't slow things down on purpose. All that cash that high-end graphics customers are willing to toss away suddenly evaporates. Anti-trust lawsuits might even follow.
Both nVidia and ATI could open their cards, but to do so means, at best, a sharp cutting of their margins at the high end.
FireGL?!?! (Score:2, Interesting)
Add textures and FireGL sucks. I beleive there's win32 firegl drivers too.
ATI needs to make Catalyst drivers for linux. Until then, the high end ATI cards will never perform well.
Re:closed source != bad always (Score:3, Interesting)
2) No slight to the XFree86 developers, but:
a) Many of the XFree86 drivers (eg: nv) are significantly slower than their proprietory counterparts and in any case 2D is much easier to do drivers for than 3D,
b) The DRI project has not released any drivers that take full-advantage of the hardware. NVIDIA's binary driver will get you exact same performance and the exact same features the Windows driver has. The DRI drivers for Radeons are not only *much* slower, but don't even support basic features like vertex/pixel shaders!
Non-OSS arguments don't hold water (Score:4, Interesting)
1: They can't OSS the driver cause there is propritary info (patented S3TC and such)
2: They can OSS and release their specs to projects like DRI as it would reveal stuff to the competition.
I say nonsense. These two arguments seem to equate OSS to GPL.
1: NV and ATI could make up their own OSS license. Lets call it the "We Need To Hide Stuff" license. They take their existing codebase and print it out. They then take a black magic marker to the printout and cross off all of the IP related stuff. They then scan the documents into Acrobat distiller and release it as a PDF. Add a statement that the code is their property under the WNTHS license and cannot be used by others, and all changes should be sent to NVidia. Problem solved. It's OSS.
2: I have never seen a processor designer "hide" their chip specs. Intel doesn't. AMD doesn't. What makes NV different? Unless they have unlicensed hardware in their product, there is no reason for them to hide what they have.
Are there any other reasons that I am missing?
Thank you for your time,
BBH
Re:Not about stealing the technology (Score:2, Interesting)
Seriously though, have you ever read an article where people dissect the design of the boards? They go into way more detail than the source code to a driver would have to. These are just journalists analyzing information ATI themselves have released. I understand that you think releasing the source code would release all kinds of information that previously wasn't released, because it will. However I think you overestimate how much anybody will care. PR using open source comments is just ludicrous, try imagining a press release where they explain, "Well ATI released their open source drivers, then on this one line this guy says "we can only do 24-bit zbuffering in pipeline 37 if the 5th register is also full". That's bad! Very bad! Don't buy their products! Don't understand it? Trust me, as their competitor I am in a completely unbaised position to tell you that it's very bad. It's may well be really really bad. Give us money."
Nobody will care. All of the real interesting technology isn't in the drivers, but the cards themselves. Drivers are just value-add and they spend alot of time just taking care of the quirks of the various applications they're trying to run. These quirks would be handled pretty easily with open source, and not be applicable to other people's drivers.
I just think "Open source drivers are bad because they'd be giving away their secrets!!" is just a knee jerk reaction, similar to when people said the same thing about closed-source operating systems. If you really stop and think about what source code they'd be giving away, there really isn't much there that is so revolutionary that it must be kept under lock and key at all times. The real beef is in the silicon.
Re:closed source != bad always (Score:5, Interesting)
I'm pretty bummed out about it actually because I don't feel like there's anything I can do to make it better under Linux. (Updating to the 2.6 kernel didn't help. I'm running the latest drivers for my video card and I've downloaded the nForce2 Linux drivers from nvidia for my motherboard's integrated sound. (ASUS A7N8X Deluxe, rev. 2.0)
I still prefer Linux
Proprietary and quality are two different things. (Score:2, Interesting)
As a person whom is working for one of the biggest hw/sw companies in the world and has been contributing code to some of our products, I'd say that we do things a bit different at times.
For one thing, QA and legal processes are much different than in the OSS world. The QA is extensive and a scheduled activity in a project instead of letting the users (alpha or beta teams ) find most bugs. This is just one way to do QA which might be considered a legacy of *old school* corporate development and will probably continue for quite a while longer due to many reasons.
As for the quality of code... We more or less come from the same background as most *hackers*, meaning we attended the same classes in school, read the same books on patterns, languages, design etc. as most other people in the field. We also are just human incapable of perfection and do not envision ourselves as incapable of error, error which could be spotted by peer review.
Unfortunately, peer review is still just in it's infancy at many places in the corporate landscape and there are a lot of prejudice to cope with before that process can be adopted (reasons which I believe a lot of you can imagine.. See Dilbert
It's true however that we have a slight advantage like sometimes being able to talk directly to the person who did stuff X which we happen to depend on and/or are tasked with wrapping in a software layer. However, most often we just design according to specs without contact with other HW/SW teams unless QA or unit testing reveals that the implementation is not in line with the specs, in which case we need to join forces with the people who did component X.
I for one would welcome a more open approach and it seems one of our directors of technology also understands the gain in peer review and having the code available to a larger audience. The result thus far has been that a few products have been moved to an internal sourceforge-like system/repository, to which all employees can apply for access. As we have a lot of code-litterate people, opening up the code of these products will no-doubt spur a lot of innovation, extensions and a quicker "time to market" of functionality our customers or even our own people crave for.
Please, do not assume that just because something is close sourced it's of higher quality. It's just code written by people, people who are probably a lot like yourself...
Re:The real question is: (Score:4, Interesting)
OK, so not only do they provide drivers, but they provide *source* code under a license that allows much of it to be incorporated directly into XFree86 and you call that an utter joke?
Damn, man, what will you accept?
ftp://ftp.matrox.com/pub/mga/archive/linux/2003
I run OpenBSD on non-i386 hardware. It's support like this that makes Matrox the only real option for me. I mean, try to get the nVidia Linux kernel module and binary XFree86 module running on OpenBSD/alpha.
Re:closed source != bad always (Score:3, Interesting)
At least frame it correctly. Its not "slightly slower." Its much slower, sometimes by several times. The trade-off is not a little bit of speed for a lot of freedom. Its turning your $300 graphics card into a $75 card, for a very little bit of extra freedom. Unlike an OS, or major software app, you're not tied into drivers. If the constraints of a closed-source driver become too much, I can switch out my card and its drivers in a matter of hours.
As far as I'm concerned, begging manufacturers to open source their drivers is whining. I don't think the OSS spirit is about forcing people to open their code. If they choose to, great. If they don't, well, we can just code something better. That's precisely what GNU did to UNIX. Now the issue at hand is that the OSS community has *not* been able to produce something that can replace this proprietory code. Until that happens, they really don't have a solid bargaining position.
Re:closed source != bad always (Score:5, Interesting)
Re:closed source != bad always (Score:3, Interesting)
Re:Not just RPM...DRM Vector. (Score:1, Interesting)
Would you feel the same way if Nvidia started incorporating DRM into their drivers, along with the bug fixes, and additional features? What would you do about it? Nvidia's drivers already shut down (or macrovision) the TV-Out when playing certain DVD's under Windows.