LOSTCIRCUITS

Summary

A few weeks ago, we forayed into the realm of AGP8X to show the differences between the older AGP 2.0 standard and its replacement going by the suffix 3.0. Numerous changes in the protocol along with the move to octal data rate were supposed to yield some performance improvement, alas, as we showed, at least in gaming applications we were unable to eve document a performance increase from AGP2X to AGP4X.

At the same time, we did notice quite some differences in professional graphics applications running under OpenGL. It appeared, though as if we were running into some limitations of the graphics adapter in that the ASUS V9280 was seemingly unable to capitalize more on the increased bandwidth provided by AGP8X. Our rationale was that a more powerful adapter might be more suitable to show off the benefits of 2GB/sec AGP bandwidth and so we grabbed an nVidia Quadro4 980 XGL. It is hard to imagine missing the target of our expectations by a wider margin but ...... on second thought, there are lessons to be learned from our results...

Regardless of all technical elegance behind the latest standard and its pointing to the future, it is hard to even see any benefit of going with AGP 8X at the present time. We were looking into this phenomenon recently and came to the conclusion that especially in Direct3D gaming applications, there is hardly any advantage to be noticed beyond the use of AGP 2X. Somewhat different is the situation in professional OpenGL benchmarks where we could show some significant progress from AGP 2X to AGP 4X. On the other hand, when comparing apples to apples, that is AGP 4X 2.0 vs. 3.0 using identical hardware and forcing protocol changes by means of enabling / disabling the AGP3.0 ID pins on the graphics card was practically immeasurable. That is, with the exception of professional benchmarks in ViewPERF 7.0 there were no differences in frame rates, regardless of AGP 4X (2.0) AGP 4X (3.0) or AGP 8X (3.0).

nVidia Quadro 4 built on the GeForce4 GPU series.

In D3D applications, it appears rather clear what is going on, texture transfers from main memory to the GPU are by no means the limitation in performance and there are several reasons for that. First, textures are preloaded into the on-board memory or texture buffer as a portion of the local frame buffer from where they are called on demand. Second, compression algorithms of 6 x and more increase the actual data transfer through the AGP interface. That means that, e.g. at 6 x texture compression, the AGP 4X interface is capable of communicating 6 GB of data per second and there is hardly any application at present that would be able to even use this amount of texture data. Third, the GPU performance will become the bottleneck rather than the fill rate.

To go a bit more into detail and put it into perspective with the overall system architecture, the system memory will be able to deliver 2.1, 2.7, 3.2 or 4.2 GB/sec bandwidth, depending on chipset and memory bus frequency and width. Keep in mind that those numbers refer to the physical number of bits / Bytes transferred across the memory bus and do not take compression algorithms into account. In other words, the numbers are not capping the texture transfer but have to be multiplied with the compression factor for the total texture bandwidth of the system memory to AGP interface.

Next Page:    => Textures and Triangles =>