i965: Remove *_generator::shader field; use prog field instead.

The "shader" field in fs_generator, vec4_generator, and gen8_generator
was only used for one purpose; to figure out if we were compiling an
assembly program or a GLSL shader (shader is NULL for assembly
programs).  And it wasn't being used properly: in vec4 shaders we were
always initializing it based on
prog->_LinkedShaders[MESA_SHADER_FRAGMENT], regardless of whether we
were compiling a geometry shader or a vertex shader.

This patch simplifies things by using the "prog" field instead; this
is also NULL for assembly programs.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa: Ensure that transform feedback refers to the correct program.

Previous to this patch, the _mesa_{Begin,Resume}TransformFeedback
functions were using ctx->Shader.CurrentProgram[MESA_SHADER_VERTEX] to
find the program that would be the source of transform feedback data.
This isn't correct--if there's a geometry shader present it should be
ctx->Shader.CurrentProgram[MESA_SHADER_GEOMETRY].  (These might be
different if separate shader objects are in use).

This patch creates a function get_xfb_source(), which figures out the
correct program to use based on GL state, and updates
_mesa_{Begin,Resume}TransformFeedback to call it.  get_xfb_source() is
written in terms of the gl_shader_stage enum, so it should not need
modification when we add tessellation shaders in the future.  It also
creates a new driver flag, NewTransformFeedbackProg, which is flagged
whenever this program changes.

To reduce future confusion, this patch also rewords some comments and
error message text to avoid referring to vertex shaders.

Cc: 10.0 <mesa-stable@lists.freedesktop.org>

v2: make the for loop in get_xfb_source() clearer.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/gen7: Use to the correct program when uploading transform feedback state.

Transform feedback may come from either the geometry shader or the
vertex shader, so we can't use
ctx->Shader.CurrentProgram[MESA_SHADER_VERTEX] to find the current
post-link transform feedback information.  Fortunately we can use
ctx->TransformFeedback.CurrentObject->shader_program.

Cc: 10.0 <mesa-stable@lists.freedesktop.org>

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
st/mesa: add a simple sanity check assertion in st_validate_attachment()

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
svga: rename "tex_usage" to "bindings", add comments

Trivial.
mesa: Increment the list pointer while freeing instruction data

Since the list pointer was never incremented when a OPCODE_PIXEL_MAP
opcode was encountered, the data for the instruction would get freed
over and over and over... resulting in a crash.

Fixes gl-1.0-beginend-coverage.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72214
Reviewed-by: Brian Paul <brianp@vmware.com>
Cc: Lu Ha <huax.lu@intel.com>
Update .gitignore for Catalan translations build artifacts

Causes git to ignore the new build artifacts introduced by commit
d5e5367e8992c2e5322d35fba8d86c33a0db6825 (driconf: Add Catalan
translations).
glsl: Rename "expr" to "lhs_expr" in vector_extract munging code.

When processing assignments, we have both an LHS and RHS.  At a glance,
"lhs_expr" clearly refers to the LHS, while a generic name like "expr"
is ambiguous.

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Fix chained assignments of vector channels.

Simple shaders such as:

    void splat(vec2 v, float f) {
        v[0] = v[1] = f;
    }

failed to compile with the following error:
error: value of type vec2 cannot be assigned to variable of type float

First, we would process v[1] = f, and transform:
LHS: (expression float vector_extract (var_ref v) (constant int (1)))
RHS: (var_ref f)
into:
LHS: (var_ref v)
RHS: (expression vec2 vector_insert (var_ref v) (constant int (1))
                 (var_ref f))

Note that the LHS type is now vec2, not a float.  This is surprising,
but not the real problem.

After emitting assignments, this ultimately becomes:
(declare (temporary) vec2 assignment_tmp)
(assign (xy)
  (var_ref assignment_tmp)
  (expression vec2 vector_insert (var_ref v) (constant int (1))
              (var_ref f)))
  (assign (xy) (var_ref v) (var_ref assignment_tmp))

We would then return (var_ref assignment_tmp) as the rvalue, which has
the wrong type---it should be float, but is instead a vec2.

To fix this, we simply return (vector_extract (var_ref assignment_temp)
<the appropriate channel>) to pull out the desired float value.

Fixes Piglit's chained-assignment-with-vector-constant-index.vert and
chained-assignment-with-vector-dynamic-index.vert tests.

Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74026
Reported-by: Dan Ginsburg <dang@valvesoftware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Simplify built-in generator functions for min3/max3/mid3.

The type of all three parameters are identical, so we don't need to
specify it three times.  The predicate is always identical too, so we
don't need to make it a parameter, either.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>