docs: Import 9.2.4 release notes, add news item.
trace: Dump query results faithfully.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
trace: Dump PIPE_QUERY_* enums.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
mesa: have old glColorTable functions generate GL_INVALID_OPERATION

As is done for the old histogram functions.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
mesa: have old convolution functions generate GL_INVALID_OPERATION

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
mesa: remove old colortable, histogram, etc. code from dlist.c

Trying to compile any of these functions into a display list
now just generates a GL_INVALID_OPERATION error.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
mesa: fix flags assignment in save_WaitSync()

The flags value is a bitfield so use the union's 'bf' field, not 'e'
(enum) field.  There's no actual change in behavior here since both
fields of the union are the same size.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
mesa: added memory-related comment in save_error()

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
mesa: fix mem leak of glPixelMap data in display list

And simplify save_PixelMapfv() by using the memdup() function.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Teach ir_variable_refcount about ir_loop::counter variables.

If an ir_loop has a non-null "counter" field, the variable referred to
by this field is implicitly read and written by the loop.  We need to
account for this in ir_variable_refcount, otherwise there is a danger
we will try to dead-code-eliminate the loop counter variable.

Note: at the moment the dead code elimination bug doesn't occur due to
a bug in ir_hierarchical_visitor: it doesn't visit the "counter"
field, so dead code elimination doesn't treat it as a candidate for
elimination.  But the patch to follow will fix that bug, so we need to
fix ir_variable_refcount first in order to avoid breaking dead code
elimination.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Fix inconsistent assumptions about ir_loop::counter.

The compiler back-ends (i965's fs_visitor and brw_visitor,
ir_to_mesa_visitor, and glsl_to_tgsi_visitor) assume that when
ir_loop::counter is non-null, it points to a fresh ir_variable that
should be used as the loop counter (as opposed to an ir_variable that
exists elsewhere in the instruction stream).

However, previous to this patch:

(1) loop_control_visitor did not create a new variable for
    ir_loop::counter; instead it re-used the existing ir_variable.
    This caused the loop counter to be double-incremented (once
    explicitly by the body of the loop, and once implicitly by
    ir_loop::increment).

(2) ir_clone did not clone ir_loop::counter properly, resulting in the
    cloned ir_loop pointing to the source ir_loop's counter.

(3) ir_hierarchical_visitor did not visit ir_loop::counter, resulting
    in the ir_variable being missed by reparenting.

Additionally, most optimization passes (e.g. loop unrolling) assume
that the variable mentioned by ir_loop::counter is not accessed in the
body of the loop (an assumption which (1) violates).

The combination of these factors caused a perfect storm in which the
code worked properly nearly all of the time: for loops that got
unrolled, (1) would introduce a double-increment, but loop unrolling
would fail to notice it (since it assumes that ir_loop::counter is not
accessed in the body of the loop), so it would unroll the loop the
correct number of times.  For loops that didn't get unrolled, (1)
would introduce a double-increment, but then later when the IR was
cloned for linking, (2) would prevent the loop counter from being
cloned properly, so it would look to further analysis stages like an
independent variable (and hence the double-increment would stop
occurring).  At the end of linking, (3) would prevent the loop counter
from being reparented, so it would still belong to the shader object
rather than the linked program object.  Provided that the client
program didn't delete the shader object, the memory would never get
reclaimed, and so the shader would function properly.

However, for loops that didn't get unrolled, if the client program did
delete the shader object, and the memory belonging to the loop counter
got re-used, this could cause a use-after-free bug, leading to a
crash.

This patch fixes loop_control_visitor, ir_clone, and
ir_hierarchical_visitor to treat ir_loop::counter the same way the
back-ends treat it: as a freshly allocated ir_variable that needs to
be visited and cloned independently of other ir_variables.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72026

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: In ir_validate, check that ir_loop::counter always refers to a new var.

The compiler back-ends (i965's fs_visitor and brw_visitor,
ir_to_mesa_visitor, and glsl_to_tgsi_visitor) have been assuming this
for some time.  Thanks to the preceding patch, the compiler front-end
no longer breaks this assumption.

This patch adds code to validate the assumption so that if we have
future bugs, we'll be able to catch them earlier.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Improve documentation of ir_loop counter/control fields.

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Remove unused field loop_variable_state::loop.

This field was neither initialized nor used.  It was just dead memory.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/gen6: Fix multisample resolve blits for luminance/intensity 32F formats.

On gen6, multisamble resolve blits use the SAMPLE message to blend
together the 4 samples for each texel.  For some reason, SAMPLE
doesn't blend together the proper samples when the source format is
L32_FLOAT or I32_FLOAT, resulting in blocky artifacts.

To work around this problem, sample from the source surface using
R32_FLOAT.  This shouldn't affect rendering correctness, because when
doing these resolve blits, the destination format is R32_FLOAT, so the
channel replication done by L32_FLOAT and I32_FLOAT is unnecessary.

Fixes piglit tests on Sandy Bridge:
- spec/ARB_texture_float/multisample-formats 2 GL_ARB_texture_float
- spec/ARB_texture_float/multisample-formats 4 GL_ARB_texture_float

No piglit regressions on Sandy Bridge.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70601

Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
docs: Import 10.0 release notes, add news item

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Fix 'make check' in src/mapi/glapi/tests when builddir != srcdir

make[5]: Entering directory `/jhbuild/build/mesa/mesa/src/mapi/glapi/tests'
  CXX      check_table.o
/jhbuild/checkout/mesa/mesa/src/mapi/glapi/tests/check_table.cpp:29:30: fatal error: glapi/glapitable.h: No such file or directory

We should look for the generated file glapi/glapitable.h in builddir, not srcdir

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
glsl: Remove useless iteration through function parameters.

There's no need to loop through the "parameters" list and remove every
element; move_nodes_to(&parameters) already throws away all elements of
the destination list.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Drop unused call_ir parameter from generate_call().

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Merge "candidates are: " message to the previous line.

Previously, when we hit a "no matching function" error, it looked like:

0:0(0): error: no matching function for call to `cos()'
0:0(0): error: candidates are: float cos(float)
0:0(0): error:                vec2 cos(vec2)
0:0(0): error:                vec3 cos(vec3)
0:0(0): error:                vec4 cos(vec4)

Now it looks like:

0:0(0): error: no matching function for call to `cos()'; candidates are:
0:0(0): error:    float cos(float)
0:0(0): error:    vec2 cos(vec2)
0:0(0): error:    vec3 cos(vec3)
0:0(0): error:    vec4 cos(vec4)

This is not really any worse and removes the need for the prefix variable.
It will also help with the next commit's refactoring.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>