No announcement yet.

The Challenge In Delivering Open-Source GPU Drivers

  • Filter
  • Time
  • Show
Clear All
new posts

  • The Challenge In Delivering Open-Source GPU Drivers

    Phoronix: The Challenge In Delivering Open-Source GPU Drivers

    As illustrated today by the release of Intel's "Sandy Bridge" CPUs there is a new desire by Linux users: open-source drivers "out of the box" at launch. Over the years the expectations of Linux users have gone from simply wanting Linux drivers for their hardware to wanting open-source Linux drivers (read: no binary blobs) to now wanting open-source drivers in the distribution of their choice at the time the hardware first ships. This is a great problem to now be experiencing, as since starting Phoronix seven years ago, the Linux hardware experience has improved a great deal where it's no longer a question if there will be Linux support but when. Some hardware vendors, such as Intel, are now working towards this goal of same-day open-source Linux support -- and in some cases achieving it -- but for open-source Linux drivers for graphics it's a particularly tall hurdle to jump...

  • #2
    Charlie seems technically incompetent.


    • #3
      Originally posted by snuwoods View Post
      Charlie seems technically incompetent.
      Seems? Thought that was taken for granted.


      • #4
        does anyone take him seriously?


        • #5
          He's lots of fun. Plus, Nvidia bashing FTW.


          • #6
            Just managing to get a usable 2D experience working with sandybridge out of the box on 10.10 before the package freezes was a pain in the butt, try out other distro livecd's if you want even more fun. 3D support won't be in natty for another 2-3 weeks or so when mesa 7.10 is pulled in. You can use xorg-edgers but compiz still doesn't work on sandybridge with git mesa here as of last week.


            • #7
              If the Linux desktop is to ever go truly mainstream, there will need to be "out of the box" support in modern Linux distributions or at least a sane way to update the driver stack without the risk of hosing your entire Linux installation or forcing the distribution vendors to make choices that could have negative consequences on other users.
              Out of the box support is highly unlikely. You have to lead the release of the hardware by an absolute minimum of 6 months. More likely closer to a year. And that's of course ignoring the LTS distros that don't update their kernels or drivers for years at a time.

              A stable API would be much more useful. A stable ABI isn't so necessary, at least for FOSS drivers. Something like DKMS is more than sufficient; recompile the driver is the kernel is updated. Not super ideal, but it works. If installation CDs have a compiler on them and the system has enough temporary memory, it means you can even get a driver installed via USB stick or somesuch when your SCSI/RAID/SATA controller is missing the driver it needs to install. A stable API is sufficient to ensure that the user can grab a driver and install it on recent Linux distributions.

              A stable ABI would be most user-friendly, but is literally never ever going to happen. The Linux developers actively despise making users' life easy because it requires them to spend more than 2 seconds thinking about their kernel interfaces.


              • #8
                I don't think anyone would complain if a basic driver was available to them through their distribution. A plain driver which at least has 2D support and preferably supports an enhanced 3D desktop environment (compiz). Most users (especially MS Windows converts) believes that 'true' graphics performance is gained by installing an additional package (blob).

                Anyway, without OpenGL 3+ support, no open source driver will be able to meet the demand for a fully featured driver no matter when or how they are distributed.


                • #9
                  I think a good compromise would be if intel provided some backports for the most used distros -- using a tool like the openSUSE build service, that despite the name you can build for ubuntu, fedora, etc.

                  For MeeGo, Intel already uses it ( so it's not like it's a new thing.

                  For other distros, hey, the source is still out there, so they would be no worse than they are right now.


                  • #10
                    off topic


                    oh michael


                    • #11
                      Yeah, the only way to have this happen is if Intel or Ubuntu (preferably both collaborating together) come up with backports for the necessary software. Ubuntu could have it's updater check if you have new sandy bridge hardware, then ask if you want to install the graphics updates required (mentioning, perhaps, that it is experimental and not fully supported by Ubuntu).

                      At the very least, Intel could create a PPA containing all the necessary updates and mention it in release notes somewhere.

                      Expecting driver support to be ready even 3 months before the hardware is released is unrealistic, and not going to happen.


                      • #12
                        <3 Gentoo. Not having to deal with release cycle BS is great. Well, we have different BS, but this kind of thing is a non-issue.

                        Any braindead numbskull could run mesa/radeon git drivers via live ebuilds. No muss, no fuss. (And really... when does mesa mainline ever fail to build or crash? It's remarkably stable basically at all times.)


                        • #13
                          Originally posted by Smorg View Post
                          <3 Gentoo. Not having to deal with release cycle BS is great. Well, we have different BS, but this kind of thing is a non-issue.

                          Any braindead numbskull could run mesa/radeon git drivers via live ebuilds. No muss, no fuss. (And really... when does mesa mainline ever fail to build or crash? It's remarkably stable basically at all times.)
                          As is Xorg Server. I still don't understand why everyone got their pants in a twist about merging the drivers back.

                          The drivers would have been more stable with the removal of all the IFDEFs

                          Just look at how much the intel driver improved when they stipped out all the old code


                          • #14
                            Having sameday support with FOSS graphics drivers is really nice and all, but isn't having FOSS graphics drivers that are at least as feature rich, fast, and stable as the proprietary drivers much more important?


                            • #15
                              This isn't a "new" desire by Linux users, Michael. I have been wanting this -- exactly this -- for 7 or 8 years, ever since I started to do 3d stuff on the Linux desktop. I used to care about hardware 2D accel as well, but nowadays I have such beefed up CPUs on my system that I can basically run vesa or shadowfb and I'm happy with the 2D performance, even video playback (although the CPU gets very hot). It's all about the 3D accel, and of course, GPGPU.

                              It's annoying to think that here in 2011 we are just starting to realize that people who use Linux want things to be ideally easy. Those of us who aren't graphics programmers for a living have more relevant things to do with our lives than mess with things which we consider "plumbing" of the system, such as the graphics stack. Maybe the perception has been that most users just suck it up and do it anyway, but that doesn't mean we haven't wanted easy-to-install, up-to-date drivers for years.

                              And as it stands, it is next to impossible to obtain a hardware 3D-accel graphics driver for Linux that is: open source; easy to install outside the distro's release cycle; frequently updated (8 to 12 times per year); and lightly to moderately tested by people whose job is QA. IF you take away the open source requirement, we have two solutions that fit the bill perfectly; the Nvidia and ATI binary blobs. But that's a tall order to ask of people who are using a pioneering platform, one of whose main advantages is that it's FOSS.

                              I'd go for a stable kernel ABI and Luc's graphics driver stack refactoring any day, if it would allow me to go to, click "Download Drivers", select my distro, and grab a .deb or .rpm that installs an additional apt or yum repository from which I can download monthly or bi-monthly builds of open source drivers. Or even, failing that, replace "" with "". But that would only be possible if the actual graphics driver work could be separated out from the larger kernel / Xorg work, which we have long seen to be impossible with the current design. Stupid, stupid, stupid.

                              And don't even get me started on Intel's refusal to join the club and work on Gallium drivers. It's the best we have right now, even though it could be a lot better. "Mesa Classic" DRI path needs to be the next thing on the chopping block, but we can't do that until we have Intel drivers on top of Gallium. Nouveau and ATI are already there, we're just waiting for Intel.

                              De-modularized X with drivers in the xserver ==> worst possible situation.

                              Modularized X, Mesa Classic DRI ==> Status Quo. Quite bad, but not the worst.

                              Modularized X, Mesa Gallium3d ==> Getting Better. Should become status quo but Intel says no.

                              Set of kernel and userspace explicit API/ABI contracts forming a stable common graphics driver infrastructure on top of which any modern GPU driver can be implemented (similar to WDDM 1.1 or OS X Quartz Extreme): Ideal, but unlikely.

                              One of the problems with developing a stable API is that you have to live with it for all the hardware you intend to support. There are still plenty of 3dfx Voodoo, Intel 855G, and other such ridiculously old chips floating around. For them, I say use existing code that supports your hardware on something like RHEL 6 until you can upgrade your hardware. You've got 7 years of security updates as of September; the clock is ticking.

                              Placing the burden of even longer term hardware support on Linux is unfair, when you consider that competitor OSes don't support ancient GPUs for nearly as long (e.g., Windows 7 doesn't support WDDM for such old cards). The narrower your focus on the supported feature set of the GPUs your API will support, the more elegantly and directly you can design your API. To take an extreme example, if you support every device that has ever been considered to be a PC graphics card all the way back to 1985, with or without 3d support, VGA, CGA, EGA, etc., your API will look very differently than if you just support, say, cards that have full OpenGL 2.1 support and a hardware scheduler. But you don't want to limit your API to only Radeon HD5000, Nvidia GF100 or later in 2011: this is far too early for such an extreme generational restriction. Finding the happy medium that will maximize the lifespan of your API, and then getting a bunch of people to hurry up and implement drivers on top of it so you can get it in released product for years of productive use, is the key to success. WDDM 1.0 and 1.1 completely crushed this goal as perfectly as they could. We answered with GEM. To put it bluntly, we got our asses handed to us.