Graphics address remapping table

Lore & Background

The GART is used as a means of data exchange between main memory and video memory, through which buffers (i.e. paging/swapping) of textures, polygon meshes and other data are loaded. It can also be used to expand the amount of video memory available for systems with only integrated or shared graphics, such as Intel HD Graphics processors. However, this type of memory expansion remapping has a caveat: any GART pre-allocated memory becomes pooled and cannot be utilized for any other purposes but graphics memory and display rendering. Since PCI Express, the GART is extended to the GTT, which acts as a buffer or cache between system memory and graphics card, and in PCI Express, the GTT buffer size is changeable by the GPU driver.

Reader's Guide

The GART's significance lies in enabling efficient data exchange between system memory and graphics hardware, allowing graphics cards to directly access host memory for textures and polygon meshes. This mechanism was foundational for AGP and later PCI Express graphics, and AMD extended it for I/O virtualization with other peripherals like disk controllers and network adapters. The GART also allowed systems with integrated graphics (e.g., Intel HD Graphics) to expand video memory, though at the cost of reserving system memory exclusively for graphics. Operating system support was gradually added: Windows from 95 OSR2 through Vista, Linux via the agpgart driver maintained by Jeff Hartmann and later reworked by Dave Jones, FreeBSD from its 4.1 release, and Solaris from the 7/05 Express Developer Edition. The transition to PCI Express introduced the GTT with a driver-changeable buffer size, reflecting the evolution of graphics memory management.

Did You Know?

• The GART is also known as the graphics aperture remapping table or graphics translation table (GTT).
• AMD reused the GART mechanism for I/O virtualization with disk controllers and network adapters.
• The Linux agpgart driver began as part of Brian Paul's Utah GLX accelerated Mesa 3D driver project.

Core Function and Architecture

The Graphics Address Remapping Table—commonly abbreviated as GART, and also referred to as the graphics aperture remapping table or graphics translation table—serves as a dedicated I/O memory management unit (IOMMU) purpose-built for graphics hardware. It operates alongside both Accelerated Graphics Port (AGP) and PCI Express (PCIe) graphics cards, providing the critical pathway through which a GPU performs direct memory access (DMA) into the host system's main memory. Through this mechanism, the graphics processor loads and exchanges buffers containing textures, polygon meshes, and other rendering data between system memory and video memory. In essence, GART acts as the translation layer that lets a graphics card read and write to addresses it would not otherwise be able to reach, making seamless data paging and swapping possible during real-time rendering workloads.

Memory Expansion and System-Wide Trade-offs

Beyond its primary role as a data-exchange conduit, the GART mechanism can be leveraged to effectively expand the pool of video memory available to systems that rely on integrated or shared graphics processors—such as Intel HD Graphics—rather than a discrete graphics card. In this configuration, the remapping table carves out a portion of the host's main memory and presents it to the GPU as additional framebuffer space. However, this approach carries a significant system-wide caveat: once memory is pre-allocated through the GART for graphics purposes, it becomes pooled and is no longer available for any other use. The entire operating system and all other applications must operate with that memory permanently reserved for display rendering and graphics workloads, meaning the trade-off is not merely a performance consideration but a hard reduction in usable system RAM.

Evolution from AGP to PCIe and Broader I/O Virtualization

With the arrival of PCI Express, the original GART concept evolved into the Graphics Translation Table (GTT), which functions as a buffer or cache sitting between system memory and the graphics card. A notable distinction in the PCIe era is that the GTT buffer size is no longer fixed; instead, it can be adjusted dynamically by the GPU driver, giving system builders and software developers finer control over how much memory is dedicated to graphics translation. The GART/GTT mechanism also proved influential beyond the graphics domain. AMD later repurposed the same underlying IOMMU architecture for broader I/O virtualization, extending its use to other peripheral devices such as disk controllers and network adapters. This reuse demonstrated that the address-remapping principles originally designed for accelerating texture and mesh transfers could serve as a general-purpose framework for managing device-to-memory access across a wide range of hardware components.

Cross-Platform Operating System Support

The GART and its successor GTT required dedicated driver support across the major operating systems of their era. On Windows, AGP GART support first appeared in Windows 95 OSR2, while GTT support was introduced later with Windows XP Service Pack 2 and Windows Vista. In the Linux world, the agpgart driver originated within Brian Paul's Utah GLX accelerated Mesa 3D driver project, with Jeff Hartmann serving as its primary maintainer. The developers initially targeted Linux 2.4.x kernels, though patches were also made available for older 2.2.x releases. Dave Jones subsequently undertook a major rework of the agpgart driver for the Linux 2.6.x kernel series, with further contributions from Hartmann. FreeBSD shipped its agpgart driver in the 4.1 release, and Solaris gained AGP GART support through the Solaris Express Developer Edition, specifically in its July 2005 release.