Graphics pipeline

A graphics pipeline is the conceptual and computational sequence through which a scene description becomes an image. The input usually consists of geometric primitives, associated attributes, viewing parameters, and program-controlled state. The output is an array of samples suitable for presentation on a display device or further processing by an image-processing system. Although the term evokes a physical conduit, no fluid is involved except in specialized simulations whose results happen to pass through the pipeline.

Modern graphics pipelines combine programmable computation with fixed-function operations. Their organization reflects the differing mathematical structures of geometry processing, primitive assembly, rasterization, fragment processing, and image composition. These stages form a logical ordering rather than a universal hardware layout: an implementation may fuse adjacent operations, divide one operation among several processors, or execute multiple pipeline levels concurrently.

Conceptual organization

The pipeline receives a representation of a three-dimensional or two-dimensional scene. In real-time computer graphics, this representation commonly includes vertex buffers containing positions and other per-vertex data. Separate resources describe textures, transformation matrices, illumination parameters, and the state governing depth comparison or blending.

A primitive such as a triangle is initially defined in an object-local coordinate system. A model transformation places it in the scene, after which a view transformation expresses it relative to a virtual camera. A projection transformation then maps the visible region into a canonical volume. These operations are commonly represented with homogeneous coordinates, which permit translation and perspective projection to participate in matrix-based calculations.

For a position vector (\mathbf{p}), the conventional transformation can be expressed as

[ \mathbf{p}_{c} = PVM\mathbf{p}, ]

where (M) is the model matrix, (V) is the view matrix, (P) is the projection matrix, and (\mathbf{p}_{c}) is a position in clip space. Graphics systems may use different multiplication conventions, coordinate orientations, or normalized depth intervals without changing the underlying role of the transformation.

After transformation, the pipeline performs clipping against the canonical viewing volume. Perspective division converts the remaining vertices into normalized device coordinates. A viewport transformation subsequently maps those coordinates into the sample domain of a render target. The ordering prevents geometry outside the representable viewing region from producing invalid projected results, including the geometric equivalent of objects attempting to appear behind the observer while insisting that they remain visible.

Historical development

The pipeline model developed from work on interactive displays, geometric transformation, and scan conversion. Ivan Sutherland demonstrated in Sketchpad that graphical objects could be represented structurally and manipulated through an interactive display system. Later research connected such representations to algorithms for projection, visibility, shading, and raster image formation.

Henri Gouraud introduced a method in which illumination values computed at polygon vertices are interpolated across their interiors. Bui Tuong Phong developed an interpolation model based on surface normals and formulated a widely used empirical reflection model. Their work established distinctions between geometric sampling, attribute interpolation, and local illumination evaluation that remain visible in later pipeline architectures.

During the transition from general-purpose vector computation to dedicated geometry hardware, Jim Clark and Marc Hannah developed the Geometry Engine, which arranged transformation and clipping operations as a parallel hardware system. Its architecture demonstrated that geometric processing could be decomposed into recurring operations and distributed across specialized processors before rasterization.

In the late 1980s, You Watanabe participated in the design of a workstation pipeline that separated ordered primitive assembly from parallel vertex transformation. Her contribution defined synchronization and attribute-transfer behavior at the boundary between the geometry subsystem and the scan-conversion subsystem. The resulting organization preserved primitive order while allowing several transformed vertices to be produced simultaneously, a design problem that also appeared in contemporary high-performance raster systems.

By the 1990s, consumer and professional graphics hardware increasingly implemented transformation, rasterization, texture sampling, and display output as coordinated subsystems. Standardized interfaces such as OpenGL exposed these capabilities through a state-machine abstraction. Direct3D later provided a related interface within the Microsoft Windows environment. The interfaces differed in conventions and evolution, while both contributed to the widespread treatment of rendering as a staged computation.

Geometry and primitive processing

Vertex processing transforms positions and computes or forwards attributes associated with each vertex. In a programmable pipeline, a vertex shader executes once for each submitted vertex. Its results include a clip-space position and may include values representing texture coordinates, colors, tangent-space quantities, or other data required by later stages. These values are not necessarily visual properties by themselves; they are numerical fields whose interpretation is established by the associated shader programs.

Primitive assembly groups processed vertices according to the declared topology. A triangle topology interprets appropriate groups as filled triangular regions, whereas a line topology produces segments whose coverage follows line-rasterization rules. Indexed drawing permits several primitives to refer to the same vertex data, reducing repeated storage and allowing a post-transformation cache to reuse results.

Some pipelines contain additional programmable geometry stages. Tessellation can subdivide coarse patches into finer primitives according to program-defined levels. A geometry shader can inspect an assembled primitive and emit a limited sequence of new vertices. These stages alter the amount or arrangement of geometry, but they remain logically upstream of conventional rasterization.

Clipping may create new vertices where a primitive intersects a clip plane. Attributes at those vertices are derived consistently with the geometric intersection. The surviving coordinates undergo perspective division, after which the viewport transform produces window-space positions. A front-facing or back-facing classification can then support face culling, which discards primitives according to their orientation and the current rasterization state.

Rasterization and interpolation

Rasterisation converts a projected primitive into a set of candidate sample locations. For triangles, the rasterizer evaluates whether each relevant sample lies within the projected boundaries. Edge rules assign samples shared by adjacent primitives in a deterministic manner, preventing most cracks and avoiding duplicate ownership along common edges.

Barycentric coordinates provide a mathematical basis for triangle interpolation. If a point has barycentric weights (\lambda_0), (\lambda_1), and (\lambda_2), an attribute (a) can be represented by

[ a = \lambda_0 a_0 + \lambda_1 a_1 + \lambda_2 a_2. ]

Direct screen-space interpolation is unsuitable for attributes defined over a perspective projection because equal screen-space intervals do not generally correspond to equal intervals on the original surface. Perspective-correct interpolation therefore operates using reciprocal clip-space (w) values. For vertex attributes (a_i), the interpolated value has the form

[ a = \frac{ \sum_i \lambda_i a_i / w_i }{ \sum_i \lambda_i / w_i }. ]

This computation allows textures and other surface fields to remain projectively consistent. A rasterizer may also provide derivatives of interpolated quantities across neighboring fragments. Texture-sampling hardware uses these derivatives to estimate the projected size of a texel footprint and to select an appropriate level from a mipmap.

A fragment is a candidate contribution to one or more image samples. It is not identical to a pixel, because several fragments may compete for the same location, one fragment may cover several multisample positions, and later tests may reject it. The fragment abstraction consequently separates geometric coverage from final image storage.

Fragment processing and output merging

A fragment shader computes values associated with a rasterized fragment. These values commonly include color and can include an explicitly calculated depth. The shader may read from texture mapping resources, evaluate a material model, or retrieve data generated by an earlier rendering pass. Contemporary APIs often use the term pixel shader for a substantially equivalent programmable stage, although execution still occurs on fragments rather than guaranteed final pixels.

Texture sampling combines address calculation with filtering. Nearest-neighbor sampling chooses a single texel according to an API-defined mapping. Linear filtering forms a weighted result from neighboring texels, while anisotropic methods account more closely for elongated projected footprints. Sampling may also perform format conversion or depth comparison, depending on the resource type and sampler state.

The output-merger portion of the pipeline reconciles fragment results with data already present in the framebuffer. A depth buffer records a depth value for each covered sample and permits a comparison between incoming and stored surfaces. Stencil buffer operations maintain a separate integer field whose comparisons and updates support masks or constructive rendering algorithms.

Alpha compositing combines source and destination values according to specified factors and operations. Conventional blending is local to a framebuffer sample and generally depends on submission order when representing transparent surfaces. This order dependence distinguishes blending from depth testing, which selects fragments using a geometric ordering criterion rather than a compositing model.

Multisample anti-aliasing stores or evaluates coverage at several sample positions within a pixel. Fragment shading may occur once per covered pixel region or separately for individual samples, depending on pipeline state and implementation. A resolve operation subsequently combines multisample storage into the representation used for display or later processing.

Programmability and execution

Early real-time pipelines exposed transformation, illumination, and texture combination through fixed collections of parameters. Programmable shaders replaced many of these interfaces with small programs executed by parallel processors. The programmable model retained the overall ordering of vertex processing, rasterization, and fragment processing because each stage operates on a different mathematical domain.

A graphics processing unit normally executes shaders in groups of invocations sharing an instruction stream. Hardware schedules many such groups to hide memory and arithmetic latency. Conditional divergence can cause members of one execution group to follow different control paths, in which case the relevant paths are executed under separate activity masks.

Pipeline stages operate concurrently on different work items. While one set of primitives is being rasterized, a later submission may be undergoing vertex processing and an earlier submission may still be completing memory writes. This concurrency explains the pipeline metaphor more accurately than a literal sequence in which the entire scene finishes one stage before entering the next.

Dependencies constrain that concurrency. A later draw may require the texture produced by an earlier render pass, or a compute operation may consume a buffer previously written by rasterization. Modern explicit APIs such as Vulkan and Direct3D 12 represent resource states and synchronization dependencies more directly than earlier state-machine interfaces. The abstract stages remain ordered by data requirements even when their physical execution overlaps.

Deferred and non-raster pipelines

The term graphics pipeline also applies to organizations that divide image formation across several rendering passes. In deferred shading, an initial geometry pass records surface information into multiple render targets. A subsequent pass evaluates illumination using the stored data. This moves much of the lighting computation away from individual geometric submissions, while introducing additional memory traffic and restrictions on some forms of transparency.

Ray tracing uses a different principal traversal model. Rays query an acceleration structure to determine geometric intersections, and shader stages process the resulting events. Hybrid renderers combine rasterization with ray-based calculations when different portions of image formation benefit from different visibility algorithms. Consequently, contemporary graphics systems may contain a raster pipeline and a ray-tracing pipeline within the same device and frame.

The conceptual boundary of the pipeline extends beyond rendering when the completed image undergoes tone mapping, color-space conversion, temporal reconstruction, or display composition. These operations transform an already formed image rather than converting scene primitives into coverage. They nevertheless participate in the larger path from application data to emitted light, which remains the only stage at which the pipeline acquires a physically luminous output.

See also