Yesterday I wrote about Ubuntu 14.10 not yet having X.Org Server 1.16 even though the first beta was issued this week and there's been a testing package repository for more than one month. This lack of X.Org Server 1.16 thus far is apparently due to AMD with not yet having a supportive Catalyst driver.
In the comments to yesterday's story, Timo Aaltonen of Canonical and part of their X/graphics team responded. "no fglrx, can't force people to switch to radeon and likely regress, on newer hw at least."
So Canonical is keeping away from using the latest X.Org code since the Catalyst (fglrx) driver doesn't yet support it and they don't want to regress users by forcing them to use the improving but still less than perfect open-source driver. Canonical's effectively bowing down to a binary blob.
As earlier this week I did a 20-way AMD Radeon open-source comparison, looked at the most energy efficient Radeon GPUs for Linux gaming, and then yesterday provided a look at the fastest NVIDIA GPUs for open-source gaming with Nouveau, in this article is a culmination of all the open-source graphics tests this week while seeing how Intel Haswell HD Graphics fall into the mix against the open-source Radeon R600/RadeonSI and Nouveau NV50/NVC0 graphics drivers.
Beignet is the project out of Intel's Open-Source Technology Center for exposing GPGPU/compute capabilities out of Ivy Bridge hardware and newer when using a fully open-source Linux stack. While Beignet differs greatly from Gallium3D's Clover state tracker, this Intel-specific open-source OpenCL implementation is working out quite well for Ubuntu Linux.
While I've been writing about Intel's Beignet project since early 2013, it's probably been about a year now since I tried out the code, which is developed by Intel's OTC graphics team in China. This weekend I tried out Beignet v0.9.2 as trying out the newest Intel OpenCL code has been on my TODO list for a while and it's been working out rather well in my initial tests.
In this article the NVIDIA hardware is being benchmarked to a similar stack from earlier this week with Ubuntu 14.04 LTS and then upgrading to the Linux 3.17 Git kernel and employing the Oibaf PPA for the upgraded xf86-video-nouveaui DDX and Mesa/Gallium3D drivers. Compared to the Radeon tests, the Nouveau driver was bumped slightly ahead to address a Nouveau driver problem that otherwise was a show-stopper. So even though it shows Mesa 10.3-devel vs. Mesa 10.4-devel, it's just a few days difference of Mesa Git due to the recent branching of Mesa 10.3. The rest of the stack was maintained the same for this Nouveau Linux gaming tests. The tested NVIDIA hardware included both old and new graphics processors:
Frame-buffer compression (FBC) support was disabled by default in the Linux 3.15 stable series for Haswell hardware and newer since the support wasn't mature and there were Intel HD Graphics users reporting issues with this feature being turned on, so it was disabled by default and hidden behind a kernel module parameter. After an Arch Linux user experienced a 4+ Watt increase in power draw for his Apple laptop, he bisected it to this FBC feature, but Intel Linux developers weren't expecting FBC to make such a huge difference in power draw. The matter is still being investigated but FBC simply can't be flipped back on by default since the code is incomplete and there's still some unmerged patches under review that won't make it until at least the Linux 3.18 kernel.
Upstream Nouveau was unaware of this issue that was affecting my entire assortment of NVIDIA GeForce hardware so it was then quickly assumed to be an issue with the Oibaf PPA that constantly is packaging the latest open-source Linux GPU drivers. On top of mainline Mesa Git, recently there's been the the Gallium3D Direct3D 9 patches (Gallium-Nine). While none of my testing was relying upon the Gallium-Nine D3D9 support, it was wreaking havoc on the system anyhow.
As of earlier today some patches were backed out of the Oibaf PPA and since getting back closer to Mesa mainline the Nouveau problems are a matter of the past. With that said, now I'm in the process of running some Nouveau Steam/Source Engine Linux gaming tests similar to today's 20-Way Radeon Comparison With Open-Source Graphics For Steam On Linux Gaming.
When it comes to Linux gamers wanting a discrete graphics card backed by open-source drivers, the only solution right now to truly recommend for those serious about performance and making use of the hardware is really AMD Radeon graphics. While Nouveau has been making much progress, until re-clocking and other issues are worked out the performance can be unbearably slow depending upon the particular graphics processor or run into other problems. (Of course, when talking about proprietary graphics drivers on Linux, the story is entirely different, or if considering integrated Intel HD Graphics.) For those pursuing a AMD Radeon GPU for their own Steam Box/Machine build and hope to use the open-source Gallium3D drivers, here's some Steam on Linux gaming benchmarks from almost two dozen different GPUs.
This week I've been running a large open-source graphics card comparison using Mesa 10.3-devel and Linux 3.17 from Git. While the intentions were nice with featuring Intel/NVIDIA/AMD graphics, running several benchmarks of Steam / Source Engine games on Linux, and also measuring the power efficiency and thermal performance, the testing was cut short when it came to the Nouveau driver testing.
As a forewarning to casual Linux users that might be running Nouveau for your GeForce hardware and once in a while update against the Oibaf PPA or Ubuntu Mainline Kernel PPA, it appears there's some bad issues right now affecting at least Ubuntu Unity users... Today in trying out several graphics cards from Kepler GPUs to old GeForce 9 hardware, there's very evident on-screen corruption and rendering problems with all the NVIDIA hardware tested thus far.
Yesterday's comparison was just about looking at the open-source performance (now that it's finally working) of the Radeon R9 290 compared to other AMD Radeon HD/Rx graphics cards on the same open-source driver stack. In today's article we're exclusively looking at the Radeon R9 290 performance when testing both the latest open and closed-source drivers. On the open-source side was the Linux 3.17 Git kernel, Mesa 10.3-devel, xf86-video-ati 7.4.99, and other Git components supplied by the Oibaf PPA atop the Ubuntu 14.04 LTS installation. On the closed-source AMD side was the Catalyst 14.6 Beta that was the latest at the time of testing.
Handling merge requests for the DRM graphics driver updates will be done differently for the Linux 3.18 kernel, which will result in a few less weeks of development time.
David Airlie of Red Hat, the DRM subsystem maintainer, generally has been allowing new Direct Rendering Manager (DRM) code to be introduced to his drm-next tree up to around the time a given kernel release occurs. After that, within days, it could end up landing in the mainline Linux kernel when the merge window opens ahead of the next -rc1 release. David though is deciding to be a more strict about changes late in the cycle in hopes of leading to better tested code and less fallout from driver problems each kernel development cycle.