Announcement

Collapse
No announcement yet.

The Challenge In Delivering Open-Source GPU Drivers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #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.

    Comment


    • #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.)

      Comment


      • #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

        Comment


        • #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?

          Comment


          • #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 intel.com, 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 "intel.com" with "ubuntu.com". 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.

            Comment


            • #16
              Originally posted by allquixotic View Post
              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 intel.com, 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 "intel.com" with "ubuntu.com". 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.
              You seem to think that replacing the Xorg server is some big huge job with lots of incompatablilies

              The xorg server plus all it's drivers is still smaller than either of the main binary blobs for either Linux or Windows

              Bumping Xorg server versions shouldn't cause any issues for apps and if they went back to monolithic any issues with the smaller libraries being out of sync would be simply resolved

              If you're using Ubuntu try giving xorg-edgers a go and see if you have any issues, there is no reason why the distros couldn't have an online updater during install or even release .1 version of their live media when major new hardware is released

              Comment


              • #17
                Originally posted by FireBurn View Post
                You seem to think that replacing the Xorg server is some big huge job with lots of incompatablilies

                The xorg server plus all it's drivers is still smaller than either of the main binary blobs for either Linux or Windows

                Bumping Xorg server versions shouldn't cause any issues for apps and if they went back to monolithic any issues with the smaller libraries being out of sync would be simply resolved

                If you're using Ubuntu try giving xorg-edgers a go and see if you have any issues, there is no reason why the distros couldn't have an online updater during install or even release .1 version of their live media when major new hardware is released
                I might as well correct my self, the only issues you may have is with the binary blobs, these frequently fail with ABI changes in the xorg-server

                Sometimes it's the case of manually overriding (the last one was input driver related so could be ignored) other times more invasive work is required

                Comment


                • #18
                  binary vs foss

                  sry for the noob question but why binary gpu drivers can be updated ten times a year irrespective of the other components and foss can not?

                  Comment


                  • #19
                    Originally posted by rmic View Post
                    sry for the noob question but why binary gpu drivers can be updated ten times a year irrespective of the other components and foss can not?
                    The components are being updated constantly in git, they don't do as many point releases however

                    If a bug is found in the binary blob you might have to wait for the next one or maybe the one after to fix it (if at all)

                    If you're lucky with OSS you might be given a patch to fix your problem immediately

                    Comment


                    • #20
                      Originally posted by rmic View Post
                      sry for the noob question but why binary gpu drivers can be updated ten times a year irrespective of the other components and foss can not?
                      Originally posted by FireBurn View Post
                      The components are being updated constantly in git, they don't do as many point releases however

                      If a bug is found in the binary blob you might have to wait for the next one or maybe the one after to fix it (if at all)

                      If you're lucky with OSS you might be given a patch to fix your problem immediately
                      True, but let's not forget that the binary drivers share code with the Windows versions. Therefore these drivers have a lot more money/man-power behind them.

                      Comment

                      Working...
                      X