Graphics on Linux has been rather interesting lately. If you’ve been keeping up with the news on DRM, kernel, Mesa and X.Org development, you must’ve been aware that Gallium3D in Mesa’s git (what’s to be 8.1 this October) has complete OpenGL 3.0 support for almost all drivers — the xorg state tracker actually works and they have a VDPAU state tracker, which too works with most GPUs. The xorg state tracker is kind of interesting because it uses Gallium3D to directly run the X.Org stack, dropping the need for a X.Org driver (think of it as the vesa driver, with full-blown acceleration, if your card has a Gallium3D driver in Mesa).
X.Org Server 1.13
Anyway, the latest chapter in this saga is X.Org Server 1.13. RC1’ed just yesterday, it brings in a bunch of changes:
- XAA’s gone. It didn’t work anyway, for the last two years — a patch left it in a broken state, and it couldn’t do any off-screen rendering, basically rendering the composite extension useless. It’s formally gone now, and all the graphics drivers which used to do XAA have been updated to use EXA. Intel uses UXA though, and they have a new experimental architecture which they call SNA (SandyBridge New Architecture) — which works for cards as old as the I865G, up to the Ivy Bridges. It’s blazing fast. Seriously.
- There’s been a bunch of driver API changes. Mostly relating to the above mentioned removal of XAA, but now that RandR 1.5 is in too, there’s native support for GPU-hotplugging, multi-GPU configurations and stuff like rendering the output on a big GPU and outputting the image using the MoBo’s IGP. In short, bonanza if you’re using Crossfire or SLI. Again, before the X.Org Server is out, the drivers already have support for this new API.
- A half a million lines-of-code patch did nothing but fix coding style. The entire patch was auto-generated. It removed 259,934 lines of code and added 264,651.
And there’s a bunch of changes with how X.Org now takes advantage of OpenGL 3.0. Specifically, something called GLX_ARB_create_context is in, which basically lets X create OpenGL contexts with profiles for any version of OpenGL upto OpenGL 3.2 (Mesa itself support only upto 3.0).
Wayland
Wayland is finally going to see its first release around the September-October mark. The main compositor/desktop manager called Weston now works pretty well, and XWayland, which provides an X.Org API over Wayland/Weston is coming along just nicely.
Wayland relies on KMS, DRM and Gallium3D, so you won’t be seeing Wayland on ATI’s FGLRX or nVidia’s Forceware anytime soon, if at all. The good news is, the open drivers for Intel and Radeon are in such a good state that it doesn’t make much sense to use the proprietary FGLRX driver at all (except if you’re using a Radeon HD7XXX card, in which case the RadeonSI open driver doesn’t work at all yet). However, Nouveau is still on the slower side, and is still extremely buggy.
DRM
The Linux Kernel’s Direct Rendering Manager (DRM) has seen a steady stream of updates as well. While the most number of changes have been seen by the radeon driver, incremental updates have hit the Intel and Nouveau DRM drivers too.
Radeon finally uses PCI Express 2.0 support wherever it’s been deemed not to be buggy. Now radeon.pcie_gen2 is enabled by default, so if your card starts acting up, you’ll have to add radeon.pcie_gen2=0 to the kernel boot parameters to disable this.
A quality SanDisk flash memory provides good storage for your documents.
That’s pretty much the interesting things that’ve been happening in the Linux graphics arena. If you want buying advice, stick to the AMD APUs that come with AMD Radeon HD6XXX cores on the processor die — they’re awesome hardware (hey, Radeon will always blow Intel hardware out of the water) and they work awesomely with Linux. The Ivy Bridge i7s make good choice for people who want beefy number-crunchers and won’t be gaming much.
Feature image courtesy: -= Treviño =-. Reused under the terms of CC-BY-NC-SA 2.0 License.
nice post