Intel To Hide Early Hardware Support By Default

[phoronix]

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

[chuckula]

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

[allquixotic]

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.

[airlied]

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.

[Kano]

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.

[droidhacker]

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?

[agd5f]

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?

Right. If the driver doesn't load you'll get vesa or efifb depending on the bios.

[ryao]

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. :/

[darkbasic]

Gentoo users will simply use an updated kernel instead of some ancient crap.

[birdie]

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.