Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 50

Thread: The Challenge In Delivering Open-Source GPU Drivers

  1. #31
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    313

    Default

    Quote 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.

  2. #32
    Join Date
    Oct 2007
    Location
    Under the bridge
    Posts
    2,125

    Default

    Quote 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.

  3. #33
    Join Date
    May 2007
    Location
    Nurnberg.
    Posts
    313

    Default

    Quote 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.

  4. #34
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,776

    Default

    Quote 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.

  5. #35
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,776

    Default

    Quote 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.

  6. #36
    Join Date
    Jun 2009
    Posts
    2,926

    Default

    That's what distributions are for.

  7. #37
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,776

    Default

    Quote 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.

  8. #38
    jbarnes is offline PCI Maintainer for Linux, X.Org developer, DRM developer, Mesa developer
    Join Date
    Feb 2010
    Posts
    21

    Default

    Quote 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.)

  9. #39
    Join Date
    Jun 2009
    Posts
    2,926

    Default

    Quote 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.

  10. #40
    Join Date
    Jul 2008
    Location
    Greece
    Posts
    3,776

    Default

    Quote 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?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •