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 Benchmarking Platform
Phoromatic Test Orchestration

How Old ATI GPUs Can Be Faster On Open Drivers


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

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 Articles & Reviews
  1. Turning A Basement Into A Big Linux Server Room
  2. NVIDIA's $1000+ GeForce GTX TITAN X Delivers Maximum Linux Performance
  3. OS X 10.10 vs. Ubuntu 15.04 vs. Fedora 21 Tests: Linux Sweeps The Board
  4. The New Place Where Linux Code Is Constantly Being Benchmarked
  5. 18-GPU NVIDIA/AMD Linux Comparison Of BioShock: Infinite
  6. Phoronix Test Suite 5.6 Adds New Phoromatic Enterprise Benchmarking Features
Latest Linux News
  1. How Far Valve Has Come: Three Years Ago They Needed OpenGL Linux Help
  2. Audacity 2.1 Improves Noise Reduction, Adds Real-Time Effects Preview
  3. Linux 4.0-rc6 Kernel Released
  4. Automatically Managing The Linux Benchmarks Firing Constantly
  5. The Big Features Of The Linux 4.0 Kernel
  6. Mesa's Android Support Is Currently In Bad Shape
  7. Wayland's Weston Terminal Can Now Be Minimized
  8. Phoronix - Working Towards Faster Page Loads
  9. Improved OpenCL Support For Blender's Cycles Renderer
  10. Mesa 10.5.2 Packs In A Handful Of Fixes
Most Viewed News This Week
  1. Introducing The Library Operating System For Linux
  2. Allwinner Continues Jerking Around The Open-Source Community
  3. Open-Source Driver Fans Will Love NVIDIA's New OpenGL Demo
  4. Systemd Change Allows For Stateless Systems With Tmpfs
  5. GNOME 3.16 Released: It's Their Best Release Yet
  6. GNOME Shell & Mutter 3.16.0 Released
  7. GNU Nano 2.4.0 Brings Complete Undo System, Linter Support & More
  8. Red Hat Is Rolling Out A VirtIO DRM/KMS GPU Driver