Originally Posted by
allquixotic
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.
De-modularized X with drivers in the xserver ==> worst possible situation.
Modularized X, Mesa Classic DRI ==> Status Quo. Quite bad, but not the worst.
Modularized X, Mesa Gallium3d ==> Getting Better. Should become status quo but Intel says no.
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.
Senior Member
Posting Permissions
Reply With Quote