SecBSD/xenocara
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

sync code with last improvements from OpenBSD

Browse source
This commit is contained in:
purplerain 2023-08-28 05:57:34 +00:00
commit 88965415ff
Signed by: purplerain
GPG key ID: F42C07F07E2E35B7
26235 changed files with 29195616 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

128
lib/mesa/docs/gallium/cso/blend.rst Normal file
View file

@ -0,0 +1,128 @@
.. _blend:
Blend
=====
This state controls blending of the final fragments into the target rendering
buffers.
Blend Factors
-------------
The blend factors largely follow the same pattern as their counterparts
in other modern and legacy drawing APIs.
Dual source blend factors are supported for up to 1 MRT, although
you can advertise > 1 MRT, the stack cannot handle them for a few reasons.
There is no definition on how the 1D array of shader outputs should be mapped
to something that would be a 2D array (location, index). No current hardware
exposes > 1 MRT, and we should revisit this issue if anyone ever does.
Logical Operations
------------------
Logical operations, also known as logicops, LOPs, or ROPs, are supported.
Only two-operand logicops are available. When logicops are enabled, all other
blend state is ignored, including per-render-target state, so logicops are
performed on all render targets.
.. warning::
The blend_enable flag is ignored for all render targets when logical
operations are enabled.
For a source component `s` and destination component `d`, the logical
operations are defined as taking the bits of each channel of each component,
and performing one of the following operations per-channel:
* ``CLEAR``: 0
* ``NOR``: :math:`\lnot(s \lor d)`
* ``AND_INVERTED``: :math:`\lnot s \land d`
* ``COPY_INVERTED``: :math:`\lnot s`
* ``AND_REVERSE``: :math:`s \land \lnot d`
* ``INVERT``: :math:`\lnot d`
* ``XOR``: :math:`s \oplus d`
* ``NAND``: :math:`\lnot(s \land d)`
* ``AND``: :math:`s \land d`
* ``EQUIV``: :math:`\lnot(s \oplus d)`
* ``NOOP``: :math:`d`
* ``OR_INVERTED``: :math:`\lnot s \lor d`
* ``COPY``: :math:`s`
* ``OR_REVERSE``: :math:`s \lor \lnot d`
* ``OR``: :math:`s \lor d`
* ``SET``: 1
.. note::
The logical operation names and definitions match those of the OpenGL API,
and are similar to the ROP2 and ROP3 definitions of GDI. This is
intentional, to ease transitions to Gallium.
Members
-------
These members affect all render targets.
dither
%%%%%%
Whether dithering is enabled.
.. note::
Dithering is completely implementation-dependent. It may be ignored by
drivers for any reason, and some render targets may always or never be
dithered depending on their format or usage flags.
logicop_enable
%%%%%%%%%%%%%%
Whether the blender should perform a logicop instead of blending.
logicop_func
%%%%%%%%%%%%
The logicop to use. One of ``PIPE_LOGICOP``.
independent_blend_enable
If enabled, blend state is different for each render target, and
for each render target set in the respective member of the rt array.
If disabled, blend state is the same for all render targets, and only
the first member of the rt array contains valid data.
rt
Contains the per-rendertarget blend state.
alpha_to_coverage
If enabled, the fragment's alpha value is used to override the fragment's
coverage mask. The coverage mask will be all zeros if the alpha value is
zero. The coverage mask will be all ones if the alpha value is one.
Otherwise, the number of bits set in the coverage mask will be proportional
to the alpha value. Note that this step happens regardless of whether
multisample is enabled or the destination buffer is multisampled.
alpha_to_one
If enabled, the fragment's alpha value will be set to one. As with
alpha_to_coverage, this step happens regardless of whether multisample
is enabled or the destination buffer is multisampled.
max_rt
The index of the max render target (irrespective of whether independent
blend is enabled), i.e. the number of MRTs minus one. This is provided
so that the driver can avoid the overhead of programming unused MRTs.
Per-rendertarget Members
------------------------
blend_enable
If blending is enabled, perform a blend calculation according to blend
functions and source/destination factors. Otherwise, the incoming fragment
color gets passed unmodified (but colormask still applies).
rgb_func
The blend function to use for RGB channels. One of PIPE_BLEND.
rgb_src_factor
The blend source factor to use for RGB channels. One of PIPE_BLENDFACTOR.
rgb_dst_factor
The blend destination factor to use for RGB channels. One of PIPE_BLENDFACTOR.
alpha_func
The blend function to use for the alpha channel. One of PIPE_BLEND.
alpha_src_factor
The blend source factor to use for the alpha channel. One of PIPE_BLENDFACTOR.
alpha_dst_factor
The blend destination factor to use for alpha channel. One of PIPE_BLENDFACTOR.
colormask
Bitmask of which channels to write. Combination of PIPE_MASK bits.

61
lib/mesa/docs/gallium/cso/dsa.rst Normal file
View file

@ -0,0 +1,61 @@
.. _depth-stencil-alpha:
Depth, Stencil, & Alpha
=======================
These three states control the depth, stencil, and alpha tests, used to
discard fragments that have passed through the fragment shader.
Traditionally, these three tests have been clumped together in hardware, so
they are all stored in one structure.
During actual execution, the order of operations done on fragments is always:
* Alpha
* Stencil
* Depth
Depth Members
-------------
enabled
Whether the depth test is enabled.
writemask
Whether the depth buffer receives depth writes.
func
The depth test function. One of PIPE_FUNC.
Stencil Members
---------------
enabled
Whether the stencil test is enabled. For the second stencil, whether the
two-sided stencil is enabled. If two-sided stencil is disabled, the other
fields for the second array member are not valid.
func
The stencil test function. One of PIPE_FUNC.
valuemask
Stencil test value mask; this is ANDed with the value in the stencil
buffer and the reference value before doing the stencil comparison test.
writemask
Stencil test writemask; this controls which bits of the stencil buffer
are written.
fail_op
The operation to carry out if the stencil test fails. One of
PIPE_STENCIL_OP.
zfail_op
The operation to carry out if the stencil test passes but the depth test
fails. One of PIPE_STENCIL_OP.
zpass_op
The operation to carry out if the stencil test and depth test both pass.
One of PIPE_STENCIL_OP.
Alpha Members
-------------
enabled
Whether the alpha test is enabled.
func
The alpha test function. One of PIPE_FUNC.
ref_value
Alpha test reference value; used for certain functions.

370
lib/mesa/docs/gallium/cso/rasterizer.rst Normal file
View file

@ -0,0 +1,370 @@
.. _rasterizer:
Rasterizer
==========
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
clamp_vertex_color
^^^^^^^^^^^^^^^^^^
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, gallium frontends may
have to insert extra clamping code.
clamp_fragment_color
^^^^^^^^^^^^^^^^^^^^
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, gallium frontends may
have to insert extra clamping code.
Shading
-------
flatshade
^^^^^^^^^
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 Gouraud 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.
:ref:`Draw` can implement flat shading by copying the provoking vertex
color to all the other vertices in the primitive.
flatshade_first
^^^^^^^^^^^^^^^
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.
* ``PIPE_PRIMITIVE_POLYGON``: The provoking vertex is always the first
vertex. If the caller wishes to change the provoking vertex, they merely
need to rotate the vertices themselves.
* ``PIPE_PRIMITIVE_QUAD``, ``PIPE_PRIMITIVE_QUAD_STRIP``: The option only has
an effect if ``PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION`` is true.
If it is not, the provoking vertex is always the last vertex.
* ``PIPE_PRIMITIVE_TRIANGLE_FAN``: When set, the provoking vertex is the
second vertex, not the first. This permits each segment of the fan to have
a different color.
Polygons
--------
light_twoside
^^^^^^^^^^^^^
If set, there are per-vertex back-facing colors. The hardware
(perhaps assisted by :ref:`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].
front_ccw
Indicates whether the window order of front-facing polygons is
counter-clockwise (TRUE) or clockwise (FALSE).
cull_mode
Indicates which faces of polygons to cull, either PIPE_FACE_NONE
(cull no polygons), PIPE_FACE_FRONT (cull front-facing polygons),
PIPE_FACE_BACK (cull back-facing polygons), or
PIPE_FACE_FRONT_AND_BACK (cull all polygons).
fill_front
Indicates how to fill front-facing polygons, either
PIPE_POLYGON_MODE_FILL, PIPE_POLYGON_MODE_LINE or
PIPE_POLYGON_MODE_POINT.
fill_back
Indicates how to fill back-facing polygons, either
PIPE_POLYGON_MODE_FILL, PIPE_POLYGON_MODE_LINE or
PIPE_POLYGON_MODE_POINT.
poly_stipple_enable
Whether polygon stippling is enabled.
poly_smooth
Controls OpenGL-style polygon smoothing/antialiasing
offset_point
If set, point-filled polygons will have polygon offset factors applied
offset_line
If set, line-filled polygons will have polygon offset factors applied
offset_tri
If set, filled polygons will have polygon offset factors applied
offset_units
Specifies the polygon offset bias
offset_units_unscaled
Specifies the unit of the polygon offset bias. If false, use the
GL/D3D1X behavior. If true, offset_units is a floating point offset
which isn't scaled (D3D9). Note that GL/D3D1X behavior has different
formula whether the depth buffer is unorm or float, which is not
the case for D3D9.
offset_scale
Specifies the polygon offset scale
offset_clamp
Upper (if > 0) or lower (if < 0) bound on the polygon offset result
Lines
-----
line_width
The width of lines.
line_smooth
Whether lines should be smoothed. Line smoothing is simply anti-aliasing.
line_stipple_enable
Whether line stippling is enabled.
line_stipple_pattern
16-bit bitfield of on/off flags, used to pattern the line stipple.
line_stipple_factor
When drawing a stippled line, each bit in the stipple pattern is
repeated N times, where N = line_stipple_factor + 1.
line_last_pixel
Controls whether the last pixel in a line is drawn or not. OpenGL
omits the last pixel to avoid double-drawing pixels at the ends of lines
when drawing connected lines.
Points
------
sprite_coord_enable
^^^^^^^^^^^^^^^^^^^
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 gallium frontend.
This feature is implemented in the :ref:`Draw` module but may also be
implemented natively by GPUs or implemented with a geometry shader.
sprite_coord_mode
^^^^^^^^^^^^^^^^^
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 :ref:`Draw` to generate texcoords.
point_quad_rasterization
^^^^^^^^^^^^^^^^^^^^^^^^
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.
point_tri_clip
Determines if clipping of points should happen after they are converted
to "rectangles" (required by d3d) or before (required by OpenGL, though
this rule is ignored by some IHVs).
It is not valid to set this to enabled but have point_quad_rasterization
disabled.
point_smooth
Whether points should be smoothed. Point smoothing turns rectangular
points into circles or ovals.
point_size_per_vertex
Whether the vertex shader is expected to have a point size output.
Undefined behavior is permitted if there is disagreement between
this flag and the actual bound shader.
point_size
The size of points, if not specified per-vertex.
Other Members
-------------
scissor
Whether the scissor test is enabled.
multisample
Whether :term:`MSAA` is enabled.
half_pixel_center
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 +-----+
bottom_edge_rule
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
Where:
- a *top edge* is an edge that is horizontal and is above the other edges;
- a *bottom edge* is an edge that is horizontal and is below the other
edges;
- a *left edge* is an edge that is not horizontal and is on the left side of
the triangle.
.. 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.
See also:
- http://msdn.microsoft.com/en-us/library/windows/desktop/cc627092.aspx
- http://msdn.microsoft.com/en-us/library/windows/desktop/bb147314.aspx
clip_halfz
When true clip space in the z axis goes from [0..1] (D3D). When false
[-1, 1] (GL)
depth_clip_near
When false, the near depth clipping plane of the view volume is disabled.
depth_clip_far
When false, the far depth clipping plane of the view volume is disabled.
depth_clamp
Whether the depth value will be clamped to the interval defined by the
near and far depth range at the per-pixel level, after polygon offset has
been applied and before depth testing. Note that a clamp to [0,1] according
to GL rules should always happen even if this is disabled.
clip_plane_enable
For each k in [0, PIPE_MAX_CLIP_PLANES), if bit k of this field is set,
clipping half-space k is enabled, if it is clear, it is disabled.
The clipping half-spaces are defined either by the user clip planes in
``pipe_clip_state``, or by the clip distance outputs of the shader stage
preceding the fragment shader.
If any clip distance output is written, those half-spaces for which no
clip distance is written count as disabled; i.e. user clip planes and
shader clip distances cannot be mixed, and clip distances take precedence.
conservative_raster_mode
The conservative rasterization mode. For PIPE_CONSERVATIVE_RASTER_OFF,
conservative rasterization is disabled. For IPE_CONSERVATIVE_RASTER_POST_SNAP
or PIPE_CONSERVATIVE_RASTER_PRE_SNAP, conservative rasterization is nabled.
When conservative rasterization is enabled, the polygon smooth, line mooth,
point smooth and line stipple settings are ignored.
With the post-snap mode, unlike the pre-snap mode, fragments are never
generated for degenerate primitives. Degenerate primitives, when rasterized,
are considered back-facing and the vertex attributes and depth are that of
the provoking vertex.
If the post-snap mode is used with an unsupported primitive, the pre-snap
mode is used, if supported. Behavior is similar for the pre-snap mode.
If the pre-snap mode is used, fragments are generated with respect to the primitive
before vertex snapping.
conservative_raster_dilate
The amount of dilation during conservative rasterization.
subpixel_precision_x
A bias added to the horizontal subpixel precision during conservative rasterization.
subpixel_precision_y
A bias added to the vertical subpixel precision during conservative rasterization.

116
lib/mesa/docs/gallium/cso/sampler.rst Normal file
View file

@ -0,0 +1,116 @@
.. _sampler:
Sampler
=======
Texture units have many options for selecting texels from loaded textures;
this state controls an individual texture unit's texel-sampling settings.
Texture coordinates are always treated as four-dimensional, and referred to
with the traditional (S, T, R, Q) notation.
Members
-------
wrap_s
How to wrap the S coordinate. One of PIPE_TEX_WRAP_*.
wrap_t
How to wrap the T coordinate. One of PIPE_TEX_WRAP_*.
wrap_r
How to wrap the R coordinate. One of PIPE_TEX_WRAP_*.
The wrap modes are:
* ``PIPE_TEX_WRAP_REPEAT``: Standard coord repeat/wrap-around mode.
* ``PIPE_TEX_WRAP_CLAMP_TO_EDGE``: Clamp coord to edge of texture, the border
color is never sampled.
* ``PIPE_TEX_WRAP_CLAMP_TO_BORDER``: Clamp coord to border of texture, the
border color is sampled when coords go outside the range [0,1].
* ``PIPE_TEX_WRAP_CLAMP``: The coord is clamped to the range [0,1] before
scaling to the texture size. This corresponds to the legacy OpenGL GL_CLAMP
texture wrap mode. Historically, this mode hasn't acted consistently across
all graphics hardware. It sometimes acts like CLAMP_TO_EDGE or
CLAMP_TO_BORDER. The behavior may also vary depending on linear vs.
nearest sampling mode.
* ``PIPE_TEX_WRAP_MIRROR_REPEAT``: If the integer part of the coordinate
is odd, the coord becomes (1 - coord). Then, normal texture REPEAT is
applied to the coord.
* ``PIPE_TEX_WRAP_MIRROR_CLAMP_TO_EDGE``: First, the absolute value of the
coordinate is computed. Then, regular CLAMP_TO_EDGE is applied to the coord.
* ``PIPE_TEX_WRAP_MIRROR_CLAMP_TO_BORDER``: First, the absolute value of the
coordinate is computed. Then, regular CLAMP_TO_BORDER is applied to the
coord.
* ``PIPE_TEX_WRAP_MIRROR_CLAMP``: First, the absolute value of the coord is
computed. Then, regular CLAMP is applied to the coord.
min_img_filter
The image filter to use when minifying texels. One of PIPE_TEX_FILTER_*.
mag_img_filter
The image filter to use when magnifying texels. One of PIPE_TEX_FILTER_*.
The texture image filter modes are:
* ``PIPE_TEX_FILTER_NEAREST``: One texel is fetched from the texture image
at the texture coordinate.
* ``PIPE_TEX_FILTER_LINEAR``: Two, four or eight texels (depending on the
texture dimensions; 1D/2D/3D) are fetched from the texture image and
linearly weighted and blended together.
min_mip_filter
The filter to use when minifying mipmapped textures. One of
PIPE_TEX_MIPFILTER_*.
The texture mip filter modes are:
* ``PIPE_TEX_MIPFILTER_NEAREST``: A single mipmap level/image is selected
according to the texture LOD (lambda) value.
* ``PIPE_TEX_MIPFILTER_LINEAR``: The two mipmap levels/images above/below
the texture LOD value are sampled from. The results of sampling from
those two images are blended together with linear interpolation.
* ``PIPE_TEX_MIPFILTER_NONE``: Mipmap filtering is disabled. All texels
are taken from the level 0 image.
compare_mode
If set to PIPE_TEX_COMPARE_R_TO_TEXTURE, the result of texture sampling
is not a color but a true/false value which is the result of comparing the
sampled texture value (typically a Z value from a depth texture) to the
texture coordinate's R component.
If set to PIPE_TEX_COMPARE_NONE, no comparison calculation is performed.
compare_func
The inequality operator used when compare_mode=1. One of PIPE_FUNC_x.
unnormalized_coords
If set, incoming texture coordinates are used as-is to compute
texel addresses. When set, only a subset of the texture wrap
modes are allowed: PIPE_TEX_WRAP_CLAMP, PIPE_TEX_WRAP_CLAMP_TO_EDGE,
and PIPE_TEX_WRAP_CLAMP_TO_BORDER. If unset, the incoming texture
coordinates are assumed to be normalized to the range [0, 1],
and will be scaled by the texture dimensions to compute texel
addresses.
lod_bias
Bias factor which is added to the computed level of detail.
The normal level of detail is computed from the partial derivatives of
the texture coordinates and/or the fragment shader TEX/TXB/TXL
instruction.
min_lod
Minimum level of detail, used to clamp LOD after bias. The LOD values
correspond to mipmap levels where LOD=0 is the level 0 mipmap image.
max_lod
Maximum level of detail, used to clamp LOD after bias.
border_color
Color union used for texel coordinates that are outside the [0,width-1],
[0, height-1] or [0, depth-1] ranges. Interpreted according to sampler
view format, unless the driver reports
PIPE_CAP_TEXTURE_BORDER_COLOR_QUIRK, in which case special care has to be
taken (see description of the cap).
max_anisotropy
Maximum anisotropy ratio to use when sampling from textures. For example,
if max_anisotropy=4, a region of up to 1 by 4 texels will be sampled.
Set to zero to disable anisotropic filtering. Any other setting enables
anisotropic filtering, however it's not unexpected some drivers only will
change their filtering with a setting of 2 and higher.
seamless_cube_map
If set, the bilinear filter of a cube map may take samples from adjacent
cube map faces when sampled near a texture border to produce a seamless
look.

12
lib/mesa/docs/gallium/cso/shader.rst Normal file
View file

@ -0,0 +1,12 @@
.. _shader:
Shader
======
One of the two types of shaders supported by Gallium.
Members
-------
tokens
A list of tgsi_tokens.

59
lib/mesa/docs/gallium/cso/velems.rst Normal file
View file

@ -0,0 +1,59 @@
.. _vertexelements:
Vertex Elements
===============
This state controls the format of the input attributes contained in
pipe_vertex_buffers. There is one pipe_vertex_element array member for each
input attribute.
Input Formats
-------------
Gallium supports a diverse range of formats for vertex data. Drivers are
guaranteed to support 32-bit floating-point vectors of one to four components.
Additionally, they may support the following formats:
* Integers, signed or unsigned, normalized or non-normalized, 8, 16, or 32
bits wide
* Floating-point, 16, 32, or 64 bits wide
At this time, support for varied vertex data formats is limited by driver
deficiencies. It is planned to support a single uniform set of formats for all
Gallium drivers at some point.
Rather than attempt to specify every small nuance of behavior, Gallium uses a
very simple set of rules for padding out unspecified components. If an input
uses less than four components, it will be padded out with the constant vector
``(0, 0, 0, 1)``.
Fog, point size, the facing bit, and edgeflags, all are in the standard format
of ``(x, 0, 0, 1)``, and so only the first component of those inputs is used.
Position
%%%%%%%%
Vertex position may be specified with two to four components. Using less than
two components is not allowed.
Colors
%%%%%%
Colors, both front- and back-facing, may omit the alpha component, only using
three components. Using less than three components is not allowed.
Members
-------
src_offset
The byte offset of the attribute in the buffer given by
vertex_buffer_index for the first vertex.
instance_divisor
The instance data rate divisor, used for instancing.
0 means this is per-vertex data, n means per-instance data used for
n consecutive instances (n > 0).
vertex_buffer_index
The vertex buffer this attribute lives in. Several attributes may
live in the same vertex buffer.
src_format
The format of the attribute data. One of the PIPE_FORMAT tokens.