mesa: remove Driver.ResizeBuffers

Nothing overrides it.

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: remove Driver.DeleteShaderProgram

Nothing overrides it.

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: remove Driver.NewShaderProgram

Nothing overrides it.

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: remove Driver.DeleteShader

Nothing overrides it.

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

egl/dri2: don't require a context for ClientWaitSync (v2)

The spec doesn't require it. This fixes a crash on Android.

v2: don't set any flags if ctx == NULL
v3: add the spec note

Cc: 10.6 11.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Albert Freeman <albertwdfreeman@gmail.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>

st/dri: don't use _ctx in client_wait_sync

Not needed and it can be NULL.

v2: fix dri2_get_fence_from_cl_event - thanks Albert

Cc: 10.6 11.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Albert Freeman <albertwdfreeman@gmail.com>

r600g: only do depth-only or stencil-only in-place decompression

instead of always doing both.
Usually, only depth is needed, so stencil decompression is useless.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: only do depth-only or stencil-only in-place decompression

instead of always doing both.
Usually, only depth is needed, so stencil decompression is useless.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

gallium/radeon: add separate stencil level dirty flags

We will only do depth-only or stencil-only decompress blits, whichever is
needed by textures, instead of always doing both.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: dump buffer lists while debugging

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

winsys/radeon: implement cs_get_buffer_list

This is more complicated, because tracking priority_usage needed changing
the relocs_bo type.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

winsys/amdgpu: add winsys function cs_get_buffer_list

For debugging.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

gallium/radeon: stop using "reloc" in a few places

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

gallium/radeon: tell the winsys the exact resource binding types

Use the priority flags and expand them.
This information will be used for debugging.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: add an option for debugging VM faults

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

radeonsi: move dumping the last IB into its own function

v2: indentation fix

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

ddebug: separate creation of debug files

This will be used by radeonsi for logging.

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

docs: add news item and link release notes for 10.6.9

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

docs: add sha256 checksums for 10.6.9

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 8957b696f9cc8a92b2c160c551c34545447ec28a)

docs: add release notes for 10.6.9

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit ab9aacce2d26a802bac81fc25748320428996692)

egl: rework handling EGL_CONTEXT_FLAGS

As of version 15 of the EGL_KHR_create_context spec, debug contexts
are allowed for ES contexts.  We should allow creation instead of
erroring.

While we're here provide a more comprehensive checking for the other two
flags - ROBUST_ACCESS_BIT_KHR and FORWARD_COMPATIBLE_BIT_KHR

v2 [Emil Velikov] Rebase. Minor tweak in commit message.

Cc: Boyan Ding <boyan.j.ding@gmail.com>
Cc: Chad Versace <chad.versace@intel.com>
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91044
Signed-off-by: Matthew Waters <ystreet00@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>

i965/wm: Make compute_barycentric_interp_modes take a nir_shader and a devinfo

Now that everything comes in through NIR, we can pick this directly out of
the shader source and don't need to reference the gl_fragment_program.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: Use nir_foreach_variable

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

nir: Add a nir_foreach_variable macro

This is a common enough operation that it's nice to not have to think about
the arguments to foreach_list_typed every time.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/nir: Remove the prog parameter from brw_nir_lower_inputs

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

radeon/llvm: Initialize gallivm targets when initializing the AMDGPU target v2

This fixes a race condition in the glx-multithreaded-shader-compile
test.

v2:
  - Replace gallivm_init_llvm_{begin,end}() with gallivm_init_llvm_targets().

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

gallivm: Allow drivers and state trackers to initialize gallivm LLVM targets v2

Drivers and state trackers that use LLVM for generating code, must
register the targets they use with LLVM's global TargetRegistry.
The TargetRegistry is not thread-safe, so all targets must be added
to the registry before it can be queried for target information.

When drivers and state trackers initialize their own targets, they need
a way to force gallivm to initialize its targets at the same time.
Otherwise, there can be a race condition in some multi-threaded
applications (e.g. glx-multihreaded-shader-compile in piglit),
when one thread creates a context for a driver that uses LLVM (e.g.
radeonsi) and another thread creates a gallivm context (glxContextCreate
does this).

The race happens when the driver thread initializes its LLVM targets and
then starts using the registry before the gallivm thread has a chance to
register its targets.

This patch allows users to force gallivm to register its targets by
calling the gallivm_init_llvm_targets() function.

v2:
  - Use call_once and remove mutexes and static initializations.
  - Replace gallivm_init_llvm_{begin,end}() with
    gallivm_init_llvm_targets().

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

gallium/radeon: Use call_once() when initailizing LLVM targets

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

i965/shader: Get rid of the shader, prog, and shader_prog fields

Unfortunately, we can't get rid of them entirely.  The FS backend still
needs gl_program for handling TEXTURE_RECTANGLE.  The GS vec4 backend still
needs gl_shader_program for handling transfom feedback.  However, the VS
needs neither and we can substantially reduce the amount they are used.
One day we will be free from their tyranny.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/fs,vec4: Get rid of the sanity_param_count

It doesn't exist for anything other than an assert that, as far as I can
tell, isn't possible to trip.  Soon, we will remove prog from the visitor
entirely and this will become even more impossible to hit.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/vec4: Use nir info instead of pulling things out of [shader_]prog

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/fs: Use the nir info instead of pulling things out of [shader_]prog

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/fs: Move sampler unit lookup into rescale_texcoord

The texunit variable we create and assign in nir_emit_texture gets passed
through two more layers of function calls before it gets to its sole use in
rescale_texcoord.  The best part is that we already pass the sampler into
rescale_texcoord so we can just look it up there.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/cs: Remove the prog argument from local_id_payload_dwords

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/backend_shader: Add a field to store the NIR shader

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

nir: Move GS data to nir_shader_info

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

nir: Add a a nir_shader_info struct

This commit also adds code to glsl_to_nir and prog_to_nir to fill it out.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

nir/glsl: Take a gl_shader_program and a stage rather than a gl_shader

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: Move prog_data uniform setup to the codegen level

As of now, uniform setup is more-or-less unified between vec4 and fs and no
longer requires the fs_visitor.  This makes uniform setup more of a
language/API thing than a backend compiler thing.  This commit moves
setting up the stage_prog_data.params arrays to the same place as we set up
the rest of stage_prog_data.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: Move binding table setup to codegen time.

Setting up binding tables really has little to do with the actual process
of turning shaders into instructions; it's more part of setting up
prog_data.  This commit moves it out of the visitors and with the rest of
the prog_data setup stuff.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/shader: Pull assign_common_binding_table_offsets out of backend_shader

This really has nothing to do with the backend compiler and we'd like to
eventually be able to set this up earlier in the compile process.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/nir: Simplify uniform setup

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

i965/nir: Pull GLSL uniform handling into a common function

The way we deal with GLSL uniforms and builtins is basically the same in
both the vec4 and the fs backend.  This commit takes the best parts of both
implementations and pulls the common code into a shared helper function.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

i965/nir: Pull common ARB program uniform handling into a common function

The way we deal with ARB program uniforms is basically the same in both the
vec4 and the fs backend.  This commit takes the best parts of both
implementations and pulls the common code into a shared helper function.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

i965/vec4: Use the uniform count from nir_assign_var_locations

Previously, we were counting up uniforms as we set them up.  However, this
count should be exactly identical to shader->num_uniforms provided by
nir_assign_var_locations.  (If it's not, we're in trouble anyway because
that means that locations don't match up.)  This matches what the fs
backend is already doing.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

i965/shader: Get rid of the setup_vec4_uniform_value helper

It's not used by anything anymore

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

i965/shader: Pull setup_image_uniform_values out of backend_shader

I tried to do this once before but Curro pointed out that having it in
backend_shader meant it could use the setup_vec4_uniform_values helper
which did different things in vec4 and fs.  Now the setup_uniform_values
function differs only by an assert in the two backends so there's no real
good reason to be using it anymore.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

i965/vec4: Get rid of the uniform_vector_size array

The uniform_vector_size array was only ever used by pack_uniform_registers
which no longer needs it.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

i965/vec4: Use the actual channels used in pack_uniform_registers

Previously, pack_uniform_registers worked based on the size of the uniform
as given to us when we initially set up the uniforms.  However, we have to
walk through the uniforms and figure out liveness anyway, so we migh as
well record the number of channels used as we go.  This may also allow us
to pack things tighter in a few cases.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

glsl/types: Make subroutine types have a single matrix column

That way, if we do the usual thing of multiplying vector_elements by
matrix_columns we get the actual number of components in the type as per
component_slots().

While we're at it, we also switch to using the actual C++ field
initializers for vector_elements and matrix_columns.

Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

i965: Pull stage_prog_data.nr_params out of the NIR shader

Previously, we had a bunch of code in each stage to figure out how many
slots we needed in stage_prog_data.param.  This code was mostly identical
across the stages and had been copied and pasted around.  Unfortunately,
this meant that any time you did something special, you had to add code for
it to each of these places.  In particular, none of the stages took
subroutines into account; they were working entirely by accident.  By
taking this data from the NIR shader, we know the exact number of entries
we need and everything goes a bit smoother.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

i965/vs: Move lazy NIR creation to codegen_vs_prog

The next commit will add code to codegen_vs_prog that requires the NIR
shader to be there in all cases.  It doesn't hurt anything to just move it
from brw_vs_emit to its only caller.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

i965/vec4: Delete the old vec4_vp code

Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/vec4: Delete the old ir_visitor code

Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/vec4: Always use NIR

GLSL IR vs. NIR shader-db results for vec4 programs on i965:

   total instructions in shared programs: 1499328 -> 1388354 (-7.40%)
   instructions in affected programs:     1245199 -> 1134225 (-8.91%)
   helped:                                7469
   HURT:                                  2440

GLSL IR vs. NIR shader-db results for vec4 programs on G4x:

   total instructions in shared programs: 1436799 -> 1325825 (-7.72%)
   instructions in affected programs:     1205599 -> 1094625 (-9.20%)
   helped:                                7469
   HURT:                                  2440

GLSL IR vs. NIR shader-db results for vec4 programs on Iron Lake:

   total instructions in shared programs: 1436654 -> 1325682 (-7.72%)
   instructions in affected programs:     1205503 -> 1094531 (-9.21%)
   helped:                                7468
   HURT:                                  2440

GLSL IR vs. NIR shader-db results for vec4 programs on Sandy Bridge:

   total instructions in shared programs: 2016249 -> 1787033 (-11.37%)
   instructions in affected programs:     1850547 -> 1621331 (-12.39%)
   helped:                                14856
   HURT:                                  1481

GLSL IR vs. NIR shader-db results for vec4 programs on Ivy Bridge:

   total instructions in shared programs: 1848027 -> 1648216 (-10.81%)
   instructions in affected programs:     1660279 -> 1460468 (-12.03%)
   helped:                                14668
   HURT:                                  1369

GLSL IR vs. NIR shader-db results for vec4 programs on Bay Trail:

   total instructions in shared programs: 1848027 -> 1648216 (-10.81%)
   instructions in affected programs:     1660279 -> 1460468 (-12.03%)
   helped:                                14668
   HURT:                                  1369

GLSL IR vs. NIR shader-db results for vec4 programs on Haswell:

   total instructions in shared programs: 1848027 -> 1648216 (-10.81%)
   instructions in affected programs:     1660279 -> 1460468 (-12.03%)
   helped:                                14668
   HURT:                                  1369

I also ran our full suite of benchmarks on a Haswell and had the following
statistically significant (according to ministat) changes:

   Test                        master-glsl     master-nir     diff
   bench_OglGeomPoint          461.556         463.006        1.450
   bench_OglTerrainFlyInst     184.484         187.574        3.090
   bench_OglTerrainPanInst     132.412         136.307        3.895
   bench_OglTexFilterAniso     19.653          19.645         -0.008
   bench_OglTexFilterTri       58.333          58.009         -0.324
   bench_OglVSInstancing       65.049          65.327         0.278
   bench_trexoff               69.474          69.694         0.220
   bench_valley                40.708          41.125         0.417

v2 (Jason Ekstrand):
 - Remove more uses of NirOptions as a switch
 - New shader-db numbers
 - Added benchmark numbers

Reviewed-by: Matt Turner <mattst88@gmail.com>

i965: don't forget to free image_param on prog_data free

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

glsl: avoid leaking hiddenUniforms map when there are no uniforms

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

mesa: avoid leaking closure when iterating over a string_to_uint_map

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

nir: Fix uninitialized 'progress' variable in nir_lower_system_values.

Commit 0a1adaf11d051b71b4c46aabee2e5342f2d6aef3 (nir: Report progress
from nir_lower_system_values().) introduced a bug caught by Valgrind:

==823== Conditional jump or move depends on uninitialised value(s)
==823==    at 0xB09020C: convert_block (nir_lower_system_values.c:68)
==823==    by 0xB079FB8: foreach_cf_node (nir.c:1310)
==823==    by 0xB07A0AF: nir_foreach_block (nir.c:1336)
==823==    by 0xB09026B: convert_impl (nir_lower_system_values.c:79)
...
==823==  Uninitialised value was created by a stack allocation
==823==    at 0xB090249: convert_impl (nir_lower_system_values.c:76)

which is trivially fixed by initializing progress.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

nir/remove_phis: handle trivial back-edges

Some loops may have phi nodes that look like:

foo = ...
loop {
    bar = phi(foo, bar)
    ...
}

in which case we can remove the phi node and replace all uses of 'bar'
with 'foo'. In particular, there are some L4D2 vertex shaders with loops
that, after optimization, look like:

        /* succs: block_1 */
        loop {
                block block_1:
                /* preds: block_0 block_4 */
                vec1 ssa_2195 = phi block_0: ssa_2136, block_4: ssa_994
                vec1 ssa_7321 = phi block_0: ssa_8195, block_4: ssa_7321
                vec1 ssa_7324 = phi block_0: ssa_8198, block_4: ssa_7324
                vec1 ssa_7327 = phi block_0: ssa_8174, block_4: ssa_7327
                vec1 ssa_8139 = intrinsic load_uniform () () (232)
                vec1 ssa_588 = ige ssa_2195, ssa_8139
                /* succs: block_2 block_3 */
                if ssa_588 {
                        block block_2:
                        /* preds: block_1 */
                        break
                        /* succs: block_5 */
                } else {
                        block block_3:
                        /* preds: block_1 */
                        /* succs: block_4 */
                }
                block block_4:
                /* preds: block_3 */
                vec1 ssa_994 = iadd ssa_2195, ssa_2150
                /* succs: block_1 */
        }

where after removing the second, third, and fourth phi nodes, the loop becomes
entirely dead, and this patch will cause the loop to be deleted entirely.

No piglit regressions.

Shader-db results on bdw:

instructions in affected programs:     5824 -> 5664 (-2.75%)
total loops in shared programs:        2234 -> 2202 (-1.43%)
helped:                                32

Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>

glx: Don't hard-code the name "libGL.so.1" in driOpenDriver (v3)

Add a macro GL_LIB_NAME to hold the filename that configure comes up with
based on the --with-gl-lib-name and --enable-mangling options.

In driOpenDriver, use the GL_LIB_NAME macro instead of hard-coding
"libGL.so.1".

v2: Add an #ifndef/#define for GL_LIB_NAME so that non-autoconf builds will
    work.
v3: Fix the library filename in the Makefile.

Signed-off-by: Kyle Brenneman <kbrenneman@nvidia.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

mapi: Make _glapi_get_stub work with "gl" or "mgl" prefix.

When USE_MGL_NAMESPACE is defined, _glapi_get_stub will check for the "m"
prefix before trying to skip it, so that "glFoo" and "mglFoo" are
equivalent.

This should let it work with all the places where something calls
_glapi_get_proc_offset with a hard-coded name that starts with the normal
"gl" prefix.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55552
Signed-off-by: Kyle Brenneman <kbrenneman@nvidia.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

glx: Fix build errors with --enable-mangling (v2)

Rearranged the GLX_ALIAS macro in glextensions.h so that it will pick up
the renames from glx_mangle.h.

Fixed the alias attribute for glXGetProcAddress when USE_MGL_NAMESPACE is
defined.

v2: Add a comment clarifying why GLX_ALIAS needs two macros.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55552
Signed-off-by: Kyle Brenneman <kbrenneman@nvidia.com>
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>

glsl: validate binding qualifier on block members

Fixes following Piglit test:
member-invalid-binding-qualifier.frag

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>

glsl: emit row_major matrix's SSBO stores only for components in writemask

When writing to a column of a row-major matrix, each component of the
vector is stored to non-consecutive memory addresses, so we generate
one instruction per component.

This patch skips the disabled components in the writemask, saving some
store instructions plus avoid storing wrong data on each disabled
component.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

glsl: error out if non-constant indexing of SSBO arrays with GLSL ES

Fixes a failing subtest in:
ES31-CTS.shader_storage_buffer_object.negative-glsl-compileTime

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>

mesa: Add abs input modifier to base for POW in ffvertex_prog

The result of POW for a negative base is undefined. Even when the result
is multiplied by zero (which is the case here whenever the base is
negative), the Inf and NaNs can propagate past that.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91342
Signed-off-by: Daniel Scharrer <daniel@constexpr.org>
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>

i965/fs: Print reg and reg_offset separately for ATTR files.

Reading this output was really confusing.  reg represents attribute
slots; reg_offset is the x/y/z/w component (0..3) within a vec4 slot.

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

i965/nir: Refactor input/output lowering setup into helpers.

The code for input lowering is going to get significantly more
complicated shortly, so I wanted to pull it out.  Vertex shader inputs
are handled nearly identically regardless of vec4/scalar mode, so I
opted to not split that.

I thought about having each function actually do the lowering, but one
pass through nir_lower_io that handles all types (which weren't handled
earlier) is probably more efficient.

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

nir: Allow nir_lower_io() to only lower one type of variable.

We may want to use different type_size functions for (e.g.) inputs
vs. uniforms.  Passing in -1 for mode ignores this, handling all
modes as before.

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

mesa: fix incorrect error in _mesa_BindTextureUnit()

If the texture object exists, but the Name field is zero, it means
the object was created but never bound to a target.  Trying to bind it
in _mesa_BindTextureUnit() should generate GL_INVALID_OPERATION.

Fixes piglit's arb_direct_state_access-bind-texture-unit test.

Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

mesa: remove _mesa_get_tex_unit_err() and fix error handling

This helper was only called from _mesa_BindTextureUnit().  It's simpler
to just inline it.

The error check / code / message in the helper was incorrect.  It was
written for glBindTextures(), not glBindTextureUnit().  The correct
error for a bad texture unit number is GL_INVALID_VALUE.  The error
message now reports the unit number rather than a GL_TEXTUREi enum.

Fixes a failure in piglit's arb_direct_state_access-bind-texture-unit test.

Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

mesa: consolidate texture binding code

Before, we were doing the actual _mesa_reference_texobj() call and
ctx->Driver.BindTexture() and misc housekeeping in three different
places.  This consolidates the common code in a new bind_texture()
function.

Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

mesa: fix indentation in _mesa_create_nameless_texture()

st/mesa: clean up #includes in st_draw.c

Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

mesa: clean up #includes in sampler.cpp

Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

mesa: clean up #includes in ir_to_mesa.cpp

Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

mesa: clean up #includes in uniforms.h

Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

mesa: clean up #includes in uniform_query.cpp

Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

mesa: clean up #includes in pipelineobj.c

Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

mesa: clean up #includes in ff_fragment_shader.cpp

Get rid of "../glsl/" paths.  Sort alphabetically.

Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

main: Fix block index when mixing UBO and SSBO blocks

Since we store both in UniformBlocks, we can't just compute the index by
subtracting the array address start, we need to count the number of
buffers of the approriate type.

v2:
  - Just fall back to calc_resource_index (Tapani)

Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

mesa: use strtok_s for strtok_r on windows

https://msdn.microsoft.com/en-us/library/ftsafwz3.aspx

v2: use _WIN32 instead of _MSC_VER (Brian Paul)

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92183
Reviewed-by: Brian Paul <brianp@vmware.com>

meta: Handle array textures in scaled MSAA blits

The old code had some significant problems with respect to
sampler2DArray textures.  The biggest problem was that some of the code
would use vec3 for the texture coordinate type, and other parts of the
code would use vec2.  The resulting shader would not even compile.
Since there were not tests for this path, nobody noticed.

The input to the fragment shader is always treated as a vec3.  If the
source data is only vec2, the vertex puller will supply 0 for the .z
component.  The texture coordinate passed to the fragment shader is
always a vec2 that comes from the .xy part of the vertex shader input.
The layer, taken from the .z of the vertex shader input is passed
separately as a flat integer.  If the generated fragment shader does not
use the layer integer, the GLSL linker will eliminate all the dead code
in the vertex shader.

Fixes the new piglit tests "blit-scaled samples=2 with
gl_texture_2d_multisample_array", etc. on i965.

Note for stable maintainer: This patch may depend on 46037237, and that
patch should be safe for stable.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: Topi Pohjolainen <topi.pohjolainen@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

i965/miptree: Add PRM references for most struct members (v2)

Add comments that link the driver's miptree structures to the hardware
structures documented in the PRM.  This provides sorely needed
orientation to developers new to the miptree code. And for miptree
veterans, this clarifies some of the more obscure miptree data.

For each driver struct field that closely corresponds to a
hardware struct field, add a PRM reference to that hardware field's
name. For example,

    struct intel_mipmap_tree {
       ...
       /**
        * @brief One of GL_TEXTURE_2D, GL_TEXTURE_2D_ARRAY, etc.
        *
        * @see RENDER_SURFACE_STATE.SurfaceType
        * @see RENDER_SURFACE_STATE.SurfaceArray
        * @see 3DSTATE_DEPTH_BUFFER.SurfaceType
        */
       GLenum target;
       ...
    };

Also annotate the INTEL_MSAA_LAYOUT_* enums with the name of the PRM
sections that documents the layout.

v2: Replace "2D subimage" with "slice", and define what a "slice" is.
    For Ben.

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com> (v1)
Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1)

i965/miptree: Rename align_w,align_h -> halign,valign

The values of intel_mipmap_tree::align_w and ::align_h correspond to the
hardware enums HALIGN_* and VALIGN_*.

See the confusion?
    align_h != HALIGN
    align_h == VALIGN

Reduce the confusion by renaming the variables to match the hardware
enum names:
    git ls-files |
    xargs sed -i -e 's/align_w/halign/g' \
                 -e 's/align_h/valign/g'

Suggested-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/miptree: Rename intel_miptree_map::mt -> ::linear_mt (v2)

Because that's what it is. It's an untiled, *linear* miptree.

v2:
  - Add space after /*.
  - Use one comment per function argument.

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Acked-by: Ben Widawsky <benjamin.widawsky@intel.com>

i965/miptree: Fix comments for map mode

The comment for intel_miptree_map::mode claimed that it was a bitmask of
GL_MAP_{READ,WRITE,INVALIDATE}_BIT. In reality, the bitmask may include
any of {GL,BRW}_MAP_*_BIT.

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Acked-by: Ben Widawsky <benjamin.widawsky@intel.com>

i965/miptree: More comments for BRW_MAP_DIRECT_BIT (v2)

Clarify that this bit extends the set of GL_MAP_*_BIT enums.
Also fix typo of "temporary".

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Acked-by: Ben Widawsky <benjamin.widawsky@intel.com>

i965: Remove duplicate copy of is_scalar_shader_stage().

Jason open coded this in 60befc63 when cleaning up some ugly code;
using our existing helper tidies it up a bit more.

v2: Drop inline (suggested by Matt).

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

i915: Remember to call intel_prepare_render() before blitting

Bring over the following fix from i965:
 commit fb3d62fe3d4fc40ba4ad9804d8b6f451316c9ae2
 Author: Kenneth Graunke <kenneth@whitecape.org>
 Date:   Tue Aug 6 14:36:09 2013 -0700

    i965: Remember to call intel_prepare_render() before blitting.

Fixes a crash in the following piglit tests:
 bin/fbo-sys-blit -auto
 bin/fbo-sys-sub-blit -auto

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "11.0" <mesa-stable@lists.freedesktop.org>

i915: Fix texcoord vs. varying collision in fragment programs

i915 fragment programs utilize the texture coordinate registers
for both texture coordinates and varyings. Unfortunately the
code doesn't check if the same index might be in use for both.
It just naively uses the index to pick a texture unit, which
could lead to collisions.

Add an extra mapping step to allocate non conflicting texture
units for both uses.

The issue can be reproduced with a pair of simple shaders like
these:
 attribute vec4 in_mod;
 varying vec4 mod;
 void main() {
   mod = in_mod;
   gl_TexCoord[0] = gl_MultiTexCoord0;
   gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
 }

 varying vec4 mod;
 uniform sampler2D tex;
 void main() {
   gl_FragColor = texture2D(tex, vec2(gl_TexCoord[0])) * mod;
 }

Fixes many piglit tests on i915:

    glsl-link-varyings-2
    glsl-orangebook-ch06-bump
    interpolation-none-gl_frontcolor-smooth-fixed
    interpolation-none-gl_frontcolor-smooth-none
    interpolation-none-gl_frontcolor-smooth-vertex
    interpolation-none-gl_frontsecondarycolor-smooth-fixed
    interpolation-none-gl_frontsecondarycolor-smooth-vertex
    interpolation-none-gl_frontsecondarycolor-smooth-none
    interpolation-none-other-flat-fixed
    interpolation-none-other-flat-none
    interpolation-none-other-flat-vertex
    interpolation-none-other-smooth-fixed
    interpolation-none-other-smooth-none
    interpolation-none-other-smooth-vertex

v2 [idr]: Minor formatting tweaks.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "11.0" <mesa-stable@lists.freedesktop.org>

i830: Fix collision between I830_UPLOAD_RASTER_RULES and I830_UPLOAD_TEX(0)

I830_UPLOAD_RASTER_RULES and I830_UPLOAD_TEX(0) are trying to occupy
the same bit. Move the texture bits upwards a bit to make room for
I830_UPLOAD_RASTER_RULES.

Now the driver will actually upload the raster rules which is rather
important to get the provoking vertex right. Fixes the appearance
of glxgears teeth on gen2.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

i965/cs: Upload UBO/SSBO surfaces

Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>

mesa: Fix format specifier warning in mesa_DispatchComputeIndirect()

Commit 1665d29ee3125743fd6daf3c43fc715f543d5669 introduced an incorrect
format specifier that operates on GLintptr indirect within the function
_mesa_DispatchComputeIndirect().

This patch mitigates the introduced GCC warning:

src/mesa/main/compute.c: In function '_mesa_DispatchComputeIndirect':
src/mesa/main/compute.c:53:7: warning: format '%d' expects argument of type 'int', but argument 3 has type 'GLintptr' [-Wformat=]
       _mesa_debug(ctx, "glDispatchComputeIndirect(%d)\n", indirect);
           ^

v2: Amend for Boyan Ding <boyan.j.ding@gmail.com> feedback.

Signed-off-by: Rhys Kidd <rhyskidd@gmail.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

i965: Get rid of prog_data compare functions

They are no longer used.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/state_cache: Remove the aux_compare fields

They haven't been used since 1bba29ed403e735ba0bf04ed8aa2e571884fcaaf so
there's no good reason to keep them around.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/copy_image: Fix a copy+past error

Reported-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: Remove early release of DRI2 miptree

intel_update_winsys_renderbuffer_miptree() will release the existing
miptree when wrapping a new DRI2 buffer, so we can remove the early
release and so prevent a NULL mt dereference should importing the new
DRI2 name fail for any reason. (Reusing the old DRI2 name will result
in the rendering going astray, to a stale buffer, and not shown on the
screen, but it allows us to issue a warning and not crash much later in
innocent code.)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86281
Reviewed-by: Martin Peres <martin.peres@linux.intel.com>
Reviewed-by: Chad Versace <chad.versace@intel.com>

glsl: assert base_alignment > 0 for records

From GLSL 1.50 spec, section 4.1.8 "Structures":

"Structures must have at least one member declaration."

So the base_alignment should be higher than zero.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>