Universal Accelerated Graphics Port (UAGP)

Updated: March 19, 2004

On This Page

  Introduction
  AGP 3.5 Features
  Windows Logo Program Requirements
  Glossary
  References

The information in this white paper is for hardware vendors who have produced or who are planning to produce chipsets with Accelerated Graphics Port (AGP) 3.5 (for Intel Processors) or AGP 3.0-capable devices (for AMD64 processors). The paper explains the benefits of using the universal AGP drivers written by Microsoft. It also provides information about how to find tools and complete the test procedures and how to find the documentation that explains the qualifying process for the Microsoft Windows Logo Program for devices and systems with the Microsoft universal drivers for AGP 3.5.

Introduction

The Accelerated Graphics Port (AGP) interface provides a fast connection between the core logic and the graphics controller without using PCI bus bandwidth. The AGP interface also defines a physical memory to virtual memory mapping mechanism called a Graphics Address Remapping Table (GART). The AGP specification has undergone several revisions since the introduction of AGPv1.0. AGP 3.0, the previous major revision, incorporated the updated protocol, signaling, electrical, mechanicals, and PCI Configuration space compatible register support. The most current revision is AGP 3.5; it incorporates “Appendix Specification Register Support,” which adds standardized isochronous control, GART layout and access, aperture control, and multiple graphics card support through multiple AGP buses.

Although the AGP specification has always defined a standard programming model, the model has not been complete enough to allow the use of a standard AGP driver. As a result, individual chipset vendors have defined different page table entry (PTE) formats for the GART, choosing radically different register layouts for their AGP target (motherboard) devices, as well as writing their own AGP drivers. Chipsets with AGP versions up to and including AGP 3.0 must have vendor-specific drivers. With the additions of and changes to registers in each revision of the AGP interface specification; inconsistencies frequently appear in each vendor’s interpretation of the AGP specification and in their AGP drivers. AGP 3.5 allows standardization of a single AGP driver for all AGP 3.5-compliant chipsets.

The AGP interface specification can be open to interpretation in particular instances. Driver developers can misinterpret the AGP specification during their implementation without realizing it. The addition and removal of features in the AGP revisions can cause illegal memory accesses when the installed drivers have different AGP capability versions from the chipsets. In addition, the proliferation of chipset and graphic card combinations means that there is no standardized method of testing to ensure quality of performance and overall system compatibility. A given combination of AGP master (graphics card) and AGP target can be thoroughly verified only by soldering an expensive logic analyzer to the underside of a motherboard and analyzing large amounts of data for error. With inconsistent testing, the result is a poor user experience and unpredictable behavior.

Microsoft developers investigated the problems of invalid GART entries as a result of customer complaints about AGP-related poor system stability, such as memory corruption. Many industry members are confused by AGP capability versioning. With the release of upcoming AGP 3.5-capable hardware, Microsoft is initiating a standardized way of programming and manipulating the AGP aperture. To deliver a quality user experience, a universal standard for the AGP driver UAGP35 should be adopted by all chipset vendors with AGP 3.5-capable hardware.

 Top of page

AGP 3.5 Features

The Appendix Specification Register Support that is required for AGP 3.5 (as specified in Appendix B, sections 5.8 and 5.9 of the AGP V3.0 Interface Specification, Revision 1) is an additional set of registers that allows programming for features such as isochronous transactions and that also allows for programming of the GART and AGP aperture.

Appendix Register Support for AGP 3.5:

• Enhanced registers in the master (core-logic) and PCI configuration space for the target AGP device (such as a graphics card), upgraded from the AGP 3.0 Core Specification Register Support:

  • PCISTS: PCI Status Register

  • CAPPTR: Capabilities Pointer

  • NCAPID: AGP Identifier Register

  • AGPSTAT: AGP Status Register

  • AGPCMD: AGP Command Register

  • NISTAT: AGP Isochronous Status Register (Optional)

  • NICMD: AGP Isochronous Command Register (Optional)

• New required registers in the target PCI configuration space, in addition to those of AGP 3.0 Core Specification Register Support (as specified in the AGP 3.0 Interface Specification):

  • APBASELO: Specify the low 32 bits of the physical address for the base of the aperture.

  • APBASEHI: Specify the high 32 bits of the physical address for the base of the aperture (used only if the capability register of the target says that it can address more than 4 GB).

  • AGPCTRL: AGP control register for configuring some bus-specific capabilities.

  • APSIZE: Specify the size of the aperture.

  • NEPG: Specify the size of the page used in the aperture.

  • GARTLO: Specify the low 32 bits of the physical address for the GART.

  • GARTHI: Specify the high 32 bits of the physical address for the GART.

To provide a minimum quality bar for AGP 3.5 drivers and systems with AGP 3.5 capability, Microsoft has developed a standard set of device and system tests, plus an AGP 3.5 driver for all chipsets.

The UAGP35 and GAGP30KX drivers conform to the AGP specification, eliminating common errors seen in earlier AGP drivers. The new driver requirements for AGP 3.0 and later are incorporated into UAGP35 and GAGP30KX, as shown in the following list.

Standard properties for Microsoft AGP 3.5 driver:

• The Graphics Processing Unit (GPU) should generate accesses in the AGP aperture only by using AGP transactions.

• The GPU should not do AGP transactions outside the AGP aperture range.

• The GART (AGP) driver is below the video port on the driver stack.

• The GART (AGP) driver exposes an interface that the video port uses to allocate AGP memory.

• The video port gets the interface by building an IRP_MJ_PNP/IRP_MN_QUERY_INTERFACE IRP that contains GUID_AGP_BUS_INTERFACE_STANDARD.

• The Interface that is provided by the GART driver performs the following services:

  • AgpReserveMemory(): Reserves a range in the aperture.

  • AgpReleaseMemory(): Releases a previous reservation in the aperture.

  • AgpCommitMemory(): Commits a portion of a range in the GART aperture that was previously reserved.

  • AgpFreeMemory(): Frees a portion of a range in the AGP aperture that was previously committed, putting it back in an uncommitted state.

  • AgpSetRate(): Allows a video driver to atomically change the current rate at which the AGP bus is transferring data.

• On a commit, the GART driver uses MmAllocatePagesForMDL to allocate physical pages in the AGP aperture and then programs them into the GART. The GPU now will see one contiguous block of memory.

• The GART driver only allocates physical memory and sets up the GART. Creating CPU mapping for that memory is the responsibility of the video port.

• The AGP capability version must never change. An AGPv3 capability target device is also compatible with an AGPv2 master, so there is no need for the target device to adjust its capability from version 3 to version 2 to match a master device’s capability. The Microsoft universal AGP driver can only assume a standard target register layout when its capability version is 3.5 for UAGP35 or 3.0 for GAGP30KX.

• For GAGP30KX compatibility, “shadow” registers must exist in the target device for the Aperture Base Address (Low/High) and Aperture Size. These registers should adhere to the Appendix Register section of the AGP 3.0 specification, specifically sections 5.9.1, 5.9.2, and 5.9.4. The term “shadow” is used to describe a register that behaves according to the specification, although it controls no real hardware. In this case, the real aperture registers reside in the x86-64 CPU, so that the GAGP30KX driver doesn’t have to try to decipher the aperture settings from possibly multiple x86-64 CPUs and to provide a direct link of communication from the hardware and BIOS to the GART driver. If the GAGP30KX driver moves or resizes the graphics aperture, it will update the Aperture Base Address shadow register (or registers), but nothing should rely on this behavior. A platform that adheres to this set of conditions is said to be “AMD-8151-compatible.” (AMD-8151was the first AGP target device for AMD64 platforms.)

• If an AGP target device resides in a host bridge (that is, system-to-PCI bridge), the CAP_ID must be 2; but if the target device resides in a PCI-to-PCI bridge, its CAP_ID must be 0xE.

Microsoft recommends that the UAGP35 driver be used on both 32-bit and 64-bit Windows platforms that are AGP 3.5 capable. This driver is installed during setup through machine.inf. Beginning with the Microsoft Windows Server™ 2003 (32-bit) operating system, when the Windows operating system is installed on any AGP 3.5-compatible machines, the UAGP35 driver is incorporated in the platform. The UAGP35 driver is supported in the Windows Server 2003 Driver Development Kit (DDK) and will be shipped with Microsoft Windows XP Service Pack 2 (SP 2), as well as with subsequent Windows releases. UAGP35 is a standard Windows driver model (WDM) upper filter driver provided by Microsoft. It allows vendors to update the PnP PCI Device IDs for their hardware.

For UAGP35 compatibility and AGP 3.5 compliance, all the AGP target registers (including the Aperture Base Address Registers) must reside in a single PCI bus, device, or function. AMD Opteron and AMD Athlon 64-bit processor-based machines cannot provide standardized GART and aperture control because the memory controller and processor are integrated. Therefore, they are not AGP 3.5-compatible as defined in the current specification. However, systems adhering to the AMD64 AGP architecture (AMD 8151-compatible) have the AGP 3.0 capability. A separate standard driver, GAGP30KX is written for those machines. The GAGP30KX driver is incorporated in Windows 2003 Server (32-bit and 64-bit) Service Pack 1 (SP 1). It will also ship with Windows XP SP 2 and subsequent Windows releases. The GAGP30KX can be extended using the Microsoft Windows Longhorn Development Kit (LDK) beta releases. UAGP35 and GAGP30KX will also eventually be installed through Windows Update.

Vendors with AGP chipsets should adapt the new drivers according to Table 1.

Table 1. AGP Driver Adaptability and Availability

Microsoft recommends that current and upcoming AGP 3.5 chipsets use the UAGP35 driver in order to gain the benefits provided by the universal driver. In addition, Microsoft recommends all current AGP 3.0 and upcoming chipsets for AMD64 processors use the GAGP30KX driver, again to gain the benefits provided by the universal driver. Windows hardware Quality Labs (WHQL) has no plans to establish a cutoff date for blocking vendors who develop AGP filter drivers from receiving the “Designed for Windows” logo on either current or new AGP chipset hardware.

Vendors planning to produce hardware with more than AGP 3.0 capability and a unique architecture that are incompatible with the UAGP35 or GAGP30KX drivers should work with Microsoft in the development of their drivers to ensure that the driver quality is met.

To facilitate the use of the Universal AGP driver, Microsoft will include the source code for UAGP35 and GAGP30KX in the LDK.  From there, vendors can build UAGP35 and GAGP30KX drivers (and must rename them to an IHV specific name), and submit this driver package to WHQL along with the appropriate INF file containing the device IDs and versioning information of the vendor's AGP3.5 capable chipsets and the relevant hardware.

These are the steps for preinstalling signed copies of the UAGP35 and GAGP30KX drivers:

1. Submit to WHQL the chipset, motherboard, or system hardware and the driver package including an INF file with the chipset’s device ID and versioning information.

2. WHQL will run the tests on vendor’s hardware and driver following the same test procedures the vendor should be following prior to submitting the hardware and driver to WHQL.

3. WHQL will verify that the tests are passed and send the signed INF file back to the vendor bundled with a copy of the signed driver.

After obtaining the signed INF and driver package from WHQL, the vendor may redistribute this package and use it to load a signed version of the UAGP35 or GAGP30KX driver for the vendor's AGP chipset.

 Top of page

Windows Logo Program Requirements

The WHQL Display Test team is responsible for ensuring that AGP Chipset and filter drivers meet the “Designed for Windows” logo program requirements. In order to ensure that AGP chipsets and filter drivers meet all required specifications outlined by Chapter 8: AGP Test Specifications in the upcoming HCT12.0 WHQL Test Specification document, Microsoft will  create a new test procedure document to follow to ensure that vendor hardware meets these specifications.  This test procedure document will outline the required testing WHQL will perform on hardware submissions so that vendors are able to run the same testing prior to submitting the hardware.  Ensuring that all tests pass prior to making the submission will be important in ensuring the submission proceeds smoothly.

For advance copies and/or questions about the test procedures please contact DCTHelp@Microsoft.com.  

 Top of page

Glossary

GART

Graphics Address Remapping Table: A translation mechanism that makes discontinuous memory appear as contiguous memory by translating virtual addresses into physical addresses in main memory through a remapping table. The aperture specifically refers to the block of contiguous memory space that contains the GART.

DCT

Display Compatibility Test: WHQL test kit for validating display adapters/chipsets that meet the “Designed for Windows” logo requirements.

HCT

Hardware Compatibility Test:  WHQL test kit for validating hardware and device drivers that are compatible with Windows operating system features in order to meet "Designed for Windows" logo requirements. 

 Top of page

References

AGP 3.0 Standard Interface Specification

http://download.intel.com/support/motherboards/desktop/sb/agp30.pdf

AGP 3.0 from the Intel Corporation website

Device Testing: Display Adapter/Chipset Testing

http://msdn.microsoft.com/en-us/library/bb892502.aspx

Explains specific testing steps for vendors that want to use the “Designed for Windows” logo for new display adapter/chipset devices.

Windows Logo Program for Hardware, including the Windows Logo Program System and Device Requirements

http://msdn.microsoft.com/en-us/windows/hardware/gg463010.aspx

Describes the scope and purpose of the Microsoft Windows Logo Program and explains how to obtain the “Designed for Windows” logo for server, desktop, and mobile systems and components that run with Windows operating systems.

Microsoft Windows Update

http://windowsupdate.microsoft.com

Microsoft contact for AGP issues

basevid@microsoft.com

 Top of page