mesa: use void in _mesa_VDPAUFiniNV() as in the header file
mesa: Remove trailing whitespace in texparam.c

Signed-off-by: Rico Schüller <kgbricola@web.de>
Signed-off-by: Brian Paul <brianp@vmware.com>
i965: Do not set bilinear_filter flag in case of multisample blits

Setting bilinear_filter flag in case of multisample blits with
GL_LINEAR filter causes incorrect behavior in translate_dst_to_src()
function. This broke Modern Warfare (1, 2 and 3) on SNB, IVB and HSW.

Tested on SNB and IVB, no Piglit regressions. Trace file of the game
(taken with apitrace) works fine with this patch.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69078
Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reported-by: Armin K <krejzi@email.com>
Tested-by: Armin K <krejzi@email.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
i965: CS writes/reads should use I915_GEM_INSTRUCTION

Otherwise the gen6 w/a in the kernel won't kick in and the write will
land nowhere.

Inspired by a patch Ken pointed me at which had the same issue (but
isn't yet merged and also for a gen7+ feature). An audit of the entire
driver didn't reveal any other case than the one in in the write_reg
helper used by the gen6 queryobj code.

Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Xinkai Chen <yeled.nova@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
i965: Emit post-sync non-zero flush before 3DSTATE_GS_SVB_INDEX.

From the comments above intel_emit_post_sync_nonzero_flush:
"[DevSNB-C+{W/A}] Before any depth stall flush (including those
 produced by non-pipelined state commands), software needs to first
 send a PIPE_CONTROL with no bits set except Post-Sync Operation != 0."

This suggests that every non-pipelined (0x79xx) command needs a
post-sync non-zero flush before it.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Xinkai Chen <yeled.nova@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
i965: Emit post-sync non-zero flush before 3DSTATE_DRAWING_RECTANGLE.

This is another non-pipelined command that needs a flush on Sandybridge.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Xinkai Chen <yeled.nova@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
i965: Also guard 3DSTATE_DRAWING_RECTANGLE with a flush in blorp.

Non-pipelined commands need this flush.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Xinkai Chen <yeled.nova@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
i965: Move post-sync non-zero flush for 3DSTATE_MULTISAMPLE.

For some reason, we put the flush in the caller, rather than just before
emitting the packet.  This is more than a cosmetic problem: BLORP calls
gen6_emit_3dstate_multisample() directly, and so it missed the flush.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Xinkai Chen <yeled.nova@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
i965: Also emit HIER_DEPTH and STENCIL packets when disabling depth.

From the documentation:
"[DevIVB] 3DSTATE_DEPTH_BUFFER must always be programmed along with the
 other Depth/Stencil state commands(i.e. 3DSTATE_CLEAR_PARAMS,
 3DSTATE_STENCIL_BUFFER, or 3DSTATE_HIER_DEPTH_BUFFER)."

We normally do this, but BLORP was failing to do so in the case where it
disables depth.

Not observed to fix anything yet.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Xinkai Chen <yeled.nova@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
i965: Also emit HiZ and Stencil packets when disabling depth on Gen6.

The normal drawing path does this, and it's necessary on Ivybridge,
so let's try it on Sandybridge too.  It's not explicitly documented
as necessary, but might help with hangs.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Xinkai Chen <yeled.nova@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Cc: "9.2" <mesa-stable@lists.freedesktop.org>
Remove error when calling glGenQueries/glDeleteQueries while a query is active

There is nothing in the OpenGL specification which prevents the user from
calling glGenQueries to generate a new query object while another object is
active. Neither is there anything in the Mesa implementation which prevents
this. So remove the INVALID_OPERATION errors in this case.

Similarly, it is explicitly allowed by the OpenGL specification to delete an
active query, so remove the assertion for that case, replacing it with the
necesssary state updates to end the query, (clear the bindpt pointer and call
into the driver's EndQuery hook).

CC: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>
glsl: Move common code out of opt_algebraic's handle_expression().

Matt and I had each screwed up these common required patterns recently, in
ways that wouldn't have been noticed for a long time if not for code
review.  Just enforce it in the caller so that we don't rely on code
review catching these bugs.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
glsl: Use ir_builder more in opt_algebraic.

While ir_builder is slightly less efficient, we're only increasing the
work when there's actual optimization being done, and it's way more
readable code.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
glsl: Drop no-op shifts involving 0.

I noticed this in a shader in Unigine Heaven that was spilling.  While it
doesn't really reduce register pressure, it shaves a few instructions
anyway (7955 -> 7882).

v2: Fix turning "0 >> x" into "x" instead of "0" (caught by Erik
    Faye-Lund).

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
r600g/sb: fix value::is_fixed()

This prevents unnecessary (and wrong) register allocation in the
scheduler for preloaded values in fixed registers.

Fixes interpolation-mixed.shader_test on rv770
(and probably on all other pre-evergreen chips).

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Tested-by: Andreas Boll <andreas.boll.dev@gmail.com>
i965/vec4: Reduce working set size of live variables computation.

Orbital Explorer was generating a 4000 instruction geometry shader, which
was taking 275 trips through dead code elimination and register
coalescing, each of which updated live variables to get its work done, and
invalidated those live variables afterwards.

By using bitfields instead of bools (reducing the working set size by a
factor of 8) in live variables analysis, it drops from 88% of the profile
to 57%, and reduces overall runtime from I-got-bored-and-killed-it (Paul
says 3+ minutes) to 10.5 seconds.

Compare to f179f419d1d0a03fad36c2b0a58e8b853bae6118 on the FS side.

Reviewed-by: Paul Berry <stereotype441@gmail.com>
svga: reindent drawing code
st/mesa: move out of memory check in st_draw_vbo()

Before we were only checking the st->vertex_array_out_of_memory flag
after updating array state.  But if there's two consecutive glDrawArrays
calls and the first one is skipped because of OOM, the second one should
be skipped too.

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

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
util,llvmpipe: correctly set the minimum representable depth value

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
llvmpipe: fix bogus layer clamping in setup

The layer coming from GS needs to be clamped (not sure if that's actually
the correct error behavior but we need something) as the number can be higher
than the amount of layers in the fb. However, this code was using the layer
calculation from the scene, and this was actually calculated in
lp_scene_begin_rasterization() hence too late (so setup was using the value
from the _previous_ scene or just zero if it was the first scene).
Since the value is used in both rasterization and setup, move calculation up
to lp_scene_begin_binning() though it's a bit more inconvenient to calculate
there. (Theoretically could move _all_ code which was in
lp_scene_begin_rasterization() to there, because ever since we got rid of
swizzled render/depth buffers our "map" functions preparing the fb data for
render don't actually change the data in there at all, but it feels like
it would be a hack.)

v2: improve comments

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Jose Fonseca <jfonseca@vmware.com>