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>
glsl: Generalize MSVC fix for strcasecmp().

This will let us use strcasecmp() from anywhere inside Mesa without
having to worry about the fact that it doesn't exist in MSVC.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
mesa: Define introspection macro to determine whether a type is trivially destructible.

Only implemented on GCC and Clang for now.  Other compilers use a
dummy implementation that always returns false, which should be a safe
[but slightly inefficient] assumption in all cases.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
ralloc: Hook up C++ destructors to ralloc when necessary.

This patch makes sure that class destructors are called as they should
be when a C++ object allocated by ralloc is released.

Based on a previous patch by Kenneth Graunke, but it doesn't exhibit
the ~0.8% performance regression in shader compilation times because
we now use the HAS_TRIVIAL_DESTRUCTOR() macro to detect the typical
case where the indirect function call can be avoided because the
object's destructor doesn't need to do anything.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965: Handle deallocation of some private ralloc contexts explicitly.

These ralloc contexts belong to a specific object and are being
deallocated manually from the class destructor.  Now that we've hooked
up destructors to ralloc there's no reason for them to be children of
any other context, and doing so might to lead to double frees under
some circumstances.  The class destructor has all the responsibility
of freeing class memory resources now.
glapi: Add support for ARB_shader_atomic_counters.

Add XML file for the dispatch code generator, update the
dispatch_sanity test and add stub definition for the new entry point.

Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
mesa: Add support for ARB_shader_atomic_counters.

This patch implements the common support code required for the
ARB_shader_atomic_counters extension.  It defines the necessary data
structures for tracking atomic counter buffer objects (from now on
"ABOs") associated with some specific context or shader program, it
implements support for binding buffers to an ABO binding point and
querying the existing atomic counters and buffers declared by GLSL
shaders.

v2: Fix extension checks.  Drop unused MAX_ATOMIC_BUFFERS constant.

Acked-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Add extension enables for ARB_shader_atomic_counters.

Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Add new atomic_uint built-in GLSL type.

v2: Fix GLSL version in which the type became available.  Add
    contains_atomic() convenience method.  Split off atomic counter
    comparison error checking to a separate patch that will handle all
    opaque types.  Include new ir_variable fields for atomic types.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Add type predicate to check whether a type contains any opaque types.

And use it to forbid comparisons of opaque operands.  According to the
GL 4.2 specification:

> Except for array indexing, structure member selection, and
> parentheses, opaque variables are not allowed to be operands in
> expressions.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Basic support for built-in intrinsics.

Fix the linker to deal with intrinsic functions which are undefined
all the way down to the driver back-end, and introduce intrinsic
definition helpers in the built-in generator.

We still need to figure out what kind of interface we want for drivers
to communicate to the GLSL front-end which of the supported intrinsics
should use a default GLSL implementation and which should use a
hardware-specific override.  As there's no default GLSL implementation
for atomic ops, this seems like something we can worry about later on.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

v2: Define local helper function to generate ir_call nodes in the
    builtin generator.