This morning after writing Intel Sandy Bridge On Ubuntu 11.04 Is Still Troubling, I proceeded to build the latest Mesa / Linux kernel / libdrm / DDX Git stack to see where the latest Intel SNB code is at and how it's running for the popular Core i5 2500K processor. Before leaving three weeks ago, everything was running great, but to much surprise, this morning it was a broken mess. Intel just regressed hard in their Sandy Bridge support for the about-to-be-released Linux 2.6.39 kernel. Whoops!
When Intel released their "Sandy Bridge" processors in early January with next-generation graphics, the Linux support was widely criticized as although they had been working on the open-source Linux driver for nearly one year at that time, it wasn't a pleasurable "out of the box" experience and building open-source graphics drivers on Linux can be a real pain. With Ubuntu 11.04, which was released at the end of April, this "Natty Narwhal" release still largely misses the Sandy Bridge support train.
There's been many individuals asking how the work is going in tracking down the major Linux kernel power regression I brought to light late last month (actually, there's at least two power regressions in the kernel). Not much progress has been made since then as I've been out of the office (and country) so I've been preoccupied with other matters, but I do happen to have another power test today to satisfy other reader requests.
The open-source graphics driver landscape is ever changing with new work going into Mesa / Gallium3D near daily. While many improvements have been made in recent time, the open-source drivers have a ways to go in competing with the proprietary competition. Even the open-source AMD driver, which is developed using documentation from AMD as well as code and engineering resources within the company, it has a tough time competing with the well-optimized Catalyst driver. Fortunately, the AMD driver is now largely centered on the two Gallium3D drivers: R300g and R600g, and have pushed away their classic Mesa DRI drivers into maintenance mode. The R300g supports the R300 through R500 ASICs (up through the Radeon X1000 series) while the R600g driver supports all ATI/AMD hardware past that point up through the latest Radeon HD 6000 series and Fusion. In this article, we are seeing where the performance is currently at for the classic Mesa, Gallium3D, and Catalyst drivers under Linux.
While AMD was very fast to provide open-source Fusion graphics driver support under Linux (along with official support in their proprietary Catalyst driver), the support has not ended up working out too well for us. It has regressed since the November push. As mentioned in March, the E-350 Fusion Linux support took a dive in terms of its graphics support with some outstanding bugs. Since then, the support has improved and is now largely usable, but there are still some big issues.
Just hours ago a new Linux KMS driver entered the world for the Cirrus GPU. Yes, as in that from Cirrus Logic for an ancient CL-GD5446 ASIC, this was a 2D-only 64-bit VisualMedia accelerator. But, fortunately, it is not for the actual hardware itself but rather the virtual incarnation that is emulated by QEMU and QEMU-KVM. Those running a Linux KVM virtualization stack with QEMU and the Cirrus adapter can now benefit from a kernel mode-setting driver.
Earlier this week Sapphire launched the Radeon HD 5830 Extreme using the well-supported "Cypress LE" graphics processor at a very competitive price relative to the NVIDIA competition and the Radeon HD 5830 graphics cards from other AMD partners. With it being part of the HD 5000 series and not one of the newer HD 6000 series graphics processors, the Linux support is already spot-on for both the official Catalyst Linux driver and within the open-source stack. In this article are the open-source Gallium3D benchmarks for the Radeon HD 5830 along with other recent ATI/AMD GPUs to show where the latest Mesa/Gallium3D code is at today.
The open-source ATI/AMD Radeon Linux driver stack has made a lot of improvements in recent times with their Gallium3D drivers becoming mature across all generations and support for new features (such as DRI2 page-flipping) landing in the mainline code and beginning to make its way to users. The time required to bring up support for new generations has also been reduced greatly and with the Radeon HD 8000 series there should be a turning point for their open-source strategy. In this article, we are providing an updated look at the course of the open-source driver's performance for the past two years.
Earlier this week was benchmarks of the NVIDIA GeForce GTX 460 "Fermi" with the open-source Nouveau driver. The reverse-engineered Nouveau support for the GeForce 400/500 series is incomplete and requires users to generate their own custom firmware before there is even 2D/3D/video acceleration support. The initial tests on the GeForce GTX 460 also yielded a disturbingly large performance difference between the open-source and closed-source NVIDIA drivers, where as with previous generations of NVIDIA GPUs the performance difference is more manageable. Here is another look at Nouveau for Fermi, but this time from a GeForce GTX 485M.
At the beginning of the month I reported on a small patch to Mesa that resulted in a huge performance improvement for Intel Sandy Bridge graphics, but Intel's OSTC developers have bumped up the performance of the latest-generation graphics processors even more. With the LLC caching patch-set, which should be committed to the Linux 2.6.40 kernel (not the current 2.6.39 cycle), there are measurable OpenGL performance improvements.
This morning I mentioned that work from last year's Google Summer of Code project on improving the ATI Radeon R300 compiler for the Mesa Gallium3D driver had never stopped. Tom Stellard's latest R300 GLSL compiler work has been focused on improving the register allocator. Tom's initial figures showed roughly a 10% boost for software with intensive OpenGL shaders, but here is what my test results show for this yet-to-be-merged code.
With NVIDIA still not providing any open-source support or technical documentation for their graphics processors, for those in the open-source community who seek to use their GeForce 400/500 "Fermi" GPUs without NVIDIA's binary driver, they are left to use the reverse-engineered, community-created Nouveau driver. Fortunately, the support for the NVIDIA Fermi GPUs is coming along at a respectable pace -- with even working OpenGL acceleration -- considering that NVIDIA is providing no support at all. In this article are the first benchmarks of this experimental GeForce 400/500 "Nouveau NVC0" driver versus NVIDIA's official proprietary driver.
As I began to share over the weekend, the community-created Nouveau driver that's open-source and is written by clean-room reverse-engineering the NVIDIA binary display driver, has reached a serious milestone. For low-end NVIDIA GPUs, the Nouveau driver based upon the Mesa Gallium3D architecture is now as fast, or even faster, than NVIDIA's official proprietary driver.
Earlier this week I talked about the direction of ATI Radeon graphics in Ubuntu 11.04, which is quite positive with there being measurable 3D performance improvements in the latest open-source driver code, after a week prior talking about a massive Intel Sandy Bridge performance fix that is able to now put the open-source Linux performance closer to being on-par with Intel's Windows OpenGL driver. How though is the performance of Intel's previous-generator Clarkdale/Arrandale graphics looking? Quite good too. Here are some quick benchmarks.
With Ubuntu 11.04 arriving in a little more than a month, the key packages to be found in this "Natty Narwhal" release are nearly settled. For those concerned about the open-source ATI graphics stack, the packages to note are the Linux 2.6.38 kernel, Mesa 7.10.1, and xf86-video-ati 6.14.0. What does this mean for the conventional user? This article provides a brief look at the state of open-source ATI in Ubuntu 11.04.
There have been a number of Intel Sandy Bridge articles on Phoronix since the January launch of this next-generation Intel CPU micro-architecture. It's ranged from the Linux support being challenging to dealing with motherboard problems and then the graphics performance being fast relative to previous generations of Intel graphics and for being based upon the classic Mesa driver architecture, but much slower than Windows. Last week then the Sandy Bridge Linux performance became much more interesting after a simple patch led to a huge performance win to the point that the open-source Linux driver performance is much closer to their full-featured Microsoft Windows driver. What is the next chapter in the Intel Sandy Bridge Linux story? A look at the VA-API video acceleration playback performance.
After some initial Linux troubles, last month we finally got Intel Sandy Bridge graphics working under Linux. The latest Intel CPUs (such as the Core i5 2500K) with integrated graphics are blazingly fast, and the classic Intel Mesa driver was fast compared to other open-source Mesa / Gallium3D drivers, but it still was a ways behind the low-end discrete graphics cards with the proprietary AMD / NVIDIA drivers for Linux. It was also shown that the Intel Linux Mesa driver is much slower than the Intel Windows driver for Sandy Bridge, as we had also found was the case for previous generations of Intel graphics. Committed to the Mesa mainline Git repository this week though was a very important Sandy Bridge change. While the commit only touched 13 lines of code (11 lines of new code, 2 lines of changed code), it has dramatically improved the Sandy Bridge Linux performance as our results show in this article.
While Intel remains to be the only major graphics vendor standing strong behind their classic Mesa driver on Linux for open-source support rather than drawing up plans to move to the Gallium3D driver architecture, there is actually available a Gallium3D driver available for Intel hardware. This Intel Gallium3D driver has been around since close to Gallium3D's inception, but it targets the older generations of Intel IGPs and was developed by VMware as a proof of concept. The driver is incomplete, but our testing shows that for those with Intel 945 netbooks and other hardware, the "i915g" driver is usable. In this article are benchmarks showing how this Intel Gallium3D driver compares to Intel's officially supported classic Mesa DRI driver.
AMD put out a rare beta Linux driver this Monday and they have now just announced the release of the Catalyst 11.1 driver as their stable monthly update for Linux and Windows users. With this Catalyst driver, there is though one interesting but hidden feature that is sure to please many ATI/AMD Radeon Linux desktop users.
Earlier this month I reported on good and bad news for the Nouveau Gallium3D driver with the good news being that for the hardware that played well with this reverse-engineered open-source driver, the OpenGL performance was not too bad in most instances compared to NVIDIA's official proprietary driver. There still is quite a difference in performance between the two NVIDIA Linux drivers, but it is a usable experience in a number of cases and is not too bad for Nouveau being a community-driven driver. However, the bad news was that non-GeForce 8 hardware had regressed to being non-functioning. Since that article, however, using code that is some more recent I have the GeForce 9 and GeForce 200 acceleration working again. The current code though leaves a lot to be desired.
A week ago I reported on the open-source ATI driver becoming a lot faster thanks to the KMS page-flipping support finally landing in the mainline Linux kernel and xf86-video-ati driver, tiling improvements, and lots of work going into the R300g/R600g Gallium3D drivers. The open-source ATI Gallium3D is not conclusively faster than the proprietary Catalyst driver is, but it's becoming a much more competitive race. In last week's article an ATI Mobility Radeon GPU was used to illustrate these improvements, but in this follow-up article are the Linux benchmark results for three discrete Radeon graphics cards using the stock Ubuntu 10.10 open-source ATI driver, the last R500-supported Catalyst Linux driver, and then the latest open-source driver bits from the Linux 2.6.38 kernel.
For the past year or so we have been fascinated by the LLVMpipe driver on Mesa's Gallium3D driver architecture for accelerating OpenGL on your CPU (or any other Gallium3D state tracker) as a means of a more efficient and viable software rasterizer for Linux. Mesa's long-standing software rasterizer (swrast) driver is slow and next to useless while LLVMpipe is many times faster thanks to leveraging the Low-Level Virtual Machine and other optimizations atop Gallium3D. However, in order to run a basic OpenGL game purely on the CPU you still need a powerful CPU, but we are pleased to find there are some noticeable performance improvements to be found in Mesa 7.10.
In testing of OpenBenchmarking.org and preparations for the release of Phoronix Test Suite 3.0-Iveland at the end of February from SCALE, a lot of benchmarks have been happening to test the various analytical features and other new capabilities of this open benchmarking platform. In fact, it is really an overwhelming amount of benchmarks; the power capacity in my office is maxed out as benchmark after benchmark and system after system there is all sorts of test scenarios being looked upon. The benchmarks coming out on Phoronix.com over the past two months have just been barely scratching the surface of what has been going into the OpenBenchmarking.org system. Recently a lot of OpenCL compute benchmarks were pumped in, and since we have only published a few OpenCL Linux benchmarks -- OpenCL on Linux vs. Mac OS X and OpenCL NVIDIA vs. ATI on Linux -- here's some more in this article.
Now that the kernel mode-setting page-flipping for the ATI Radeon DRM kernel module has been merged into the Linux 2.6.38 kernel and the respective bits have been set in the xf86-video-ati DDX, we're in the process of running new open-source ATI graphics benchmarks under Linux. Our initial results (included in this article) show these latest improvements to cause some major performance boosts for the open-source ATI driver as it nears the level of performance of the proprietary Catalyst driver.
With our big AMD Linux GPU / driver comparison we found its open-source Gallium3D driver to be noticeably faster than the classic Mesa DRI driver across an array of Radeon hardware from multiple generations. However, the official Catalyst driver was multiple times faster (roughly 5.18x faster) than the Gallium3D driver, not to mention its lack of proper support for OpenGL 3/4, VA-API/VDPAU/XvBA video playback, and many other features only found within the proprietary Catalyst driver. Now though it is time to see how the Gallium3D Nouveau performance compares to that of NVIDIA's proprietary Linux driver across different GeForce graphics cards.
As was alluded to in our New Year greeting, we have been working on a massive graphics card / driver comparison under Linux. Beginning with ATI/AMD hardware, we have tested a series of graphics cards spanning the Radeon X1000, HD 2000, HD 3000, HD 4000, and HD 5000 generations using the very latest drivers. These drivers include the official Catalyst 10.12 Linux release as well as the very latest development code for the open-source Mesa and Gallium3D drivers. The results for seven ATI GPUs spanning four generations with three drivers are quite interesting.
Earlier this week we published our annual look at AMD's Catalyst driver releases from the past year. Not only did the Catalyst Linux driver this year picked up a couple new features, its driver performance had improved slightly over the past twelve months. In building up some initial test data for OpenBenchmarking.org we decided not only to do these tests on the latest consumer-grade graphics card this year, but expand it to cover the workstation performance too and to go back nearly two years in time. These results for an AMD FirePro V8700 graphics card with the monthly driver updates going back to Catalyst 9.2 are quite interesting. AMD announced twice this year optimizations to their FirePro driver software, but in reality these "optimizations" were largely unsustainable and not optimizations as much as they were attempting to address driver regressions from the past.
Earlier this month we delivered our annual performance look at NVIDIA's 2010 Linux graphics drivers and now the tables have turned to do our annual examination of the ATI/AMD Catalyst graphics drivers for the Radeon graphics processors. This was certainly an interesting year -- both good and bad -- for AMD with their Catalyst Linux driver.
At the end of each year for the past five years we have delivered "year in review" articles looking at the performance of NVIDIA's (and ATI/AMD's) proprietary Linux drivers. Both in terms of new features introduced during the year in their driver updates and benchmarking the driver releases to see how the performance has evolved over twelve months. With 2010 coming to an end, it is time for this year's driver reviews. We are starting this year seeing how the NVIDIA performance has matured in 2010.
Yesterday we shared benchmarks of the ATI R600 Gallium3D driver compared against the classic Mesa R600 driver and then the proprietary AMD Catalyst driver. The proprietary driver was much faster than the open-source drivers were, but the Gallium3D driver did possess higher performance in most of the tests than with the classic Mesa driver. This is similar to the R300 Gallium3D driver being faster than its now-deprecated R300 classic driver. Meanwhile though Intel continues to back only their classic Mesa DRI driver and there are no signs of them switching over to the Gallium3D architecture anytime soon. It is not as if Intel's current Mesa driver is feature-complete and performance-optimized as our tests from earlier this year show Intel's Linux graphics performance being far behind their Windows driver. In this article though we are seeing where the Intel Mesa performance is at when using the very latest DRM and Mesa code.
716 display drivers articles published on Phoronix.