Valve sponsors Mesa development
lunarg.com
lunarg.com
So it is beneficial if code can be shared between hardware drivers. You could have a full implementation for each GPU/vendor, each with its own set of bugs, missing features and incompatibilities. Or you can do as Mesa did and try to implement the hardware independent parts in a common place, and have just the hardware-specific parts implemented by the drivers.
For example you definitely don't want a separate implementation of the GLSL compiler for each GPU/vendor, GLSL is compiled to an intermediate representation and that is then further translated to hardware specific instructions. (although in practice I think you still have 2 implementations: one for Intel, and another for all other Gallium drivers)
Think of it this way: would you like a full C compiler written from scratch for each CPU architecture, or would you want to share where possible (parser, type checker, hardware-independent optimizers, etc.).
So an analogy would be: GCC frontend is like core Mesa, and a GCC backend is like a Mesa hardware driver. Another analogy would be libc: the majority of the code is hardware-independent that implements the various C99/POSIX APIs (i.e. like core Mesa), with just the hardware-specific parts / optimizations implemented in assembly (i.e. like Mesa drivers).
First you don't want every draw call to cause a system trap. Thus some drivers include a dynamic library which gets loaded into the program’s memory space.
Then after the library comes a daemon. Between the library and the daemon is where the OpenGL implementation lives.
The daemon then hands off to the driver. The driver is meant to be a light interface to the GPU. The thinking being the kernel is not the right place to transform OpenGL to hardware instructions. If one did write an OpenGL implementation in a kernel driver then we could expect some harsh words from Linus.
Now on a pedantic note the GPU already handles pushing the bits to the screen without the driver's help. Which is good because you do not want to introduce yet another timing dependent driver class like the networking stack.
I'm not sure where the shader compilation occurs.
1. Kernel Module Hardware Drivers (radeon, i915, nvidia, etc)
2. DRI to interface with the kernel
3. Mesa DRI Drivers, providing the translation from libgl to DRI / kernel module. Examples are the Intel driver and Gallium architecture, which provides AMD, Nvidia, Tegra, Mali, and Ardreno drivers and share even more code.
4. LibGL, the shared library provided at /usr/lib/libGL.so
Your application links against libGL, which is the implemented OpenGL API.
The distinction between Gallium and Intel can be useful to clarify here - Gallium has an internal API called Winsys that is the minimum command set drivers can support, "state trackers" that provide translation layers for various APIs (OpenGL, OpenCL, Openmax, Direct3D) to that base API.
Mesa libgl will call into the DRI drivers, and if they are Gallium drivers that is through the OpenGL state tracker, where the vendor specific code will get a pass off of shader code and instructions to translate into the winsys layer, which is what the underlying drivers will translate to the command stream for the GPU hardware.
Intel implements that entire part on their own - they have their own separate implementations of openCL (beignet) and openGL to hardware translation.
http://blog.mecheye.net/2012/06/the-linux-graphics-stack/
Not claiming I understand it all, but it's long because graphics are complicated :) I have been surprised at how device-dependent graphics software is.
I wonder if Windows or OS X has nicer graphics abstractions than Linux? i.e. that make it less of a mess?
In an ideal world it would be obvious where to draw the line between the GPU- and vendor-independent bits and the common code shared by everyone, but not only is that very hard to do, it can change drastically over the years. Couple that with the fact that platform vendors have to maintain these imperfect interfaces for many years regardless, and that vendors can have their own abstraction layers in between the top layer of their driver code and the bare metal of all their GPUs, and you have a perfect storm of too many layers getting in the way and imperfectly defined interfaces to many of those layers, which necessitates occasional layering violations at every level of the stack if you want to avoid some pathological performance bottlenecks for some GPUs.
At best you end up with a bunch of ugly, imperfect, but generally functional software that more or less gets the job done at an acceptable level of performance.
I would imagine that the situation with Linux just adds yet more issues to that bag of hurt. GPU vendors don't always want to help out, and are likely to withhold valuable technical information that they don't want to be public. The whole process of defining how many layers there are, what functionality exists at what layer, and what interfaces are used between the layers is almost by definition (for GPU driver models at least) a bunch of questions for which there are no good answers, which is also a perfect storm for Open Source development. Any solution anyone comes up with is always going to have some caveats and gotchas, which for open, egalitarian development models means endless arguments and bikeshedding in which everyone involved is correct in pointing out the weaknesses of the system as designed, but there are no alternatives that anyone can point to that don't have similar problems in someone else's eyes.
For example, back in the '90s, for right or wrong I was very optimistic about GGI solving a lot of graphics problems for Linux, and that was limited to the 2D stuff (I can't imagine how controversial it would've been had it included 3D as well):
http://en.wikipedia.org/wiki/General_Graphics_Interface
It didn't pan out that way, but so much energy was burned by so many people arguing about it over so many years. :( I don't have authoritative knowledge of the whole thing, so maybe the doubters were correct, but at the time it felt like a bunch of people shooting down an imperfect solution while offering no solution at all.
EDIT: TL;DR designing a graphics stack that ultimately goes down to the metal is a set of very hard problems, many of which have no perfect answers. This, coupled with secretive vendors and the level of specialized knowledge required to even contribute to stuff like this, makes it an even harder problem in the Open Source world. Not an insurmountable obstacle, but a really hard set of problems nonetheless, for both technical and human reasons.
I don't really game any more but like to support the ecosystem.
Intel is ok too, but their hardware is not really targeted for gamers.
That being said, if you are fine with using proprietary drivers, currently nothing beats nVidia in terms of performance, features and stability of OpenGl drivers.
You would be supporting the ecosystem with any purchase, but if you are politically inclined on free software then the choice is AMD or Intel.
FWIW, I find the latest graphics units from Intel, e.g. HD 4600, rather okay. Even graphically nontrivial things like Crusader Kings II or KSP run decently, although usually far from the highest possible settings. But on the other hand, the drivers are rock-solid, delivered directly in Debian without any fiddling around as was/is necessary for the Nvidia drivers and I don’t need my own powerplant just to run a computer :)
The Maxwell-based 750ti is the card to buy then. It's tiny, draws a reasonable amount of power and I've yet to see a game that doesn't run well on high.
I had a 7770 for a year before I switched to Nvidia. Better all around.
Still AMD do sponsor open source driver development, I'm told, so it's up to how much you're willing to sacrifice for this.
I eventually ended up buying a radeonsi card and while the extra GPU oomph is nice, the lower stability is not.
Valve is probably the most influential single entity in PC gaming, for them to embrace open-source to this degree is massive...
I am a gamer on Linux, but there's no reason these games will run better on Linux vs Windows or use the controller better (since they will probably support the controller drivers for Windows systems as well). Valve has repeatedly said they would not do any exclusive titles for any platform as well, so I don't think just a couple of great games will drive much Steambox sales. There are going to be several drivers for Steamboxes: 1) the hardware needs to be cheap enough 2) the experience needs to be seamless and AS GOOD as a console if not more 3) enough big games to ensure you do not miss too much by not staying on Windows.
Dota 2 is probably memory bandwidth limited on Intel/Linux/OpenGL and that is likely the case for other games too.
So maybe modifying the OpenGL part of the game engine a bit to take memory bandwidth constraints of Intel GPUs into account would help more.
When I was looking into the issue of Intel GPU peformance on Linux many months ago there were no tools to profile memory bandwidth bottlenecks.