Because AGP is an evolving technology and both software and hardware developers are still experimenting with different optimizations for it, it's hard to come up with a hard and fast rule about whether to overclock the AGP bus or leave it at standard clockspeed so that the SBA can function.

For 3D applications that make use of lots of small textures (total texture size not withstanding), SBA makes a lot of sense. The majority of the latencies incurred by the large number of AGP requests and commands will be effectively masked by channeling them through the dedicated SBA lines. This gives the card an advantage over the AGP bus without SBA even though it is overclocked. That's because the latency of each and every AGP request or command down the SBA-less AGP bus will NOT be masked; and they will cause quite a degradation in effective throughput. This is especially true if the AGP pipeline of the card is deep and the number of AGP requests is high.

For 3D applications that make use of large textures, however, the overclocked AGP bus will prove to be the better solution. That's because the large textures will be able to cross the bus significantly faster. And although the latency of each AGP request won't be masked, it will be reduced and the effect minimized by the fact that there are fewer AGP requests per MB of textures transferred. This is especially true if the AGP pipeline is short and the number of textures used is low.

However, looking at the trend adopted by both software and hardware manufacturers, it's doubtful that the higher bandwidth of the overclocked AGP bus will be utilized much. AGP has always had a bad reputation. For one thing, its bandwidth is miserable compared to what onboard RAM on most cards these days are capable of. So both software and hardware developers will always be developing ways on overcoming that shortfall. Naturally, the theme would be to reduce reliance on the AGP bus. How would they do that?

Well, graphics card manufacturers are now pushing out cards with 16-32MB of onboard RAM. 64MB of onboard RAM may even be appearing soon. The reason why they are adding so much onboard RAM is because the onboard RAM will be able to accommodate most, if not all, of the textures used by the 3D application and thus minimize the effect of the slow AGP bus.

Still, RAM is not cheap and to ensure certain 3D applications (read : games) would be able to run at a usable speed, software developers try to keep the texture size low by using small textures. But just in case the need for large textures arises, hardware developers have started adding texture compression support to their hardware so that if the software developers need to use large textures, they will be able to do so without incurring crippling degradations in texture rendering speed. With texture compression, large textures will effectively be reduced in size so that they can be more easily and quickly transferred across the AGP bus.

Because all these methods aim to reduce the effect of the AGP bus' low bandwidth on the graphics controller's performance, it goes to reason that any increase in the AGP bus' bandwidth, courtesy of overclocking, will have minimal effect on the performance of the graphics controller. That's why it's doubtful that overclocking the AGP bus will have as much effect as improving the efficiency of the AGP bus by utilizing the SBA. To sum it all up, if your card supports SBA, enable it for better AGP performance but if it doesn't come with the SBA, then overclock the AGP bus for a slight boost in performance.

 

The grayed out text in the page 1 was written by Frank Hady of Intel's Platform Architecture Labs and is copyright of Intel.