Slashdot Mirror


The Challenge In Delivering Open Source GPU Drivers

yuhong writes "After the recent Intel Sandy Bridge launch left Linux users having to build the latest source from Git repositories in order to have full support for the integrated graphics, Phoronix looked at the problems involved in delivering new graphics drivers for Linux."

6 of 182 comments (clear)

  1. Re:Intel and Open Source by vidnet · · Score: 5, Informative

    They did release drivers for the latest kernel, and they work great. However, you do need bleeding edge versions of the entire graphics stack to use them. This is a problem when combined with non-free ATI and Nvidia which always lags behind with no way for maintainers to get them up to speed.

    In other words, a distro can include "old" kernels/drivers/X-servers with non-free ATI/Nvidia support XOR newer and less tested ones with the latest Intel support.

    Either way, it's a reduced user experience and that's what TFA is on about.

  2. Re:It's not easy by JonJ · · Score: 4, Informative
    --
    -- Linux user #369862
  3. Re:Intel and Open Source by Anonymous Coward · · Score: 2, Informative

    Seeing as GPU manufacturers mainly used to support Windows and Mac, probably due to contracts between them, to attract cross-over clients. There was no such incentive for *nix back then.

    Well, it was less of that and more a matter of having a dis-incentive (if there is such a word). For a long time, most of the 90's, it was not easy to get drivers from the hardware vendors. It's only been in the past 10 years that we've seen a website with regular driver updates become standard- you used to have to hunt for a support number, usually not a toll free one, wait for an hour on hold only to be told it would cost you $20 for handling and take 3 to 6 weeks to ship you a disc. This meant having the drivers included with the standard Windows distribution was make-or-break for most peripheral hardware, especially GPU's and soundcards which rarely came pre-built back then.
    So MS was able to drop some "subtle hints" to the hardware vendors that well, if they released drivers for other OS's then it might cause some "problems" getting their drivers approved in time for the OS install discs to print and ship. In other words, although they never got caught 'red-handed', there was a LOT of fear in the hardware industry of being shut out in the cold if they supported Linux or other OS's which MS didn't want to compete with. Combine that with the usual FUD we used to (and still do) hear about opensource letting go of 'industry secrets' etc. and you end up with a climate which actively discourages the hardware makers from releasing their own drivers for Linux, or even giving out enough source to build your own. Luckily we've seen this attitude shift quite a bit in the last 5 years or so, but we're not all the way there yet.

    As for Mac, back then Apple had pretty much total control of their hardware and software, and they just plain old didn't want to let any of their competitors use it.

  4. Re:It's not easy by Mad+Merlin · · Score: 4, Informative

    It's obvious that you don't understand the issue, kernel ABI is completely irrelevant here. Not only is the overwhelming majority of the software that requires updating here in userspace (Mesa, Xorg libraries and Intel DDX driver), you can already switch out the kernel version in use freely, without a stable ABI!

    No, what the article is trying to say is that because not every driver completely reinvents the wheel like they do on Windows, there needs to be more coordination between the driver and the other libraries that it depends upon, instead of just being able to dump the latest development code as a new release and call it a day.

  5. Re:Damn linux users! by LingNoi · · Score: 4, Informative

    After RTFA it seems more that there are a ton of features missing rather then delayed. Here's an excerpt from the article..

    They include Video Processing Accelerators - never coming to Linux, Color Processing Accelerators - never coming to Linux, Skin Tone Enhancements - never coming to Linux, Adaptive Contrast Enhancement - never coming to Linux, Total Color Control - never coming to Linux, Video Decode in hardware - Q1, Video Encode in hardware - Q1, 3D acceleration - Q1 sooner rather than later and a host of software to use it - never coming to Linux.

  6. Re:It's not easy by Ash-Fox · · Score: 4, Informative

    The point is, it's a fucking mess to install graphic driver. I mean, why in the last 10 years, hasn't Linux/Xorg been able to roll out a stable graphic API on which the graphic card manufacturer can build drivers.

    Actually, they have, it's just that graphic card manufacturers want more than what the API provides.

    By the way, it's not about open source vs closed source, it's about Intel drivers flawed development process and Nvidia's working one. Nothing stops Intel from doing the same that Nvidia does (bundle everything) and release it as open source.

    nVidia bypasses a lot of opensource code to make their stuff 'just work', I wrote this small blog entry a few years ago that explained some of the things that nVidia's drivers do to resolve 3d acceleration issues and so on in the x.org architecture (some of the information is now outdated, but nVidia still bypasses various bits to make them 'just work'):

    http://ash.weststar.name/babble/20081104161100/why-nvidia-rocks-where-x-org-does-not/

    --
    Change is certain; progress is not obligatory.