Merge remote branch 'origin/master' into glsl2

This pulls in multiple i965 driver fixes which will help ensure better
testing coverage during development, and also gets past the conflicts
of the src/mesa/shader -> src/mesa/program move.

Conflicts:
	src/mesa/Makefile
	src/mesa/main/shaderapi.c
	src/mesa/main/shaderobj.h

2 files changed, 98 insertions, 10 deletions

diff --git a/src/gallium/docs/source/cso/blend.rst b/src/gallium/docs/source/cso/blend.rst
index c74396284c..7bde10c124 100644
--- a/src/gallium/docs/source/cso/blend.rst
+++ b/src/gallium/docs/source/cso/blend.rst
@@ -14,21 +14,74 @@ in other modern and legacy drawing APIs.
 
 XXX blurb about dual-source blends
 
+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.
-logicop_enable
-   Enables logic ops. Cannot be enabled at the same time as blending, and
-   is always the same for all render targets.
-logicop_func
-   The logic operation to use if logic ops are enabled. One of PIPE_LOGICOP.
-dither
-   Whether dithering is enabled. Note: Dithering is implementation-dependent.
 rt
    Contains the per-rendertarget blend state.
 
diff --git a/src/gallium/docs/source/cso/velems.rst b/src/gallium/docs/source/cso/velems.rst
index 92cde014fb..978ad4a243 100644
--- a/src/gallium/docs/source/cso/velems.rst
+++ b/src/gallium/docs/source/cso/velems.rst
@@ -3,9 +3,44 @@
 Vertex Elements
 ===============
 
-This state controls format etc. of the input attributes contained
-in the pipe_vertex_buffer(s). There's one pipe_vertex_element array member
-for each input attribute.
+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
 -------