LOSTCIRCUITS

Evolving AGP Standards and the Lack of Performance Scaling

One issue that has been a constant by-line of all improvements of the various AGP iterations is the lack of performance benefits along the evolutionary path. That is, the transition from AGP2X to AGP4X failed to generate any increment in performance, likewise, AGP8X incentives are marginal at best. A great portion of this paradox has to be viewed in the context of what AGP was supposed to become and its possible role in UMA and the vision of Intel, targeting a single processor system powered solely by the CPU as power house. While this strategy has proven successful for most peripherals - a case in point is the consumer desktop soft-audio – it certainly has failed in the graphics sector as probably everybody is aware.

Back to the performance issues mentioned. Most of the lack of performance increase can be attributed to the choice of benchmarks. In addition, most of the expectations that made us look at the wrong benchmarks and, by extension, caused the general disappointment were, explicitly or implicitly - however predictably - caused by marketing. In retrospect, it appears as if most of it was done despite knowing better.

A case in point is the claim about the bandwidth dependence of textures. Admittedly, AGP1X no longer suffices, however, by use of compression algorithms like that developed by S3 (S3TC) and its 6:1 lossless compression ratio, even an AGP2X interface can transfer as much as 1.5GBs of texture data. For any current gaming application this will more than suffice.

There are two exceptions, though. Complex 3D CAD designs rely on the precision of geometry setup which precludes the use of compression. This is where we originally found the greatest benefits of increased interface speed. The second exception entails mostly anything related to real time streaming video processing since non-recurrent data cannot be cached in the local video memory.

System Design Limitations

The Accelerated Graphics Port is essentially a logical PCI device with the benefit of having a dedicated bus for itself. In other words, where other PCI devices share one bus, AGP by definition occupy their own physical bus. By extension, the one bus – one device rule entails that only one AGP interface can exist per bus, at least, this was true for AGP revisions up to 2.0. AGP3.0 specifications allow for the addition of a second AGP device, at least in theory. However, in practice, there has not been any presence of designs that made use of the extended feature set other than allowing the AGP slot next to an integrated graphics device. Suffice it to say that without a suitable platform, there was no incentive for the development of any AGP-based scan line interleaving à la Voodoo2, the technology and rights to which were inherited by nVidia with the take-over of the shambles of 3dfx. As we know, SLI in a modernized version may become a major factor in PCIe.

PCIe, the new kid on the block

PCI Express and its ins and outs have been covered in a more or less competent way all over the web and there is no reason to go into gory detail again. Suffice it to say that the “graphics adapter” PCI Express interface within the gamut of PCIe configuration possibilities uses a 16x parallelism of high speed serial lanes with its packetizing of commands addresses and data (CAD) transfers. As a result, there is no longer a need for either pipelining of data with addresses and commands, nor is an increased pinout needed for sideband addressing – everything runs through the same lanes and is decoded at either end of the Databahn. The graphics interface is only one port within this system of abundant bandwidth and, therefore, even a multiplicity of graphics adapters appears a rather trivial task to implement.

Bridge vs. Native PCIe Support

Adaptation of existing designs to support PCIe vs so-called native (designed from scratch) solutions have spawned a number of somewhat academic discussions about the pros and cons, or whether ATI does have a bit of a headstart here. That is, nVidia is still using a bridge solution to interface with the system. Keep in mind, though, what we mentioned earlier. That is, the different AGP standards failed to reveal much difference in consumer applications and we expect the difference between the native and the bridge design to be even closer and approaching the border of measurability. On the other hand, there is some evidence that bridge solutions are not as tolerant with respect to system overclocking as native solutions. Enough preamble, time to move on and look at the selection of hardware on today’s menu.

Next Page:    => Tech Specs at one Glance =>