After the benchmarks a few days back of Intel Sandy Bridge Acceleration On Non-SNB Hardware, Chris Wilson of Intel who has been responsible for much of the "Sandy Bridge New Acceleration" work requested more tests, but this time to see the effect that the compositing window manager has on this new acceleration architecture. As a result, here is some quick tests of Intel's Sandy Bridge graphics under the Unity, Unity 2D, and GNOME Shell desktops.
Last week benchmarks were published of Intel's New Sandy Bridge Acceleration architecture (SNA) that showed several performance improvements for 2D and 3D, but the new acceleration architecture still wasn't mature with a few regressions compared to the normal UXA back-end. While the focus of this SNA support is on speeding up operations for Sandy Bridge (SNB) and forthcoming Ivy Bridge (IVB) hardware, SNA is supported for older Intel graphics processors too. Here are some benchmarks of the Sandy Bridge New Acceleration architecture when using the Ironlake and Gen3 back-ends.
In preparing for XDC2011 Chicago, the X.Org developers' summit that begins in just ten days that I have organized, the schedule is being worked out at the moment. One of the items that is set to be talked about at XDC2011 during the Nouveau driver discussion is TimeGraph. This is an open-source GPU command scheduler that sounds fairly interesting.
In early June there was the introduction of the Sandy Bridge New Acceleration Architecture by Intel that dramatically excelled the 2D and 3D performance of their processor graphics on their Sandy Bridge hardware along with previous-generation IGPs. Here is a look at how the SNA acceleration architecture is performing today.
A month ago we looked at the Radeon HD 6550D graphics performance from the AMD Fusion A8-3850 (a new "Llano" APU) under Linux when using the Catalyst driver. However, bugs at the time had barred a comparison of the Llano graphics under Linux with the open-source Mesa/Gallium3D driver. Fortunately, we now have a working open-source Radeon driver configuration to deliver these comparative AMD Llano Linux OpenGL benchmarks.
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.
770 display drivers articles published on Phoronix.