Slashdot Mirror
Intel Open Sources Graphics Drivers
PeterBrett writes "Intel's Keith Packard announced earlier today that Intel was open sourcing graphics drivers for their new 965 Express Chipset family graphics controllers. From the announcement: 'Designed to support advanced rendering features in modern graphics APIs, this chipset
family includes support for programmable vertex, geometry, and fragment shaders. By open sourcing the drivers for this new technology, Intel enables the open source community to experiment, develop, and contribute to the continuing advancement of open source 3D graphics.' The new drivers, available from the Linux Graphics Drivers from Intel website, are licensed under the GPL for Linux kernel drivers, and MIT license for XOrg 2D & 3D rendering subsystems."
The argument against nVidia and ATI opening up their drivers was always that it would give other vendors a headstart in cloning their chipsets. They'd be able to tell how they work (from a hardware API level at least), and have a driver ready to go if they copied that API.
Now that there's a working Intel 3D driver with source, does this mean that other vendors might start making cheap clones of the Intel graphics chips? Or was the above argument really a red herring.
And if they did, what's to stop them from making chips that use the same API, but work much better?
Posted from my Android phone. Oh, I can change this? There, that's better...
Nice.
I bet they're trying to preempt AMD doing the same with an integrated ATI chip.
Well played, Intel. Well played.
Victory or awesome!
besides the desire/preference to have open source drivers for license compliance and moral/ethical reasons, there is a more practical reason why source access to drivers is handy. sometimes you need to recompile drivers from source in order to have them play well with operating systems features. for instance, if they need to respect the constraints of real-time systems such as rtlinux, rtai, or xenomai. these systems need to redefine cli/sti (clear/set interrupt) instructions (using macros) so that the real-time micro-kernel handles the interrupts rather than linux. open source drivers let you recompile with #include files that make this possible.
Yeah! Damn those blobs, giving you all that performance!!
Why would an open source driver be slower than blobs if the manufacturers created it?
The way I see it, by giving ATI/Nv my money I'm saying "hey, it's ok to pollute my system with code I can't look at" (and yes, I am capable of looking at it, but even if I wasn't *someone* is and that's the point). So Intel will be getting my money when I buy a new motherboard.
And it's not just about games - Xgl/compiz, xcompmgr, etc. etc.
I know that all of us techies turn our noses up at integrated graphic chipsets, but I think that an enormous number of computers out there, including laptops, that utilize this technology. One of the more common complaints from people switching to linux is that the monitor resolution and graphics are sucky. A BSD and GPL licenced driver solution would be perfect to help more people make the switch!
Hardly.
Closed-source Linux drivers can work well enough for a single kernel version in a controlled environment. You still don't get support from most distros that would want to build their own. Sure, if you cooperate you get in Novell and Red Hat's offerings, but not much further. You also get the onus of sinking the money into it to keep it working. Not to mention you pretty much guarantee being a problem to your users--think things like software suspend that never work right with closed drivers because certain problems can't be debugged or fixed (in which case improved quality *IS* a foregone conclusion).
You either get SLES / RHEL, or you get SLES / RHEL / Debian / Ubuntu / everything else... Not to mention improved operation. Of course, gravitating toward what works is why people are using open source in the first place. Sometimes "what works" is defined in terms of avoiding vendor lock-in and extortionate licensing.
I think Mauve has the most RAM. --PHB (Dilbert Comic)
I got a Dell Inspiron 6000 a bit over a year ago and I dual boot XP / Gentoo Linux. I choose to go with the ATI Mobile X300 (M300) graphics cards, and I say you made the right choice. In order to get it to play nice with radeonfb, I have to disable hardware acceleration. Before I had hibernate working, but it is not working with the currently installed version of fglrx (not the latest anymore, I think). I am definitely never buying an ATI graphics card again, and after this announcement, I may seriously consider Intel's offerings.
Centralization breaks the internet.
You know, there's a lot more to do with a computer than play games. Especially amongst those of us that run Linux, we tend to do a lot less gameplaying than the average bear.
Personally, I'm ecstatic over FINALLY being able to purchase a system that will run Google Earth, that I won't have to fuck with every time a kernel update happens, or ATI breaks their latest blob and I have to spend hours googling for a fix, or nvidia hasn't once again broken something because they don't think anyone but 10 users still use this graphics card.
There's *nothing* but good to be said about open source graphics card drivers that support halfway decent OpenGL. Even if I don't have the privledge of spending $500 upgrading my rig just to play whatever the flavour of the month PC game is out.
If Intel would do this for add-on cards and not just integrated chipsets (which is what I hear is the deal so far), I'd be as happy as I've been ever since discovering Linux.
Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
Intel DOES release full specifications.
Their silicon is just crippled - there's honestly no way around that when you're effectively producing a $5 graphics solution (which is approximately the cost difference between Intel chipsets without integrated graphics and Intel chipsets with integrated graphics.) Even if a technology is economical to implement in silicon, at that price point it's not feasible to license technologies from other companies unless absolutely necessary, such as S3 Texture Compression, which was the technology that basically started the branch between closed-source and open-source ATI chipset support.
It does what it's designed to do extremely well (unlike many other "el cheapo" solutions which are designed to do more but just don't do any of it well), it just simply is NOT designed to do very much.
retrorocket.o not found, launch anyway?
Also, that document is a complete lie. I don't care that it's in the kernel tree. There's lots of wrong stuff in there.
A driver does not have to be in the tree to be stable, running driver, and the driver being in the kernel tree doesn't mean that it is either stable or running.
And I should know, as I have written multiple closed-source Linux device drivers, two of which have open-source versions in the kernel that have at various times either not worked, or worked poorly, and both of which perform signifigantly worse than the closed version.
Go actually read that document. The argument it makes is that a stable kernel/driver API is a bad idea because the kernel/driver API is unstable. It's a circular argument. The real issue is three-fold. One, there isn't enough agreement amongst the diversity of kernel developers to ever come up with a stable API, two, there is no dicipline amongst the people in charge to maintain that stability even if a consensus was reached, and three, there are some who would like to keep the interface unstable merely to keep this argument for open source drivers valid.
Dispite all that, the only real roadblock between ease of binary driver development and what we have today is that there is heavy backporting amongst distribution vendors without incrementing the kernel version number. In other words, vendors lie about their versions in order to maintain the illusion of version stability for their customers... But even that is a minor issue, as it only makes the people who run on the bleeding edge suffer, and nobody runs on the bleeding edge in production.
See, the interesting thing is that I wouldn't be surprised if *on Linux" the Intel cards end up beating ATI and NVidia just because of the drivers. I've got ATI cards in both my laptops and I'm not impressed by the speed with the open-source drivers (and I'm unwilling to live with all the trouble involved in the closed-source ones). I'm sure a machine with an Intel chipset and open-source drivers could easily beat both ATI and NVidia on Linux.
Opus: the Swiss army knife of audio codec
Possibly.
Another reason why they are unwilling to release the information might be because it would prove that they have been bullshitting us for a long time.
Chances are that the difference between a £50 card and a £300 card is in the software: by changing just one bit in one byte in the huge, bloated blob of a driver, you could extract £300 performance from a £50 graphics card. It can't be economically viable for them to fabricate different GPUs to use on "cheap" and "expensive" cards. Instead, they have an I/O pin {maybe several pins?} on the GPU which they tie to 0V {so it reads as a 0} on the cheap cards, or leave unconnected {so it looks like a 1} on the expensive cards. The driver software reads the state of the pin and determines whether or not to run the card in "expensive" mode.
{Then, of course, there are the various "cheats" built into games to make them run faster or better with certain graphics cards -- or, to put it more accurately, to make them run slower or worse with other graphics cards. Games companies are certainly not above accepting bakshish.}
The RAW formats used by digital cameras are similarly undocumented for pretty much the same reason: the JPEG files are interpolated up to much higher resolutions than the sensor actually generates. Revealing the format of the RAW file would also reveal the real number of pixels on the image sensor, and likely open up camera manufacturers to prosecution under consumer protection law.
Je fume. Tu fumes. Nous fûmes!