Local Memory Interface

There was plenty of confusion over the type of memory interface Radeon 8500 supported. Initial chip diagrams represented the bus as a dual channel 64bit DDR data bus, giving the impression of a similar crossbar system to GeForce3/4 (albeit with half the paths). However later diagrams missed this out and listed it as a straight 128bit DDR data bus. There is no such confusion with Radeon 9700, though, as ATI are clearly stating that 9700 does indeed utilise a 'crossbar' memory bus system.

As we can see from the diagram there is a clear '4 way crossbar' system employed by Radeon 9700. However, like Matrox's Parhelia and 3Dlabs Wildcat VP before it, Radeon 9700 employs a full 256bit DDR data bus, allowing for twice the bandwidth of previous 128bit DDR memory interfaces. As the 4-way crossbar is operating on a 256bit bus this means that it is divided into 64bit chunks.

As mentioned above, the memory interface is DDR capable and the shipping memory speed of Radeon 9700 PRO at 310MHz (620MHz effective) allows for just shy of 20 Gigabytes of bandwidth (19.84). ATi also state that the memory interface is capable of supporting DDR-II memory types, and they expect to introduce DDR-II variants when it's commercially viable - early next year ATi believe.

It would seem that ATI are not set to bring a 'Virtualised' memory system similar to that employed by 3Dlabs Wildcat VP P10 chip. In gaming environments it's likely that texture data is going to an area that would make use of a virtual memory system and ATI feels that with 128MB of onboard memory, most of the time the textures will fit into that space. If, however, there is insufficient space within the local memory the textures that do not fit will be placed in the system memory via the AGP aperture; should a pixel being rendered require information from a texture residing in system memory then only the specific texel information needed for that pixel need be addressed, and therefore the entire texture does not need to be loaded, or swapped, across the AGP bus.

AGP Interface

For the AGP interface ATI have decided to fully implement AGP8X in the Radeon 9700. The AGP8X specification retains the 66Mhz AGP bus clocking, though it is now able to "strobe" the signals at 8 times the frequency of the clock; for AGP8X this allows a potential maximum data transfer rate of 2GB/sec, double that of AGP4X.

Traditionally AGP bandwidth has been labelled as the bottleneck for geometry complexity to the graphics card, though, paradoxically, now that we have even higher AGP rates this is becoming less of an issue with modern 3D chips. With the introduction of ever more programmable Vertex Shaders, more of the geometry can be controlled directly by the 3D card. An example of this would be with character (model) blending. If a 3D chip does not support such blending then it needs to be controlled by the CPU and so the geometry needs to be sent from the CPU to the 3D card via the AGP bus; hence if the bus is slow the operation is slow. However, with a Vertex Shader capable of such blends the geometry information for the model need only be sent once, at load time, and the 3D chip is able to handle all subsequent blends locally, thus reducing the data passed across the AGP bus as the application is rendering.

One area that does remain important is for transference of texture data should the available local ram not be sufficient to hold all the texture data for an application.. As explained earlier, in this case the texture will be moved across into system RAM via the AGP aperture, so when sampling of these textures is required as high as possible AGP bandwidth is desirable.

Arguably, in this case, texturing may also follow a similar path to geometry. With the advent from greater Pixel Shader functionality, procedural textures become more of a reality so that rather than storing a high resolution, or even 3D texture to represent something like wood grain, this could be generated procedurally via the pixel shader and would require far less space to store (as it is just a mathematical model) and hence cut down the requirements for texture space.

However, suffice it to say that for present games increased AGP bandwidth will be useful for passing geometry and texture information from the host CPU/bus to the graphics card, thus ensuring that any bottlenecks that may be imposed by the AGP bus are minimised.