AGP 8× - Why do we need it, and what does it do?

In the past, AGP bandwidth has been scaled up at regular intervals. AGP1X and 2X were introduced simultaneously and AGP4X was introduced 2 years later. Now, AGP8X is recognized as the natural progression beyond AGP4X. It is expected to satisfy the bandwidth demands on the graphics interface for at least 2 generations.

The need to increase bandwidth beyond AGP4X is based on the following trends:

- Workload content and real-time performance expectations are continuing to scale at a significant rate every year. These are measured by the complexity of the scene being visualized and the real-time scene changes and interactivity that is expected.

- The capabilities of graphics subsystems to render complex images are scaling at a tremendous rate due to significant architectural and technological improvements.

- The host platform’s capabilities to support the graphics subsystem and workload requirements are also continually increasing. These capabilities include processor speeds, system memory capacity and bandwidth, as well as multiprocessing.

AGP8X is an evolution of AGP. This evolutionary interface maintains the same connector and interface signals as AGP. However, since the electrical signaling and clock rates are significantly different between AGP and AGP8X, compatibility at the platform level is achieved using a “Universal” motherboard. A Universal motherboard is one that supports both AGP and AGP8X signaling. What follows is a list of AGP/AGP8× compatibility features.

This means that much of the older AGP 4× technology can be efficiently leveraged to create motherboards and cards for the AGP8× specification. Speed alone is not the only improvement to be found in AGP8×. What follows is a list of improvements and how the will impact computer users.

Isochronous Operation

What Intel Says: Traditional AGP devices can demand up to the maximum bandwidth available over the AGP ports. However, the AGP system does not guarantee to deliver the requested bandwidth, nor does it guarantee transfers will take place within some clearly specified request/transfer latency time. This “best efforts” arrangement works reasonably well for applications requiring low average latency and high average throughput, as long as the device can tolerate an arbitrarily long delay now and then without losing data. In contrast, streaming applications require the ability to transfer data on a periodic schedule and do so continuously. Further, low cost designs must minimize the amount of request and data buffering. Isochronous data transfer services provide a contract, established during application startup, that indicates precisely when data transfers may be requested and sets bounds on when the corresponding data transfers will occur. This greatly alleviates the problem of arbitrarily long delays and places a strict bound on the amount of buffering needed to avoid data loss. This is done by the system guaranteeing to process a specified number (N) of read or write transactions of a specified size (Y) during each isochronous time period (T). An AGP8X device can divide this bandwidth between read and write traffic as appropriate. Further, the system transfers isochronous data over the AGP8X Port within a specified latency (L). Given these parameters, the system guarantees to deliver isochronous bandwidth equal to: BW=NY/T

To simplify synchronization with the processor, isochronous write transactions are guaranteed to become visible to the rest of the system without the need for an explicit “flush” operation. Both consumer desktop and professional workstation systems benefit from isochronous support; however, specific platform types may differ as to the number of transactions per period, transaction size and transaction latency.

In Plain English: AGP modes, up to 4× have worked reasonably well because they were mainly directed towards games, where you could afford to wait a few seconds while things were loaded across the AGP port before starting a particular part of the game. But, demands on computers are changing, and now streaming data is becoming more and more important. This kind of information doesn't work so well with AGP simply because the small delays in AGP operation cause it to slow and stutter. AGP8× proposes to change this by allowing each application to tell AGP how it wants the data handled so as to minimize any poor performance impact that a single "general" solution might cause.

Our Opinion: Good Feature | No Change | Bad Feature

Flow Control Change

What Intel Says: Since isochronous and asynchronous transactions may be concurrently processed on the AGP8X interface, it is necessary to ensure that a throttled (stalled) asynchronous transaction does not cause the isochronous latency specification to be violated. Based on this, the following points emerge:

• Block-level flow control will stall the interface. Buffer-Full flow control only stalls a new asynchronous data transfer from starting.
• AGP8X “Reads and Writes” cannot be flow-controlled at the block-level since the maximum transaction size is 64 bytes.
• AGP8X Fast Writes can be flow-controlled at the block-level since there is no limit to the size of the transaction.

Two- (2) modifications made to the asynchronous transaction flow control are required to ensure proper isochronous operation. These modifications are:

Isochronous Transactions and Buffer-Full Flow Control
Data transfers for isochronous read or write transaction will ignore buffer-full flow control applied using RBF and WBF. The core-logic that initiates these transfers may pass a stalled asynchronous data transfer with an isochronous data transfer. Simply put, the core-logic ignores RBF and WBF when it initiates an isochronous data transfer.

AGP8X Fast Write Flow Control
For AGP “Fast Writes”, the maximum number of wait states introduced during each block-level stall was not specified. In AGP8X, the maximum number of Wait states is limited to two- (2) common clock cycles. In other words, the AGP8X Master must not suppress TRDY for more than two- (2) cycles including the throttle point cycle. If the AGP8X Master needs additional time to receive the Fast Write data, it must use the Fast Write termination schemes that are defined in the AGP interface specification. The AGP8X Master is allowed to disconnect a stalled transaction with or without accepting any data. The target is required to resume where the disconnected transaction left off.

In Plain English: Basically, this change was required to properly support the Isochronous Operation listed above. The old way that flow contol worked was designed to operate with the greater latency allowances that AGP 4× and below allowed - so, its only natural that this would need to be changed as well.

Our Opinion: Good Feature | No Change | Bad Feature

Updated Synchronization Models

What Intel Says: Synchronization models used for interchange of data between different agents in the platform. The basic reason for synchronization is to guarantee that when one agent performs a data movement in the platform for consumption by a second agent, the second agent receives the intended data. There are several instances of this that are updated as presented in the following list:

• Processor writes data to Main Memory and AGP8X device reads this data.
• AGP8X device writes data to Main Memory and the processor reads this data.
• A 3 rd agent (say another PCI device) writes to Main Memory and AGP8X device reads this data.
• AGP8X device writes to the Main Memory and a 3 rd agent reads this data.
• One- (1) AGP8X device behind a Fan-out Bridge writes to the Main Memory, while the other AGP8X devices behind the same bridge read it.

In Plain English: Finally! The most important item here is the last one - this is a clear indication that multiple AGP adapters will be permitted under the new AGP8× specification.

Our Opinion: Good Feature | No Change | Bad Feature

In Conclusion

If you made it this far, I'd like to thank you. To this point the going has been pretty heavy. The basis of AGP8× is pretty straightforward for what it will do for computers and computer users. It will allow AGP to move into more mainstream applications that require different tolerances than just games. It will allow more than one AGP card to be used in the system at once, and it brings the speed of AGP up to levels similar to the memory bandwidth speeds that we will be seeing as DDR based motherboards become more common.

The only word of warning that I would issue is this: Every time a new implementation of AGP has been introduced, it has taken at least a year for the non-Intel chipset makers to get their implementations to become stable. With the huge increase in complexity that AGP8× represents, expect this pattern to continue.