• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1.. _rasterizer:
2
3Rasterizer
4==========
5
6The rasterizer state controls the rendering of points, lines and triangles.
7Attributes include polygon culling state, line width, line stipple,
8multisample state, scissoring and flat/smooth shading.
9
10Linkage
11
12clamp_vertex_color
13^^^^^^^^^^^^^^^^^^
14
15If set, TGSI_SEMANTIC_COLOR registers are clamped to the [0, 1] range after
16the execution of the vertex shader, before being passed to the geometry
17shader or fragment shader.
18
19OpenGL: glClampColor(GL_CLAMP_VERTEX_COLOR) in GL 3.0 or GL_ARB_color_buffer_float
20
21D3D11: seems always disabled
22
23Note the PIPE_CAP_VERTEX_COLOR_CLAMPED query indicates whether or not the
24driver supports this control.  If it's not supported, gallium frontends may
25have to insert extra clamping code.
26
27
28clamp_fragment_color
29^^^^^^^^^^^^^^^^^^^^
30
31Controls whether TGSI_SEMANTIC_COLOR outputs of the fragment shader
32are clamped to [0, 1].
33
34OpenGL: glClampColor(GL_CLAMP_FRAGMENT_COLOR) in GL 3.0 or ARB_color_buffer_float
35
36D3D11: seems always disabled
37
38Note the PIPE_CAP_FRAGMENT_COLOR_CLAMPED query indicates whether or not the
39driver supports this control.  If it's not supported, gallium frontends may
40have to insert extra clamping code.
41
42
43Shading
44-------
45
46flatshade
47^^^^^^^^^
48
49If set, the provoking vertex of each polygon is used to determine the color
50of the entire polygon.  If not set, fragment colors will be interpolated
51between the vertex colors.
52
53The actual interpolated shading algorithm is obviously
54implementation-dependent, but will usually be Gourard for most hardware.
55
56.. note::
57
58    This is separate from the fragment shader input attributes
59    CONSTANT, LINEAR and PERSPECTIVE. The flatshade state is needed at
60    clipping time to determine how to set the color of new vertices.
61
62    :ref:`Draw` can implement flat shading by copying the provoking vertex
63    color to all the other vertices in the primitive.
64
65flatshade_first
66^^^^^^^^^^^^^^^
67
68Whether the first vertex should be the provoking vertex, for most primitives.
69If not set, the last vertex is the provoking vertex.
70
71There are a few important exceptions to the specification of this rule.
72
73* ``PIPE_PRIMITIVE_POLYGON``: The provoking vertex is always the first
74  vertex. If the caller wishes to change the provoking vertex, they merely
75  need to rotate the vertices themselves.
76* ``PIPE_PRIMITIVE_QUAD``, ``PIPE_PRIMITIVE_QUAD_STRIP``: The option only has
77  an effect if ``PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION`` is true.
78  If it is not, the provoking vertex is always the last vertex.
79* ``PIPE_PRIMITIVE_TRIANGLE_FAN``: When set, the provoking vertex is the
80  second vertex, not the first. This permits each segment of the fan to have
81  a different color.
82
83Polygons
84--------
85
86light_twoside
87^^^^^^^^^^^^^
88
89If set, there are per-vertex back-facing colors.  The hardware
90(perhaps assisted by :ref:`Draw`) should be set up to use this state
91along with the front/back information to set the final vertex colors
92prior to rasterization.
93
94The frontface vertex shader color output is marked with TGSI semantic
95COLOR[0], and backface COLOR[1].
96
97front_ccw
98    Indicates whether the window order of front-facing polygons is
99    counter-clockwise (TRUE) or clockwise (FALSE).
100
101cull_mode
102    Indicates which faces of polygons to cull, either PIPE_FACE_NONE
103    (cull no polygons), PIPE_FACE_FRONT (cull front-facing polygons),
104    PIPE_FACE_BACK (cull back-facing polygons), or
105    PIPE_FACE_FRONT_AND_BACK (cull all polygons).
106
107fill_front
108    Indicates how to fill front-facing polygons, either
109    PIPE_POLYGON_MODE_FILL, PIPE_POLYGON_MODE_LINE or
110    PIPE_POLYGON_MODE_POINT.
111fill_back
112    Indicates how to fill back-facing polygons, either
113    PIPE_POLYGON_MODE_FILL, PIPE_POLYGON_MODE_LINE or
114    PIPE_POLYGON_MODE_POINT.
115
116poly_stipple_enable
117    Whether polygon stippling is enabled.
118poly_smooth
119    Controls OpenGL-style polygon smoothing/antialiasing
120
121offset_point
122    If set, point-filled polygons will have polygon offset factors applied
123offset_line
124    If set, line-filled polygons will have polygon offset factors applied
125offset_tri
126    If set, filled polygons will have polygon offset factors applied
127
128offset_units
129    Specifies the polygon offset bias
130offset_units_unscaled
131    Specifies the unit of the polygon offset bias. If false, use the
132    GL/D3D1X behavior. If true, offset_units is a floating point offset
133    which isn't scaled (D3D9). Note that GL/D3D1X behavior has different
134    formula whether the depth buffer is unorm or float, which is not
135    the case for D3D9.
136offset_scale
137    Specifies the polygon offset scale
138offset_clamp
139    Upper (if > 0) or lower (if < 0) bound on the polygon offset result
140
141
142
143Lines
144-----
145
146line_width
147    The width of lines.
148line_smooth
149    Whether lines should be smoothed. Line smoothing is simply anti-aliasing.
150line_stipple_enable
151    Whether line stippling is enabled.
152line_stipple_pattern
153    16-bit bitfield of on/off flags, used to pattern the line stipple.
154line_stipple_factor
155    When drawing a stippled line, each bit in the stipple pattern is
156    repeated N times, where N = line_stipple_factor + 1.
157line_last_pixel
158    Controls whether the last pixel in a line is drawn or not.  OpenGL
159    omits the last pixel to avoid double-drawing pixels at the ends of lines
160    when drawing connected lines.
161
162
163Points
164------
165
166sprite_coord_enable
167^^^^^^^^^^^^^^^^^^^
168The effect of this state depends on PIPE_CAP_TGSI_TEXCOORD !
169
170Controls automatic texture coordinate generation for rendering sprite points.
171
172If PIPE_CAP_TGSI_TEXCOORD is false:
173When bit k in the sprite_coord_enable bitfield is set, then generic
174input k to the fragment shader will get an automatically computed
175texture coordinate.
176
177If PIPE_CAP_TGSI_TEXCOORD is true:
178The bitfield refers to inputs with TEXCOORD semantic instead of generic inputs.
179
180The texture coordinate will be of the form (s, t, 0, 1) where s varies
181from 0 to 1 from left to right while t varies from 0 to 1 according to
182the state of 'sprite_coord_mode' (see below).
183
184If any bit is set, then point_smooth MUST be disabled (there are no
185round sprites) and point_quad_rasterization MUST be true (sprites are
186always rasterized as quads).  Any mismatch between these states should
187be considered a bug in the gallium frontend.
188
189This feature is implemented in the :ref:`Draw` module but may also be
190implemented natively by GPUs or implemented with a geometry shader.
191
192
193sprite_coord_mode
194^^^^^^^^^^^^^^^^^
195
196Specifies how the value for each shader output should be computed when drawing
197point sprites. For PIPE_SPRITE_COORD_LOWER_LEFT, the lower-left vertex will
198have coordinates (0,0,0,1). For PIPE_SPRITE_COORD_UPPER_LEFT, the upper-left
199vertex will have coordinates (0,0,0,1).
200This state is used by :ref:`Draw` to generate texcoords.
201
202
203point_quad_rasterization
204^^^^^^^^^^^^^^^^^^^^^^^^
205
206Determines if points should be rasterized according to quad or point
207rasterization rules.
208
209(Legacy-only) OpenGL actually has quite different rasterization rules
210for points and point sprites - hence this indicates if points should be
211rasterized as points or according to point sprite (which decomposes them
212into quads, basically) rules. Newer GL versions no longer support the old
213point rules at all.
214
215Additionally Direct3D will always use quad rasterization rules for
216points, regardless of whether point sprites are enabled or not.
217
218If this state is enabled, point smoothing and antialiasing are
219disabled. If it is disabled, point sprite coordinates are not
220generated.
221
222.. note::
223
224   Some renderers always internally translate points into quads; this state
225   still affects those renderers by overriding other rasterization state.
226
227point_tri_clip
228    Determines if clipping of points should happen after they are converted
229    to "rectangles" (required by d3d) or before (required by OpenGL, though
230    this rule is ignored by some IHVs).
231    It is not valid to set this to enabled but have point_quad_rasterization
232    disabled.
233point_smooth
234    Whether points should be smoothed. Point smoothing turns rectangular
235    points into circles or ovals.
236point_size_per_vertex
237    Whether the vertex shader is expected to have a point size output.
238    Undefined behavior is permitted if there is disagreement between
239    this flag and the actual bound shader.
240point_size
241    The size of points, if not specified per-vertex.
242
243
244
245Other Members
246-------------
247
248scissor
249    Whether the scissor test is enabled.
250
251multisample
252    Whether :term:`MSAA` is enabled.
253
254half_pixel_center
255    When true, the rasterizer should use (0.5, 0.5) pixel centers for
256    determining pixel ownership (e.g, OpenGL, D3D10 and higher)::
257
258           0 0.5 1
259        0  +-----+
260           |     |
261       0.5 |  X  |
262           |     |
263        1  +-----+
264
265    When false, the rasterizer should use (0, 0) pixel centers for determining
266    pixel ownership (e.g., D3D9 or ealier)::
267
268         -0.5 0 0.5
269      -0.5 +-----+
270           |     |
271        0  |  X  |
272           |     |
273       0.5 +-----+
274
275bottom_edge_rule
276    Determines what happens when a pixel sample lies precisely on a triangle
277    edge.
278
279    When true, a pixel sample is considered to lie inside of a triangle if it
280    lies on the *bottom edge* or *left edge* (e.g., OpenGL drawables)::
281
282        0                    x
283      0 +--------------------->
284        |
285        |  +-------------+
286        |  |             |
287        |  |             |
288        |  |             |
289        |  +=============+
290        |
291      y V
292
293    When false, a pixel sample is considered to lie inside of a triangle if it
294    lies on the *top edge* or *left edge* (e.g., OpenGL FBOs, D3D)::
295
296        0                    x
297      0 +--------------------->
298        |
299        |  +=============+
300        |  |             |
301        |  |             |
302        |  |             |
303        |  +-------------+
304        |
305      y V
306
307    Where:
308     - a *top edge* is an edge that is horizontal and is above the other edges;
309     - a *bottom edge* is an edge that is horizontal and is below the other
310       edges;
311     - a *left edge* is an edge that is not horizontal and is on the left side of
312       the triangle.
313
314    .. note::
315
316        Actually all graphics APIs use a top-left rasterization rule for pixel
317        ownership, but their notion of top varies with the axis origin (which
318        can be either at y = 0 or at y = height).  Gallium instead always
319        assumes that top is always at y=0.
320
321    See also:
322     - http://msdn.microsoft.com/en-us/library/windows/desktop/cc627092.aspx
323     - http://msdn.microsoft.com/en-us/library/windows/desktop/bb147314.aspx
324
325clip_halfz
326    When true clip space in the z axis goes from [0..1] (D3D).  When false
327    [-1, 1] (GL)
328
329depth_clip_near
330    When false, the near depth clipping plane of the view volume is disabled.
331depth_clip_far
332    When false, the far depth clipping plane of the view volume is disabled.
333depth_clamp
334    Whether the depth value will be clamped to the interval defined by the
335    near and far depth range at the per-pixel level, after polygon offset has
336    been applied and before depth testing. Note that a clamp to [0,1] according
337    to GL rules should always happen even if this is disabled.
338
339clip_plane_enable
340    For each k in [0, PIPE_MAX_CLIP_PLANES), if bit k of this field is set,
341    clipping half-space k is enabled, if it is clear, it is disabled.
342    The clipping half-spaces are defined either by the user clip planes in
343    ``pipe_clip_state``, or by the clip distance outputs of the shader stage
344    preceding the fragment shader.
345    If any clip distance output is written, those half-spaces for which no
346    clip distance is written count as disabled; i.e. user clip planes and
347    shader clip distances cannot be mixed, and clip distances take precedence.
348
349conservative_raster_mode
350    The conservative rasterization mode.  For PIPE_CONSERVATIVE_RASTER_OFF,
351    conservative rasterization is disabled.  For IPE_CONSERVATIVE_RASTER_POST_SNAP
352    or PIPE_CONSERVATIVE_RASTER_PRE_SNAP, conservative rasterization is nabled.
353    When conservative rasterization is enabled, the polygon smooth, line mooth,
354    point smooth and line stipple settings are ignored.
355    With the post-snap mode, unlike the pre-snap mode, fragments are never
356    generated for degenerate primitives.  Degenerate primitives, when rasterized,
357    are considered back-facing and the vertex attributes and depth are that of
358    the provoking vertex.
359    If the post-snap mode is used with an unsupported primitive, the pre-snap
360    mode is used, if supported.  Behavior is similar for the pre-snap mode.
361    If the pre-snap mode is used, fragments are generated with respect to the primitive
362    before vertex snapping.
363
364conservative_raster_dilate
365    The amount of dilation during conservative rasterization.
366
367subpixel_precision_x
368    A bias added to the horizontal subpixel precision during conservative rasterization.
369subpixel_precision_y
370    A bias added to the vertical subpixel precision during conservative rasterization.
371