Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Intel To Hide Early Hardware Support By Default

  1. #1
    Join Date
    Jan 2007
    Posts
    14,324

    Default Intel To Hide Early Hardware Support By Default

    Phoronix: Intel To Hide Early Hardware Support By Default

    While Intel is quick to work on enabling future hardware within their open-source graphics driver stack for Linux, the early support is often buggy and problematic on the early code before the hardware is released. Intel now intends to conceal this early hardware support -- for Valley View and Haswell right now -- behind a run-time variable for toggling the support...

    http://www.phoronix.com/vr.php?view=MTIwODg

  2. #2
    Join Date
    Dec 2011
    Posts
    68

    Default This is Horrible!

    Now I can't use the Haswell driver on my 5 year old Intel chipset! Oh the horror!

  3. #3
    Join Date
    Sep 2008
    Posts
    989

    Default

    I'm pretty sure Fedora, ArchLinux and Gentoo will default to setting this module parameter because most people who use those distros will want it (new hardware enthusiasts, bleeding edge enthusiasts, etc)

    However, the downside of this flag is that people running more conservative distros such as Ubuntu will probably be stuck with *no* hardware support (llvmpipe or no 3d at all, or perhaps even no Xorg) until the drivers are considered stable enough. Of course they could enable the flag, but if you're using Ubuntu, you probably won't know about this flag anyway...

    Dumb idea all around, if you ask me. If a clueless end-user with new hardware is in a scenario where they downloaded a distro with this flag set, and the driver hasn't yet been declared stable in the version of the kernel they're running, would you rather (a) that they have no hardware accel at all, or (b) have some hardware accel working but crash with certain workloads or OpenGL features?

    This sounds like a defensive measure to further isolate users from the developers by preventing users from being able to blame Intel for having non-working drivers when the drivers are not finished in the first place. While this may make Intel developers' mailboxes slightly neater, it also has many downsides:

    • The early driver code never makes it out to the public for testing, which results in fewer bug reports (many many bugs are only found in real life workloads on end-user systems; this is truer with graphics drivers than any other software I've ever seen).
    • The fewer bug reports doesn't mean the software is more stable; it means that the bugs just aren't being found. So it takes longer for the driver to become stable, so then, either the public goes without the driver for a much longer period of time while Intel and enthusiasts find all the bugs by themselves, or the driver is declared "stable" prematurely and is still buggy anyway because all the bugs are the ones that will only be found in real-world scenarios, which aren't being tested because of the flag.
    • For the cases where the developers are wrong about the driver and it is in fact in better shape than they give it credit for, or where the user's use case is very modest (just 2d accel, or just basic compositing), they won't get access to the driver without tweaking a low-level system setting.

  4. #4
    Join Date
    May 2007
    Posts
    319

    Default

    Quote Originally Posted by allquixotic View Post
    I'm pretty sure Fedora, ArchLinux and Gentoo will default to setting this module parameter because most people who use those distros will want it (new hardware enthusiasts, bleeding edge enthusiasts, etc)

    However, the downside of this flag is that people running more conservative distros such as Ubuntu will probably be stuck with *no* hardware support (llvmpipe or no 3d at all, or perhaps even no Xorg) until the drivers are considered stable enough. Of course they could enable the flag, but if you're using Ubuntu, you probably won't know about this flag anyway...

    Dumb idea all around, if you ask me. If a clueless end-user with new hardware is in a scenario where they downloaded a distro with this flag set, and the driver hasn't yet been declared stable in the version of the kernel they're running, would you rather (a) that they have no hardware accel at all, or (b) have some hardware accel working but crash with certain workloads or OpenGL features?

    This sounds like a defensive measure to further isolate users from the developers by preventing users from being able to blame Intel for having non-working drivers when the drivers are not finished in the first place. While this may make Intel developers' mailboxes slightly neater, it also has many downsides:

    • The early driver code never makes it out to the public for testing, which results in fewer bug reports (many many bugs are only found in real life workloads on end-user systems; this is truer with graphics drivers than any other software I've ever seen).
    • The fewer bug reports doesn't mean the software is more stable; it means that the bugs just aren't being found. So it takes longer for the driver to become stable, so then, either the public goes without the driver for a much longer period of time while Intel and enthusiasts find all the bugs by themselves, or the driver is declared "stable" prematurely and is still buggy anyway because all the bugs are the ones that will only be found in real-world scenarios, which aren't being tested because of the flag.
    • For the cases where the developers are wrong about the driver and it is in fact in better shape than they give it credit for, or where the user's use case is very modest (just 2d accel, or just basic compositing), they won't get access to the driver without tweaking a low-level system setting.
    its not about accel as muhc as output setup. Would you rather they just got a black screen?

    If you ship a 3.6 kernel now in a distro (say F18), and get a haswell laptop, you'll boot to a black screen because there is no eDP support, VGA support is also questionable. This isn't something users should be exposed to, especailly as a released distro might not be out yet to support that GPU.

    But I suppose you are smarter than everyone else, so when you call something you have no clue about dumb, we should all bow down.

    Dave.

  5. #5
    Join Date
    Aug 2007
    Posts
    6,607

    Default

    Basically the idea is not that bad but i hope that there will be a stable driver stack in time for haswell release. The problem with distros like debian is, when wheezy is out it is much harder to update the userspace part only. A ppa for wheezy would be nice - that's nothing impossible to add to the u ppa infrastructure. U could possible keep track of new drivers more easyly. Replacing the kernel is in most cases not that problematic, however 3.7 changes some things so 3rd party drivers need small changes.

  6. #6

    Default

    Quote Originally Posted by allquixotic View Post
    I'm pretty sure Fedora, ArchLinux and Gentoo will default to setting this module parameter because most people who use those distros will want it (new hardware enthusiasts, bleeding edge enthusiasts, etc)
    I can say with 99.999% certainty that Gentoo will not do that. End users are free to append this to their kernel commandline should they desire it. However, we will not recommend it.

    By the way, it would be nice if my title was "Gentoo Developer" rather than just "Gentoo". It would more accurately reflect the fact that I am a Gentoo Developer. :/

  7. #7
    Join Date
    Nov 2009
    Location
    Italy
    Posts
    906

    Default

    Gentoo users will simply use an updated kernel instead of some ancient crap.
    ## VGA ##
    AMD: X1950XTX, HD3870, HD5870
    Intel: GMA45, HD3000 (Core i5 2500K)

  8. #8

    Default

    The title is definitely misleading: "Intel To Hide Early Hardware Support By Default" - they aren't hiding anything, they just don't expose experimental features by default.

  9. #9
    Join Date
    Oct 2009
    Posts
    2,062

    Default

    Quote Originally Posted by airlied View Post
    its not about accel as muhc as output setup. Would you rather they just got a black screen?

    If you ship a 3.6 kernel now in a distro (say F18), and get a haswell laptop, you'll boot to a black screen because there is no eDP support, VGA support is also questionable. This isn't something users should be exposed to, especailly as a released distro might not be out yet to support that GPU.

    But I suppose you are smarter than everyone else, so when you call something you have no clue about dumb, we should all bow down.

    Dave.
    Ok, maybe I'm missing something, but doesn't having the drivers disabled ensure that the outputs will NOT be... outputting? Disabled drivers == black screen? Or is it likely to work with crufty non modesetting ancientness using bios modes?

  10. #10
    Join Date
    Oct 2009
    Posts
    2,062

    Default

    Quote Originally Posted by birdie View Post
    The title is definitely misleading: "Intel To Hide Early Hardware Support By Default" - they aren't hiding anything, they just don't expose experimental features by default.
    s/Hide/Disable/

Posting Permissions

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