How Old ATI GPUs Can Be Faster On Open Drivers
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.
Latest Linux Hardware Reviews
Latest Linux Articles
Latest Linux News
Latest Forum Discussions