While the Linux power consumption may be up on recent kernels depending upon your hardware configuration, there's a few known but not too commonly used tweaks for reducing your system power consumption and extending your battery life when using Intel integrated graphics on your favorite Linux distribution.
While the BFS scheduler is getting ready to celebrate its second birthday, in just three weeks AMD's open-source Radeon graphics driver strategy for Linux will be turning four years old. It was on the 6th of September in 2007 that I exclusively broke the news to the world on AMD's open-source strategy, which has ended up being a game-changer in the Linux world. AMD continues to support open-source hardware enablement on their latest graphics processors and recently even hired more developers to work on the code and documentation. How far have they come though in four years?
Besides boosting the Intel Sandy Bridge performance, the Linux 3.1 kernel is also great for open-source graphics in that it has improved support for NVIDIA GeForce 400/500 "Fermi" graphics cards via the reverse-engineered Nouveau driver. The Linux kernel has already supported kernel mode-setting for these GPUs and then more recently there was 2D/X-Video acceleration as well as 3D acceleration when paired with the Nouveau Gallium3D "NVC0" driver. The accelerated support though has required manually extracting the graphics processor's microcode after the GPU was initialized by the proprietary driver. With the Linux 3.1 kernel, Nouveau can generate its own "FUC" microcode to circumvent this problem. In other words, there is now "out of the box" open-source support for NVIDIA GeForce 400/500 graphics cards.
Last week the DRM pull went in for the Linux 3.1 kernel. For the Intel DRM graphics driver in the Linux kernel there is frame-buffer compression clean-ups, high color support, ring frequency scaling, shared LLC support, and hang-check module disabling. Compared to the Linux 3.0 kernel, the driver improvements significantly boost the open-source graphics performance for Intel Sandy Bridge hardware.
After a short delay, Mesa 7.11 has been released. This is the user-space library for providing OpenGL support under Linux for the open-source Intel, ATI/AMD, and NVIDIA drivers, among other hardware and software-based drivers. The Mesa 7.11 release also offers updates to the Gallium3D driver architecture. Here is some of what you can expect to find on Mesa 7.11.
Following last week's benchmarks of Intel's New Sandy Bridge Acceleration architecture with the very latest open-source driver code, it was decided to throw a few NVIDIA and ATI/AMD graphics cards into the mix to see where the open-source driver performance is comparatively at for some other hardware. This article presents these Linux graphics results for eight configurations.
Being merged into the mainline Mesa tree once Mesa 7.11 has been released is the GLSL-To-TGSI translator. This allows core Mesa to translate directly from GLSL IR to TGSI, rather than stepping through the crufty Mesa IR, before reaching the Gallium3D hardware drivers. It's more efficient this way -- leading to possible performance improvements -- and it's also a stepping-stone in bringing GL Shading Language 1.30 support, which is required for OpenGL 3.0 compatibility.
Open-source code supporting the AMD Radeon HD 6000 "Northern Islands" GPU hardware has been available since January, but only in the past few days has this Linux code matured to the point of being stable and useful for testing. In this article are our first benchmarks of the AMD Northern Islands and Cayman graphics processors using the open-source Mesa Gallium3D driver and comparing its performance to AMD's proprietary Catalyst driver.
The new benchmarks going out today on Phoronix are looking at the performance of Intel's Sandy Bridge graphics with the latest Microsoft Windows 7 and Ubuntu Linux drivers. Not only are we using the very latest drivers, but there is also a separate Linux test run with SNA, the "Sandy Bridge New Acceleration" architecture enabled.
As noted last week on Phoronix, Google has Chromium OS engineers making improvements to Intel's Gallium3D driver even though this open-source Linux driver isn't officially supported by Intel Corp. Google's interested in shipping the Intel Gallium3D driver on their Chromium OS netbooks in order to take advantage of the Low-Level Virtual Machine (LLVM) and other Gallium3D features to make up for the netbook's lack of vertex shader hardware. How does this community-maintained Intel 3D driver now compare performance-wise to Intel's official classic Mesa driver? Here is a fresh set of benchmarks from the latest Mesa Git code over the US holiday weekend.
Following last week's completion of the Radeon driver power management tests against the AMD Catalyst driver, now it is time to turn the tables on NVIDIA. In this article are some power consumption and thermal tests when comparing the latest open-source "Nouveau" driver code against NVIDIA's closed-source proprietary driver.
Today on Phoronix are not only new benchmarks of the proprietary Catalyst graphics driver compared to the open-source Radeon Linux driver alternative when looking at the OpenGL frame-rates, but also metrics on a number of other fronts. In this article is a graphics driver comparison when looking at the system power consumption, GPU operating temperature, and CPU usage too. The results are quite interesting and not commonly looked at on Phoronix or by users.
The first of the AMD Radeon HD 6000 "Northern Islands" graphics cards launched late last year, and while the open-source Linux driver support is technically there for those interested in this alternative to the proprietary Catalyst driver, the support is still largely broken. Here is a quick look.
Last week we provided a fresh look at the AMD Radeon Gallium3D performance using the latest development code for the Linux 3.0 kernel and Mesa 7.11 library. Today we are now looking at the Gallium3D driver performance of the Nouveau driver that is reverse-engineered to support NVIDIA GeForce graphics processors.
As noted earlier in the week, the open-source AMD Radeon "R600g" driver that supports 3D acceleration on Radeon HD 2000 series graphics cards through the latest Radeon HD 6000 and Fusion graphics processors, is becoming quite fit. The driver is nearing a point of stability, is mature enough for most desktop users, and it is beginning to receive some performance optimizations and other improvements. Thanks to this recent work, plus the ongoing development of the Linux 3.0 kernel, here is a fresh set of AMD Gallium3D Linux driver benchmarks.
It has been about a month since we last delivered ATI/AMD Radeon Linux benchmarks comparing the performance of the open-source driver against the high-performance proprietary driver. Since that point there's been various improvements to the Mesa/Gallium3D driver and there's also been the merge of the latest Radeon DRM code for the next kernel, which will likely be called the Linux 3.0 kernel, but in the DRM pull request was referred to as Gardenshed. Here are these benchmarks on several different Radeon graphics cards.
For the past five months when mentioning Intel graphics at Phoronix, it's been pretty much about their latest-generation Sandy Bridge hardware and most recently about their next-generation Ivy Bridge. The talk has either been about new hardware enablement, performance improvements, or bad regressions. In this article, we are going a generation back to look at how the Clarkdale/Arrandale-Ironlake graphics performance has evolved under Linux over the course of Ubuntu releases.
While last week we reported Intel Sandy Bridge graphics support is still troubling in Ubuntu 11.04 and also the support broke at the last minute in Linux 2.6.39, there's really good news to report this week from the Sandy Bridge Linux land. When using the very latest working Linux driver code, in many cases the OpenGL performance of this open-source driver stack is now faster than Intel's official Windows 7 driver.
With the very latest open-source Linux driver code for the AMD Fusion E-350, the support is finally stable and comparable to that of other recent Radeon HD graphics processors with the open-source driver stack.
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.
825 display drivers articles published on Phoronix.