Announcement

Collapse
No announcement yet.

The Challenge In Delivering Open-Source GPU Drivers

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

  • #31
    Originally posted by elanthis View Post
    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.
    First off, this is about the most sensible post in this whole thread. You put your finger on the issue correctly with the last sentence.

    That being said; the API does not need to be stable, it should evolve naturally. But it will automatically and naturally become more stable and future-proof if developers do spend more than 2 seconds thinking about their interfaces. Everything else comes from there, naturally, and almost painlessly (it is less painful than the current situation, that's for sure).

    Everybody could win, if only the supposedly more clued people would spend some time using that bigger brain that they are supposed to have. Or put differently: by continuing to refuse to work like this, those refusing only prove that they are not deserving of the status that they like to claim for themselves.

    Comment


    • #32
      Originally posted by zoomblab View Post
      Ah, the joy of "distro" dependency! Hannu said about that a long time ago.

      http://4front-tech.com/hannublog/?p=11
      Only if you don't know how to use git and make. Which is a pretty sad excuse.

      Comment


      • #33
        Originally posted by [Knuckles] View Post
        I think a good compromise would be if intel provided some backports for the most used distros

        Some backports for some distributions is rather limiting.

        What we need is driver developer provided backwards compatibility (with some features disabled) for some distributions: ideally, compatible with debian stable. The likes of Redhat, Canonical and SuSE can then do the rest of the work for their older enterprise releases (for which they get paid). The job of supporting such older infrastructure will also be overseeable in such a constellation.

        This way, every user can do one of the following to get drivers installed:
        1) install packages built by distribution maintainers, who also have an easy task, so updates are plenty and frequent
        2) build driver stacks from source for a reasonably current distribution
        3) spend some time on getting the code compatible
        4) buy support
        5) update infrastructure
        6) use a closed driver (for the sake of argument)

        Depending on different user classes, you can then start guessing at the numbers.

        Phoronix users:
        1) 5% -> 50%
        2) 10% -> 20%
        3) 5% -> 2%
        4) 5% -> 3%
        5) 25% -> 5%
        6) 50% -> 20%

        Other hobby users:
        1) 25% -> 60%
        2) 5% -> 10%
        3) 0% -> 0%
        4) 10% -> 5%
        5) 20% -> 5%
        6) 40% -> 20%

        Corporate users (admins doing the work):
        1) 30% -> 75%
        2) 20% -> 10%
        3) 0% -> 5%
        4) 20% -> 5% (little extra support needed for graphics drivers, but the support will be bought anyway for other issues)
        5) 10% -> 0%
        6) 20% -> 5% (most use intel hw anyway)

        (would be nice to collect real figures though)

        Guess what, those selling support will actually fare better:
        * the user experience will vastly improve
        * the market share will also improve (over time, we made a horrible impression so far)
        * the manpower needed to provide graphics driver support will be reduced and can be rerouted to do more useful things

        And, for graphics driver developers, there are the following advantages:
        * vastly increased userbase for recent code: better testing!
        * easier direct debugging: testing different versions of both driverstack and infrastructure is feasible
        * easier user debugging
        * less time spent dealing with bugs and support, more with development (but slightly more time will be needed there anyway)
        * more pressure for closed vendors to open up
        * bigger market share for free software

        All that takes is the willingness to state: "Yes, we support up to debian stable", and to make that happen. When given the ability, users will then provide loads of testing, and will make sure that such support is not broken easily.

        Comment


        • #34
          Originally posted by phoronix View Post
          Phoronix: The Challenge In Delivering Open-Source GPU Drivers


          http://www.phoronix.com/vr.php?view=ODk3MQ
          The link is broken. It does not link to the article.

          Comment


          • #35
            Originally posted by BlackStar View Post
            Only if you don't know how to use git and make. Which is a pretty sad excuse.
            No, it's not a sad excuse. It's an excellent excuse. Using a computer should be easy and intuitive. Like Mac OS and Windows.

            Expecting users to deal with Git and make is ridiculous.

            Comment


            • #36
              That's what distributions are for.

              Comment


              • #37
                Originally posted by pingufunkybeat View Post
                That's what distributions are for.
                Only rolling release ones. The rest needs to wait half a year or more, which makes users sooo happy.

                Comment


                • #38
                  Originally posted by elanthis View Post
                  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.
                  No, this is our job, and we blew it for Sandy Bridge. We're supposed to do development well ahead of product release, and make sure distros include the necessary code to get things working (we have separate teams to do development and aid distros in backporting, though most of them can handle it by themselves these days).

                  I could give you all sorts of explanations as to why this is (Sandy Bridge is a big architectural change, we made some mistakes in defining our development milestones, and we didn't work hard enough to get our changes backported), but really there's no excuse. Fortunately we've learned from this and are giving ourselves more time and planning better for Sandy Bridge's successor, Ivy Bridge.

                  As for a stable ABI, yes it would definitely help situations like this and make lives easier for distros, device manufacturers, and probably users. But it would make life harder for developers, and as we all know, open source development is driven by developers, and we're a whiny and lazy bunch. (Yes, this is a flippant remark, don't take it too seriously since I omit much of the complexity behind the "life harder for developers" part that has big implications for users, distros, and device manufacturers; it's a complicated issue.)

                  Comment


                  • #39
                    Originally posted by RealNC View Post
                    Only rolling release ones. The rest needs to wait half a year or more, which makes users sooo happy.
                    Surely, it's possible to update Mesa, X, and the kernel in a non-rolling distro, as long as it provides the relevant packages.

                    Comment


                    • #40
                      Originally posted by pingufunkybeat View Post
                      Surely, it's possible to update Mesa, X, and the kernel in a non-rolling distro, as long as it provides the relevant packages.
                      If it does then it's not a non-rolling distro, no?

                      Comment

                      Working...
                      X