The rasterizer state controls the rendering of points, lines and triangles. Attributes include polygon culling state, line width, line stipple, multisample state, scissoring and flat/smooth shading.
Linkage
If set, TGSI_SEMANTIC_COLOR registers are clamped to the [0, 1] range after the execution of the vertex shader, before being passed to the geometry shader or fragment shader.
OpenGL: glClampColor(GL_CLAMP_VERTEX_COLOR) in GL 3.0 or GL_ARB_color_buffer_float
D3D11: seems always disabled
Note the PIPE_CAP_VERTEX_COLOR_CLAMPED query indicates whether or not the driver supports this control. If it’s not supported, the state tracker may have to insert extra clamping code.
Controls whether TGSI_SEMANTIC_COLOR outputs of the fragment shader are clamped to [0, 1].
OpenGL: glClampColor(GL_CLAMP_FRAGMENT_COLOR) in GL 3.0 or ARB_color_buffer_float
D3D11: seems always disabled
Note the PIPE_CAP_FRAGMENT_COLOR_CLAMPED query indicates whether or not the driver supports this control. If it’s not supported, the state tracker may have to insert extra clamping code.
If set, the provoking vertex of each polygon is used to determine the color of the entire polygon. If not set, fragment colors will be interpolated between the vertex colors.
The actual interpolated shading algorithm is obviously implementation-dependent, but will usually be Gourard for most hardware.
Note
This is separate from the fragment shader input attributes CONSTANT, LINEAR and PERSPECTIVE. The flatshade state is needed at clipping time to determine how to set the color of new vertices.
Draw can implement flat shading by copying the provoking vertex color to all the other vertices in the primitive.
Whether the first vertex should be the provoking vertex, for most primitives. If not set, the last vertex is the provoking vertex.
There are a few important exceptions to the specification of this rule.
If set, there are per-vertex back-facing colors. The hardware (perhaps assisted by Draw) should be set up to use this state along with the front/back information to set the final vertex colors prior to rasterization.
The frontface vertex shader color output is marked with TGSI semantic COLOR[0], and backface COLOR[1].
The effect of this state depends on PIPE_CAP_TGSI_TEXCOORD !
Controls automatic texture coordinate generation for rendering sprite points.
If PIPE_CAP_TGSI_TEXCOORD is false: When bit k in the sprite_coord_enable bitfield is set, then generic input k to the fragment shader will get an automatically computed texture coordinate.
If PIPE_CAP_TGSI_TEXCOORD is true: The bitfield refers to inputs with TEXCOORD semantic instead of generic inputs.
The texture coordinate will be of the form (s, t, 0, 1) where s varies from 0 to 1 from left to right while t varies from 0 to 1 according to the state of ‘sprite_coord_mode’ (see below).
If any bit is set, then point_smooth MUST be disabled (there are no round sprites) and point_quad_rasterization MUST be true (sprites are always rasterized as quads). Any mismatch between these states should be considered a bug in the state-tracker.
This feature is implemented in the Draw module but may also be implemented natively by GPUs or implemented with a geometry shader.
Specifies how the value for each shader output should be computed when drawing point sprites. For PIPE_SPRITE_COORD_LOWER_LEFT, the lower-left vertex will have coordinates (0,0,0,1). For PIPE_SPRITE_COORD_UPPER_LEFT, the upper-left vertex will have coordinates (0,0,0,1). This state is used by Draw to generate texcoords.
Determines if points should be rasterized according to quad or point rasterization rules.
(Legacy-only) OpenGL actually has quite different rasterization rules for points and point sprites - hence this indicates if points should be rasterized as points or according to point sprite (which decomposes them into quads, basically) rules. Newer GL versions no longer support the old point rules at all.
Additionally Direct3D will always use quad rasterization rules for points, regardless of whether point sprites are enabled or not.
If this state is enabled, point smoothing and antialiasing are disabled. If it is disabled, point sprite coordinates are not generated.
Note
Some renderers always internally translate points into quads; this state still affects those renderers by overriding other rasterization state.
When true, the rasterizer should use (0.5, 0.5) pixel centers for determining pixel ownership (e.g, OpenGL, D3D10 and higher):
0 0.5 1
0 +-----+
| |
0.5 | X |
| |
1 +-----+
When false, the rasterizer should use (0, 0) pixel centers for determining pixel ownership (e.g., D3D9 or ealier):
-0.5 0 0.5
-0.5 +-----+
| |
0 | X |
| |
0.5 +-----+
Determines what happens when a pixel sample lies precisely on a triangle edge.
When true, a pixel sample is considered to lie inside of a triangle if it lies on the bottom edge or left edge (e.g., OpenGL drawables):
0 x
0 +--------------------->
|
| +-------------+
| | |
| | |
| | |
| +=============+
|
y V
When false, a pixel sample is considered to lie inside of a triangle if it lies on the top edge or left edge (e.g., OpenGL FBOs, D3D):
0 x
0 +--------------------->
|
| +=============+
| | |
| | |
| | |
| +-------------+
|
y V
Note
Actually all graphics APIs use a top-left rasterization rule for pixel ownership, but their notion of top varies with the axis origin (which can be either at y = 0 or at y = height). Gallium instead always assumes that top is always at y=0.