1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

How Old ATI GPUs Can Be Faster On Open Drivers

AMD

Published on 13 February 2011 09:41 AM EST
Written by Michael Larabel in AMD
116 Comments

A few days ago when publishing the results of benchmarking a lot of graphics cards on their Gallium3D drivers (about a dozen graphics cards) this left a number of people surprised. A number of these results from the open-source Gallium3D drivers illustrated the older graphics processors as being much faster than the newer hardware, even though the newer hardware is far superior to the vintage products. This shouldn't have been a surprise if you stay up-to-date with the Linux graphics news on Phoronix, but it comes down to features found in the older Gallium3D drivers not yet implemented in the newer open-source drivers.

Among the comments in our forums about the old GPUs beating the newer ones included:
I wonder how a card from 2005 (x1800) with 8:16:16:16 config core and only 8 GP/s in pixel and texture fillrate is able to outbeat with nearly 2x speed a card from 2009 with 640:32:16 config core and 9.2, 18.4 fillrates accordingly. The difference in tests also varies to great degree. Maybe there is a lot of unimplemented hardware features and 1800 is card which arch have got most of attention?..

LOL my old X800 8-9 year old card beat the newest intel shit 2500K LOL

r600g driver is not working truly right in performance section: hd3850 is usually performing faster than hd4830 and hd5750. hd4830 has just two times the processing power than a hd3850. hd5750 have more than two times the processing power of a hd3850 and some more memory bandwidth and still performing worse.

On the ATI side, the reason for older GPUs often running faster than the newer GPUs is that the Radeon X1000 (R500) GPUs and earlier run on the "R300g" Gallium3D driver while the newer GPUs (R600+; the Radeon HD 2000/3000/4000/5000/6000 series) all run off the "R600g" driver. The R600g driver is much newer than the R300g driver and as such it's not as mature and well-developed as the R300g driver. There's also been classic Mesa support around longer for the R300-R500 chipsets, documentation has been around longer, the hardware is a bit simpler, etc. Plus, let's not forget that when AMD's pivotal open-source strategy came about, the Radeon HD 2000 (R600) series was the new hardware at the time and so AMD had to play catch-up to bring their previous generations of ASICs up to par.

Eventually the R600g driver will be on the same level as the R300g driver, but it's not there yet. The R600g driver is certainly moving along at a much faster pace than the R300g driver since the R300g driver began as a Google Summer of Code project and was the first Gallium3D driver work for many of the open-source ATI developers. In fact, it was not even a year ago that the R600g driver hit the glxgears milestone; it was in July when an R600g strategy was plotted. It's been just months since this driver went from being non-functional to now being faster than the R600 classic driver and in many areas also more advanced and will soon hopefully be the default R600+ driver in Mesa.

Some of the R300g features can be easily ported to the R600g driver, such as the recent work to unify the vertex buffer manager, while other work requires some re-engineering and also further improvements to the R600+ support within the Radeon DRM module. Among the features still not implemented in R600g that should yield performance boost are fast clears, 2D tiling, and Hyper-Z, as noted by AMD's Alex Deucher in our forum thread.

In fact, just over the weekend Marek Olšák, one of the leading open-source ATI community developers, proposed a patch to optimize the command submission state checking. What does this patch apply against right now? The R100 through R500 ASICs. This CS state checking optimization patch is designed to drop the time spent in the kernel and result in performance improvements by only checking color-buffer/z-buffer/texture states when they are changed. Marek ends with "r600 might need something like this as well." But for now, the R500 and earlier owners can enjoy the faster support once this patch lands.

The R300g driver is closing in on the Catalyst driver performance while the R600g driver is making progress. There will not, however, be a parity with the closed-source driver due to the lack of S3TC texture compression and other features that can't be implemented in the open-source drivers due to patents and other licensing restrictions.

Going forward with new generations of ATI graphics processors there will hopefully be less of a lag time in initially supporting the hardware and also bringing its performance up to speed. AMD was on target with Fusion Ontario open-source support and slightly behind with the Radeon HD 6000 series, but also with the next-generation GPUs they will focus upon just bringing up the 3D support in the Gallium3D driver as opposed to also bringing up the support in the classic Mesa driver. But for those most concerned about prompt support and fast performance, there is always the proprietary Catalyst driver.

This performance abnormality for older GPUs vs. newer GPUs isn't limited to just the ATI Gallium3D drivers, but it's a similar problem on the Nouveau side too. However, with the Nouveau driver, since it's developed by reverse-engineering within the community and without the support of NVIDIA Corp, the development situation is a bit more challenging. The level of support and capabilities is limited to the hardware that the developers have access to and that they are trying to bring up support for all of NVIDIA graphics processors at virtually the same time. Here's some more Nouveau Gallium3D benchmarks from last month.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. MSI X99S SLI PLUS On Linux
  2. NVIDIA GeForce GTX 970 Offers Great Linux Performance
  3. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  4. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
Latest Linux Articles
  1. Open-Source Radeon 2D Performance Is Better With Ubuntu 14.10
  2. RunAbove: A POWER8 Compute Cloud With Offerings Up To 176 Threads
  3. 6-Way Ubuntu 14.10 Linux Desktop Benchmarks
  4. Ubuntu 14.10 XMir System Compositor Benchmarks
Latest Linux News
  1. Ubuntu 14.04 In The Power8 Cloud From RunAbove
  2. KDE With Theoretical Client-Side Decorations, Windows 10 Influence
  3. Sandusky Lee: Great Cabinets For Storing All Your Computer Gear
  4. Fedora 21 Beta & Final Release Slip Further
  5. Mesa 10.3.2 Has A Couple Bug-Fixes
  6. RadeonSI/R600g HyperZ Support Gets Turned Back On
  7. openSUSE Factory & Tumbleweed Are Merging
  8. More Fedora Delays: Fedora 21 Beta Slips
  9. Mono Brings C# To The Unreal Engine 4
  10. Coreboot Now Has Support For Intel Broadwell Hardware
Latest Forum Discussions
  1. Use Ubuntu MATE 14.10 Make it an official distro.
  2. HOPE: The Ease Of Python With The Speed Of C++
  3. Users/Developers Threatening Fork Of Debian GNU/Linux
  4. Debian Is Back To Discussing Init Systems, Freedom of Choice
  5. AMD Radeon VDPAU Video Performance With Gallium3D
  6. Updated and Optimized Ubuntu Free Graphics Drivers
  7. Ubuntu 16.04 Might Be The Distribution's Last 32-Bit Release
  8. Linux hacker compares Solaris kernel code: