Difference between revisions of "Rendering Pipeline Overview"

From OpenGL Wiki
Jump to: navigation, search
(Remodelling to make it more like the specification.)
m (Bot: Updating section links to use redirects.)
Line 14: Line 14:
# [[Vertex Post-Processing]], the outputs of the last stage are adjusted or shipped to different locations.
## [[Transform Feedback]] happens here.
## [[Transform Feedback]] happens here.
## Primitive [[Clipping|Clipping]], the [[Vertex Post-Processing#Perspective divide|perspective divide]], and the [[Vertex Post-Processing#Viewport transform|viewport transform]] to window space.
## Primitive [[Clipping|Clipping]], the [[Perspective Divide|perspective divide]], and the [[Viewport Transform|viewport transform]] to window space.
# [[Primitive Assembly]]
# [[Primitive Assembly]]
# [[Rasterization|Scan conversion and primitive parameter interpolation]], which generates a number of [[Fragment]]s.

Revision as of 16:35, 6 May 2015



Rendering Pipeline Flowchart

The OpenGL rendering pipeline works in the following order:

  1. Prepare vertex array data, and then render it
  2. Vertex Processing:
    2. Optional primitive tessellation stages.
    1. Transform Feedback happens here.
  4. Primitive Assembly
  5. Scan conversion and primitive parameter interpolation, which generates a number of Fragments.
  7. Per-Sample_Processing:
    1. Scissor Test
    2. Stencil Test
    3. Depth Test
    4. Blending
    5. Logical Operation
    6. Write Mask

Vertex Specification





Vertex Rendering

Once the vertex data is properly specified, it is then rendered as a Primitive via a drawing command.

Vertex Processing

Vertices fetched due to the prior vertex rendering stage begin their processing here. The vertex processing stages are almost all programmable operations. This allows user code to customize the way vertices are processed. Each stage represents a different kind of shader operation.

Many of these stages are optional.

Vertex shader

Vertex shaders perform basic processing of each individual vertex. Vertex shaders receive the attribute inputs from the vertex rendering and converts each incoming vertex into a single outgoing vertex based on an arbitrary, user-defined program.

Vertex shaders can have user-defined outputs, but there is also a special output that represents the final position of the vertex. If there are no subsequent vertex processing stages, vertex shaders are expected to fill in this position with the clip-space position of the vertex, for rendering purposes.


Vertex shaders are not optional.


Core in version 4.6
Core since version 4.0
Core ARB extension ARB_tessellation_shader

Primitives can be tessellated using two shader stages and a fixed-function tessellator between them. The Tessellation Control Shader (TCS) stage comes first, and it determines the amount of tessellation to apply to a primitive, as well as ensuring connectivity between adjacent tessellated primitives. The Tessellation Evaluation Shader (TES) stage comes last, and it applies the interpolation or other operations used to compute user-defined data values for primitives generated by the fixed-function tessellation process.

Tessellation as a process is optional. Tessellation is considered active if a TES is active. The TCS is optional, but a TCS can only be used alongside a TES.

Geometry Shader

Geometry shaders are user-defined programs that process each incoming primitive, returning zero or more output primitives.

The input primitives for geometry shaders are the output primitives from a subset of the Primitive Assembly process. So if you send a triangle strip as a single primitive, what the geometry shader will see is a series of triangles.

However, there are a number of input primitive types that are defined specifically for geometry shaders. These adjacency primitives give GS's a larger view of the primitives; they provide access to vertices of primitives adjacent to the current one.


Geometry shaders are optional.

Vertex post-processing

After the shader-based vertex processing, vertices undergo a number of fixed-function processing steps.

Transform Feedback




The primitives are then clipped. Clipping means that primitives that lie on the boundary between the inside of the viewing volume and the outside are split into several primitives, such that the entire primitive lies in the volume. Also, the last Vertex Processing shader stage can specify user-defined clipping operations, on a per-vertex basis.


Primitive assembly

Primitive assembly is the process of collecting a run of vertex data output from the prior stages and composing it into a sequence of primitives. The type of primitive the user rendered with determines how this process works.


If tessellation or geometry shaders are active, then a limited form of primitive assembly is executed before these Vertex Processing stages. This is used to feed those particular shader stages with individual primitives, rather than a sequence of vertices.

The rendering pipeline can also be aborted at this stage. This allows the use of Transform Feedback operations, without having to actually render something.

Face culling

Triangle primitives can be culled (ie: discarded without rendering) based on the triangle's facing in window space. This allows you to avoid rendering triangles facing away from the viewer. For closed surfaces, such triangles would naturally be covered up by triangles facing the user, so there is never any need to render them. Face culling is a way to avoid rendering such primitives.





Fragment Processing


Per-Sample Operations


The first step is a sequence of culling tests; if a test is active and the fragment fails the test, the underlying pixels/samples are not updated (usually). Many of these tests are only active if the user activates them. The tests are:

  • Pixel ownership test: Fails if the fragment's pixel is not "owned" by OpenGL (if another window is overlapping with the GL window). Always passes when using a Framebuffer Object. Failure means that the pixel contains undefined values.
  • Scissor Test: When enabled, the test fails if the fragment's pixel lies outside of a specified rectangle of the screen.
  • Stencil Test: When enabled, the test fails if the stencil value provided by the test does not compare as the user specifies against the stencil value from the underlying sample in the stencil buffer. Note that the stencil value in the framebuffer can still be modified even if the stencil test fails (and even if the depth test fails).
  • Depth Test: When enabled, the test fails if the fragment's depth does not compare as the user specifies against the depth value from the underlying sample in the depth buffer.
Note: Though these are specified to happen after the Fragment Shader, they can be made to happen before the fragment shader under certain conditions. If they happen before the FS, then any culling of the fragment will also prevent the fragment shader from executing, this saving performance.

After this, color blending happens. For each fragment color value, there is a specific blending operation between it and the color already in the framebuffer at that location. Logical Operations may also take place in lieu of blending, which perform bitwise operations between the fragment colors and framebuffer colors.
