If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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

<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

<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

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

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.

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

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.

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

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