i965: Fix cube array coordinate normalization

Hardware requires the magnitude of the largest component to not exceed
1; brw_cubemap_normalize ensures that this is the case.

Unfortunately, we would previously multiply the array index for cube
arrays by the normalization factor. The incorrect array index would then
cause the sampler to attempt to access either the wrong cube, or memory
outside the cube surface entirely, resulting in garbage rendering or in
the worst case, hangs.

Alter the normalization pass to only multiply the .xyz components.

Fixes broken rendering in the arb_texture_cube_map_array-cubemap piglit,
which was recently adjusted to provoke this behavior.

V2: Fix indent.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Cc: "9.2" mesa-stable@lists.freedesktop.org
Reviewed-by: Eric Anholt <eric@anholt.net>
mesa: Remove some remaining FEATURE_* detritus.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa: Remove 'invalidate_state' parameter to _mesa_dirty_texobj().

Every caller passed true.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
glsl: Create and use a has_explicit_attrib_location() helper.

Explicit attribute locations are supported with GLSL 3.30, GLSL ES 3.00,
or "#extension GL_ARB_explicit_attrib_location: enable".  Using a helper
function makes it easy to check for this.

This enables support in GLSL 3.30, which was previously missing.

Previously, we overrode the extension enable flag for ES 3.00.  This is
not robust against a shader such as:

   #version 330
   #extension GL_ARB_explicit_attrib_location : disable

Disabling extensions should not remove core language functionality.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Create and use a has_uniform_buffer_objects() helper.

This is better than overriding the extension enable based on the
language version; it's robust against shaders that do:

   #version 140
   #extension GL_ARB_uniform_buffer_object : disable

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
mesa: Add core support for the GL_AMD_performance_monitor extension.

This provides an interface for applications (and OpenGL-based tools) to
access GPU performance counters.  Since the exact performance counters
available vary between vendors and hardware generations, the extension
provides an API the application can use to get the names, types, and
minimum/maximum values of all available counters.  Counters are also
organized into groups.

Applications create "performance monitor" objects, select the counters
they want to track, and Begin/End monitoring, much like OpenGL's query
API.  Multiple monitors can be in flight simultaneously.

v2: Pass ctx to all driver hooks (suggested by Christoph), and attempt
    to fix overallocation of bitsets (caught by Christoph).  Incomplete.

v3: Significantly rework core data structures.  Store counters in groups
    rather than in a global list.  Use their array index in the group's
    counter list as the ID rather than trying to store a globally unique
    counter ID.  Use bitsets for active counters within a group, and
    also track which groups are active so that's easy to query.

v4: Remove _mesa_ prefix on static functions; detect out of memory
    conditions in new_performance_monitor(); make BeginPerfMonitor hook
    return a boolean rather than setting m->Active or raising an error.
    Switch to GLuint/unsigned for NumGroups, NumCounters, and
    MaxActiveCounters (which also means switching a bunch of temporary
    variable types).  All suggested by Brian Paul.  Also, remove
    commented out code at the bottom of the block.  Finally, fix the
    dispatch sanity test (noticed by Ian Romanick).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com> [v3]
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965: Add support for GL_AMD_performance_monitor on Ironlake.

Ironlake's counters are always enabled; userspace can simply send a
MI_REPORT_PERF_COUNT packet to take a snapshot of them.  This makes it
easy to implement.

The counters are documented in the source code for the intel-gpu-tools
intel_perf_counters utility.

v2: Adjust for core data structure changes.  Add a table mapping buffer
    object offsets to exposed counters (which changes each generation).
    Finally, add report ID assertions to sanity check the BO layout
    (thanks to Carl Worth).

v3: Update for core BeginPerfMonitor hook changes (requested by Brian).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965: Add #define for MI_REPORT_PERF_COUNT on Gen6+.

This appears in Volume 1 Part 1 of the Sandybridge PRM on page 48.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
i965/fs: Don't double-accept operands of logical and/or/xor operations.

If the argument to emit_bool_to_cond_code() is an ir_expression, we
loop over the operands, calling accept() on each of them, which
generates assembly code to compute that subexpression.  We then emit
one or two final instruction that perform the top-level operation on
those operands.

If it's not an expression (say, a boolean-valued variable), we simply
call accept() on the whole value.

In commit 80ecb8f1 (i965/fs: Avoid generating extra AND instructions on
bool logic ops), Eric made logic operations jump out of the expression
path to the non-expression path.

Unfortunately, this meant that we would first accept() the two operands,
skip generating any code that used them, then accept() the whole
expression, generating code for the operands a second time.

Dead code elimination would always remove the first set of redundant
operand assembly, since nothing actually used them.  But we shouldn't
generate it in the first place.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>