st/mesa: fix glDrawPixels with a texture

The samplers for DrawPixels data and the pixel map are assigned to slots
which don't overlap with the existing sampler slots.

The texture coordinates for the user texture are uploaded as a constant.

Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>

st/mesa: implement DrawPixels shader transformation using tgsi_transform_shader

Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>

st/mesa: make Z/S drawpix shaders independent of variants, don't use Mesa IR v2

- there is no connection to user fragment shaders, so having these as
  shader variants makes no sense
- don't use Mesa IR, use TGSI
- don't create gl_fragment_program, just create the shader CSO

v2: generate exactly the same shader as before to fix llvmpipe

Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>

st/mesa: implement glBitmap shader transformation using tgsi_transform_shader

Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>

st/mesa: remove old emulation for VS and FS variants

Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>

st/mesa: use TGSI utility to emulate features for FS variants

Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>

st/mesa: use TGSI utility to emulate features for VS variants

Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>

st/mesa: decrease the size of st_vertex_program

The other variables can't be moved.

Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>

st/mesa: inline st_prepare_vertex_program

No other shader stage has a "prepare" function.
This will allow removing some variables from st_vertex_program.

Also, prepare_fragment_program was a dead prototype.

Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>

tgsi/scan: add info about declared samplers (v2)

v2: get it from declarations, not instructions

tgsi: add a utility for emulating some GL features

st/mesa will use this, but drivers can use it too.

Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>

mesa: call ProgramStringNotify for fixed-function vertex programs

Drivers weren't notified about this at all.
This allows disabling on-demand compilation in drivers.

Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Tested-by: Brian Paul <brianp@vmware.com>

glsl: move shader_enums into nir

First step towards inverting the dependency between glsl and nir (so nir
can be used without glsl).  Also solves this issue with 'make distclean'

  Making distclean in mesa
  make[2]: Entering directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/mesa'
  Makefile:2486: ../glsl/.deps/shader_enums.Plo: No such file or directory
  make[2]: *** No rule to make target '../glsl/.deps/shader_enums.Plo'. Stop.
  make[2]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src/mesa'
  Makefile:684: recipe for target 'distclean-recursive' failed
  make[1]: *** [distclean-recursive] Error 1
  make[1]: Leaving directory '/mnt/sdb1/Src64/Mesa-git/mesa/src'
  Makefile:615: recipe for target 'distclean-recursive' failed
  make: *** [distclean-recursive] Error 1

Reported-by: Andy Furniss <adf.lists@gmail.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Rob Clark <robclark@freedesktop.org>

mesa: Get rid of texture-dependent image unit derived state.

The point is to avoid having to re-validate all image units when
_NEW_TEXTURE is flagged, which can be expensive if the driver exposes
a large number of image units.  This has been reported to fix a 36%
performance regression in the Synmark2 Multithread benchmark on the
i965 driver which exposes 192 image units.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91788
Reported-by: Wendy Wang <wendy.wang@intel.com>
Tested-by: Ye Tian <yex.tian@intel.com>
CC: "11.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i965: Use _mesa_is_image_unit_valid() instead of gl_image_unit::_Valid.

gl_image_unit::_Valid will be removed in a future commit.

Tested-by: Ye Tian <yex.tian@intel.com>
CC: "11.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: Skip redundant texture completeness checking during image validation.

The call to _mesa_test_texobj_completeness() is unnecessary if the
texture is already known to be complete.  If the texture object is
dirtied in the meantime _BaseComplete and _MipmapComplete will be
reset to false.  _mesa_is_image_unit_valid() will start to be called
more frequently in a future commit, so it seems desirable to avoid the
unnecessary work.

Tested-by: Ye Tian <yex.tian@intel.com>
CC: "11.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: Expose function to calculate whether a shader image unit is valid.

A future commit will remove all texture object-dependent derived state
from the image unit struct to make validation unnecessary on texture
state changes.  Instead of checking gl_image_unit::_Valid drivers will
be required to call this function when needed to find out whether an
image unit is in a valid state and whether access from the shader is
allowed.

Tested-by: Ye Tian <yex.tian@intel.com>
CC: "11.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i965: Don't tell the hardware about our UAV access.

The hardware documentation relating to the UAV HW-assisted coherency
mechanism and UAV access enable bits is scarce and sometimes
contradictory, and there's quite some guesswork behind this commit, so
let me summarize the background first: HSW and later hardware have
infrastructure to support a stricter form of data coherency between
shader invocations from separate primitives.  The mechanism is
controlled by the "Accesses UAV" bits on 3DSTATE_VS, _HS, _DS, _GS and
_PS (or _PS_EXTRA on BDW+), and the "UAV Coherency Required" bit on
the 3DPRIMITIVE command.

Regardless of whether "UAV Coherency Required" is set, the hardware
fixed-function units will increment a per-stage semaphore for each
request received if "Accesses UAV" is set for the same or any lower
stage.  An implicit DC flush is emitted by the lowermost stage with
"Accesses UAV" set once it's done processing the request, this also
happens regardless of the value of "UAV Coherency Required".  The
completion of the DC flush will cause the same stage and all previous
ones to decrement the semaphore, marking the UAV accesses for the
primitive as coherent with L3.

The "UAV Coherency Required" 3DPRIMITIVE bit will cause a pipeline
stall before any threads are dispatched for the first FF stage with
"Accesses UAV" set until the semaphore is cleared for the same stage.
Effectively this guarantees that UAV memory accesses performed by
previous primitives from any stage will be strictly ordered (and
thanks to the implicit DC flush visible in memory) with UAV accesses
from the following primitives.

None of this is required by the usual image, atomic counter and SSBO
GL APIs which have very relaxed cross-primitive coherency and ordering
requirements, so we don't actually ever set the "UAV Coherency
Required" bit -- Ordering with respect to shader invocations from
previous stages on the same primitive where there is a data dependency
is of course already guaranteed as the spec requires, regardless of
this mechanism being enabled.  We do set the "Accesses UAV" bits
though since my commit ac7664e493655e290783c23a0412b9c70936da50 (which
this patch partially reverts), mainly because of comments like the
following from the BDW PRM:

> 3DSTATE_GS
>[...]
> 12 Accesses UAV
>    Format: Enable
>    This field must be set when GS has a UAV access.

There are similar comments in the documentation for the other
3DSTATE_*S commands.  The "must" part is misleading and unjustified
AFAIK.  Most of the "Accesses UAV" bits don't seem to have any side
effects other than the implicit DC flushes and the related
book-keeping in anticipation for a subsequent primitive with "UAV
Coherency Required" set, so in most cases they are unnecessary and may
incur a performance penalty.  There is an exception though.  On Gen8+
the PS_EXTRA UAV access bit influences the calculation of the PS
UAV-only and ThreadDispatchEnable signals which on previous
generations were set explicitly by the driver, so we cannot always
avoid enabling it on the PS stage.

The primary motivation for this change is that in fact the hardware
coherency mechanism is buggy and will cause a rather non-deterministic
hang on Gen8 when VS is the only stage with "Accesses UAV" set and the
processing of a request terminates immediately after the implicit DC
flush is sent for a previous primitive with no additional vertices
being emitted for the second primitive, what will cause the hardware
to skip sending a second DC flush and cause the VS to stall
indefinitely waiting for a response from the DC (BDWGFX HSD 1912017).
This hardware bug can be reproduced on current master with the
spec@arb_shader_image_load_store@host-mem-barrier@Indirect/RaW piglit
subtest (if you have the patience to run it a few dozen times).

The proposed workaround is to insert CS STALLs speculatively between
3DPRIMITIVE commands when "Accesses UAV" is enabled for the VS stage
only.  Because this would affect one of the hottest paths in the
driver and likely decrease performance even further due to the
unnecessary serialization, and because we don't actually need the
implicit DC flushes, it seems better to just disable them.

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

nir/instr_set: remove unnecessary check in nir_instrs_equal()

This was originally added to nir_instrs_equal() instead of
nir_instr_can_cse() incorrectly, but this was fixed when moving to the
instruction set API (as it had to be, otherwise hashing wouldn't work).
Now, this is dead code since instr_can_rewrite() will only return true
for texture instructions that use an index, so we can turn the check into
an assert. This also means that now nir_instrs_equal(instr, instr) will
always return true unless it assert-fails.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>

nir: make nir_instrs_equal() static

This was previously tied to CSE, since it would only work for
instructions where nir_can_cse() (now instr_can_rewrite()) returned
true. Now that CSE uses the instruction set abstraction which only uses
this internally, we can make it local to nir_instr_set.c.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>

nir/cse: use the instruction set API

This replaces an O(n^2) algorithm with an O(n) one, while allowing us to
import most of the infrastructure required for GVN. The idea is to walk
the dominance tree depth-first, similar when converting to SSA, and
remove the instructions from the set when we're done visiting the
sub-tree of the dominance tree so that the only instructions in the set
are the instructions that dominate the current block.

No piglit regressions. No shader-db changes.

Compilation time for full shader-db:

Difference at 95.0% confidence
        -35.826 +/- 2.16018
        -6.2852% +/- 0.378975%
        (Student's t, pooled s = 3.37504)

v2:
- rebase on start_block removal
- remove useless state struct
- change commit message

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>

nir: add an instruction set API

This will replace direct usage of nir_instrs_equal() in the CSE pass,
which reduces an O(n^2) algorithm with an effectively O(n) one. It'll
also be useful for implementing GVN on top of GCM.

v2:
- Add texture support.
- Add more comments.
- Rename instr_can_hash() to instr_can_rewrite() since it's really more
about whether its uses can be rewritten, and it's implicitly used by
nir_instrs_equal() as well.
- Rename nir_instr_set_add() to nir_instr_set_add_or_rewrite() (Jason).
- Make the HASH() macro less magical (Topi).
- Rewrite the commit message.

v3:
- For sorting phi sources, use a VLA, store pointers to the sources, and
compare the predecessor pointer directly (Jason).

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>

nir: constify instruction comparison functions

v2: rebase, don't constify nir_srcs_equal() as it's pass-by-value
anyways

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>

nir: constify nir_ssa_alu_instr_src_components()

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>

nir: split out instruction comparison functions

Right now nir_instrs_equal() is tied pretty tightly to CSE, but we're
going to introduce the idea of an instruction set and tie it to that
instead.  In anticipation of that, move this into its own file where
we'll add the rest of the instruction set implementation later.

v2: Rebase on texture support.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Connor Abbott <cwabbott0@gmail.com>

i965/fs: Handle non-const sample number in interpolateAtSample

If a non-const sample number is given to interpolateAtSample it will
now generate an indirect send message with the sample ID similar to
how non-const sampler array indexing works. Previously non-const
values were ignored and instead it ended up using a constant 0 value.

The generator will try to determine if the sample ID is dynamically
uniform via nir_src_is_dynamically_uniform. If not it will query the
pixel interpolator in a loop, once for each different live sample
number. The next live sample number is found using emit_uniformize. If
multiple live channels have the same sample number then they will be
handled in a single iteration of the loop. The loop is necessary
because the indirect send message doesn't seem to have a way to
specify a different value for each fragment.

This fixes the following two Piglit tests:

arb_gpu_shader5-interpolateAtSample-nonconst
arb_gpu_shader5-interpolateAtSample-dynamically-nonuniform

v2: Handle dynamically non-uniform sample ids.
v3: Remove the BREAK instruction and predicate the WHILE directly.
    Make the tokens arrays const. (Matt Turner)
v4: Iterate over the live channels instead of each possible sample
    number.
v5: Don't special case immediate values in
    brw_pixel_interpolator_query. Make a better wrapper for the
    function to set up the PI send instruction. Ensure that the SHL
    instructions are scalar. (Francisco Jerez).

Reviewed-by: Francisco Jerez <currojerez@riseup.net>

i965: Add a second successor to BRW_OPCODE_WHILE

It is possible to directly predicate the WHILE instruction. In this
case there will be a second successor block because the execution can
resume from the instruction after the loop. This will be used in a
subsequent patch.

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

nir: Add a function to determine if a source is dynamically uniform

Adds nir_src_is_dynamically_uniform which returns true if the source
is known to be dynamically uniform. This will be used in a later patch
to add a workaround for cases that only work with dynamically uniform
sources. Note that the function is not definitive, it can return false
negatives (but not false positives). Currently it only detects
constants and uniform accesses. It could easily be extended to include
more cases.

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

nvc0: move HW SM queries to nvc0_query_hw_sm.c/h files

Global performance counters (PCOUNTER) will be added to
nvc0_query_hw_pm.c/h files.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>

nvc0: move HW queries to nvc0_query_hw.c/h files

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>

nvc0: move SW queries to nvc0_query_sw.c/h files

Loosely based on freedreno driver.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>

nvc0: move nvc0_so_target_save_offset() to its correct location

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>

nvc0: add a header file for nvc0_query

This will allow to split SW and HW queries in an upcoming patch.

While we are at it, make use of nvc0_query struct instead of pipe_query.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>

main: fix length of values written to glGetProgramResourceiv() for ACTIVE_VARIABLES

Return the number of values written.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au>

main: buffer array variables can have array size of 0 if they are unsized

From ARB_program_query_interface:

  For the property ARRAY_SIZE, a single integer identifying the number of
  active array elements of an active variable is written to <params>. The
  array size returned is in units of the type associated with the property
  TYPE. For active variables not corresponding to an array of basic types,
  the value one is written to <params>. If the variable is a shader
  storage block member in an array with no declared size, the value zero
  is written to <params>.

v2:
- Unsized arrays of arrays have an array size different than zero

v3:
- Arrays and unsized arrays will have an array_stride > 0. Use it
  instead of is_unsized_array flag (Timothy).

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au>

main: consider that unsized arrays have at least one active element

From ARB_shader_storage_buffer_object:

"When using the ARB_program_interface_query extension to enumerate the
 set of active buffer variables, only the first element of arrays (sized
 or unsized) will be enumerated"

_mesa_program_resource_array_size() is used when getting the name (and
name length) of the active variables. When it is an unsized array,
we want to indicate it has one active element so the returned name
would have "[0]" at the end.

v2:
- Use array_stride > 0 and array_elements == 0 to detect unsized
  arrays. Because of that, we don't need is_unsized_array flag
  (Timothy)

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au>

main: fix TOP_LEVEL_ARRAY_SIZE and TOP_LEVEL_ARRAY_STRIDE

When the active variable is an array which is already a top-level
shader storage block member, don't return its array size and stride
when querying TOP_LEVEL_ARRAY_SIZE and TOP_LEVEL_ARRAY_STRIDE
respectively.

Fixes the following 12 dEQP-GLES31 tests:

dEQP-GLES31.functional.ssbo.layout.single_basic_array.shared.mat3x4
dEQP-GLES31.functional.ssbo.layout.single_basic_array.shared.row_major_mat3x4
dEQP-GLES31.functional.ssbo.layout.single_basic_array.shared.column_major_mat3x4
dEQP-GLES31.functional.ssbo.layout.single_basic_array.packed.mat3x4
dEQP-GLES31.functional.ssbo.layout.single_basic_array.packed.row_major_mat3x4
dEQP-GLES31.functional.ssbo.layout.single_basic_array.packed.column_major_mat3x4
dEQP-GLES31.functional.ssbo.layout.single_basic_array.std140.mat3x4
dEQP-GLES31.functional.ssbo.layout.single_basic_array.std140.row_major_mat3x4
dEQP-GLES31.functional.ssbo.layout.single_basic_array.std140.column_major_mat3x4
dEQP-GLES31.functional.ssbo.layout.single_basic_array.std430.mat3x4
dEQP-GLES31.functional.ssbo.layout.single_basic_array.std430.row_major_mat3x4
dEQP-GLES31.functional.ssbo.layout.single_basic_array.std430.column_major_mat3x4

v2:
- Fix check when the shader storage block is instanced
- Write auxiliary function to do the check.

v3:
- Check if full_instanced_name is NULL just after allocation (Ilia)
- Remove () from one strcmp() in the if statement (Ilia)

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

main: fix goto in program_resource_top_level_array_stride

Use found_top_level_array_stride instead of found_top_level_array_size.

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Timothy Arceri <t_arceri@yahoo.com.au>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>

mesa: add GL_UNSIGNED_INT_24_8 to _mesa_pack_depth_span

Patch adds missing type (used with NV_read_depth) so that it gets
handled correctly. This fixes errors seen with following CTS test:

   ES3-CTS.gtf.GL3Tests.packed_pixels.packed_pixels

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: "11.0" <mesa-stable@lists.freedesktop.org>

mesa,meta: move gl_texture_object::TargetIndex initializations

Before, we were unconditionally assigning the TargetIndex field in
_mesa_BindTexture(), even if it was already set properly.  Now we
initialize TargetIndex wherever we initialize the Target field, in
_mesa_initialize_texture_object(), finish_texture_init(), etc.

v2: also update the meta_copy_image code.  In make_view() the
view_tex_obj->Target field was set, but not the TargetIndex field.
Also, remove a second, redundant assignment to view_tex_obj->Target.
Add sanity check assertions too.

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: Mark Janes <mark.a.janes@intel.com>

mesa: remove unused _mesa_create_nameless_texture()

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: Mark Janes <mark.a.janes@intel.com>

mesa: remove unneeded error check in create_textures()

Callers of create_texture() will either pass target=0 or a validated
GL texture target enum so no need to do another error check inside
the loop.

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: Mark Janes <mark.a.janes@intel.com>

i965: Link compiler unit tests to libi965_compiler.la

We can now link the unit tests against just libi965_compiler.la. This
lets us drop a lot of DRI driver dependencies, but we still pull in all
of libmesa and more.

This also provides a few standalone users of libi965_compiler.la, which
will help us accidentally using i965_dri.so functions from the compiler.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Kristian Høgsberg Kristensen <krh@bitplanet.net>

i965: Break out backend compiler to its own library

This introduces a new libtool helper library, libi965_compiler.la.  This
library is moderately self-contained, but still needs to link to all of
libmesa.la among other things.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Kristian Høgsberg Kristensen <krh@bitplanet.net>

i965/cs: Get max_cs_threads from brw_compiler devinfo

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Kristian Høgsberg Kristensen <krh@bitplanet.net>

i965: Move brw_get_shader_time_index() call out of emit functions

brw_get_shader_time_index() is all tangled up in brw_context state and
we can't call it from the compiler. Thanks the Jasons recent
refactoring, we can just get the index and pass to the emit functions
instead.

Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
Signed-off-by: Kristian Høgsberg Kristensen <krh@bitplanet.net>

i965: Move brw_select_clip_planes() to brw_shader.cpp

We call this from the compiler so move it to brw_shader.cpp.

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Signed-off-by: Kristian Høgsberg Kristensen <krh@bitplanet.net>

i965: Use util_next_power_of_two() for brw_get_scratch_size()

This function computes the next power of two, but at least 1024. We can
do that by bitwise or'ing in 1023 and calling util_next_power_of_two().

We use brw_get_scratch_size() from the compiler so we need it out of
brw_program.c. We could move it to brw_shader.cpp, but let's make it a
small inline function instead.

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Signed-off-by: Kristian Høgsberg Kristensen <krh@bitplanet.net>

i965: Move brw_mark_surface_used() to brw_shader.cpp

brw_program.c won't be part of the compiler library, but we need
brw_mark_surface_used() in the compiler. Move to brw_shader.cpp.

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Signed-off-by: Kristian Høgsberg Kristensen <krh@bitplanet.net>

i965/cs: Split out helper for building local id payload

The initial motivation for this patch was to avoid calling
brw_cs_prog_local_id_payload_dwords() in gen7_cs_state.c from the
compiler. This commit ends up refactoring things a bit more so as to
split out the logic to build the local id payload to brw_fs.cpp. This
moves the payload building closer to the compiler code that uses the
payload layout and makes it available to other users of the compiler.

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Signed-off-by: Kristian Høgsberg Kristensen <krh@bitplanet.net>

i965: Move brw_link_shader() and friends to new file brw_link.cpp

We want to use the rest of brw_shader.cpp with the rest of the compiler
without pulling in the GLSL linking code.

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Signed-off-by: Kristian Høgsberg Kristensen <krh@bitplanet.net>

i965: Configure bufmgr debug options from intel_screen.c

We need the debug flag parsing and INTEL_DEBUG in the compiler, but we
don't want the dependency on bufmgr (libdrm_intel) in there. Move to
intel_screen.c.

There are now only two lines left in brw_process_intel_debug_variable(),
but we keep it in intel_debug.h to avoid having to expose
'debug_control' as a global variable.

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Kristian Høgsberg Kristensen <krh@bitplanet.net>

util: Move DRI parse_debug_string() to util

We want to use intel_debug.c in code that doesn't link to dri common.

v2: Remove unnecessary stddef.h include (Topi), use util/debug.h
    in all DRI driver and remove driParseDebugString() (Iago).

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Signed-off-by: Kristian Høgsberg Kristensen <krh@bitplanet.net>

i965: Move brw_dump_ir() out of brw_*_emit() functions

We move these calls one level up into the codegen functions.

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Signed-off-by: Kristian Høgsberg Kristensen <krh@bitplanet.net>

gallium/ddebug: add missing dd_util.h to sources list

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

gallium/ddebug: automake: sort sources alphabetically

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

nir/sweep: Reparent the shader name

Previously the name of the nir shader was being freed prematurely during
nir_sweep. Since 756613ed35d the name was later being used to generate
filenames for the optimiser debug output and these would end up with
garbage from the dangling pointer.

Co-authored-by: Neil Roberts <neil@linux.intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

c11/threads: initialize timeout structure

Signed-off-by: Jan Vesely <jano.vesely@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

docs/relnotes: document EGL_KHR_create_context on llvmpipe and softpipe

Signed-off-by: Boyan Ding <boyan.j.ding@gmail.com>

i965/gs/gen6: Maximum allowed size of SEND messages is 15 (4 bits)

Comit d48ac9306619 addressed this for VS, but we forgot to do the same for
URB writes generated by the gen6 GS.

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

i965: Define FIRST_SPILL_MRF and FIRST_PULL_LOAD_MRF only once and in one place

That should make tracking where we do spills and pull loads a bit easier.

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

i965: make pull constant loads in gen6 start at MRFs 16/17

So they do not conflict with our (un)spills (MRF 21..23) or our
URB writes (MRF 1..15)

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

i965: Fix remove_duplicate_mrf_writes so it can handle 24 MRFs in gen6

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

mesa: include bad type in error string of _mesa_pack_depth_span

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

glsl: add varyings to resource list only with SSO

Varyings can be considered inputs or outputs of a program only when
SSO is in use. With multi-stage programs, inputs contain only inputs
for first stage and outputs contains outputs of the final shader stage.

I've tested that fix works for Assault Android Cactus (demo version)
and does not cause Piglit or CTS regressions in glGetProgramiv tests.

Following ES 3.1 CTS separate shader tests that do query properties
of varyings in SSO shader programs pass:

   ES31-CTS.program_interface_query.separate-programs-vertex
   ES31-CTS.program_interface_query.separate-programs-fragment

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92122

mesa: Correctly handle GL_BGRA_EXT in ES3 format_and_type checks

The EXT_texture_format_BGRA8888 extension (which mesa supports
unconditionally) adds a new format and internal format called GL_BGRA_EXT.
Previously, this was not really handled at all in
_mesa_ex3_error_check_format_and_type.  When the checks were tightened in
commit f15a7f3c, we accidentally tightened things too far and GL_BGRA_EXT
would always cause an error to be thrown.

There were two primary issues here.  First, is that
_mesa_es3_effective_internal_format_for_format_and_type didn't handle the
GL_BGRA_EXT format.  Second is that it blindly uses _mesa_base_tex_format
which returns GL_RGBA for GL_BGRA_EXT.  This commit fixes both of these
issues as well as adds explicit checks that GL_BGRA_EXT is only ever used
with GL_BGRA_EXT and GL_UNSIGNED_BYTE.

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92265
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "11.0" <mesa-stable@lists.freedesktop.org>

Revert "mesa: enable KHR_debug for ES contexts"

This reverts commit b69cfbdf18fa64606a76761b20bc268f4ac731e5.

This isn't quite baked yet. Seems that despite building the ES piglits,
none of them got executed.

egl/dri2: Properly dereference array.

Fixes a regression that broke EGL since

commit 858f2f2ae6d72f338fdd6d544b0c733814e22724
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date:   Sun Sep 13 12:25:27 2015 +0100

    egl/dri2: ease srgb __DRIconfig conditionals

radeonsi: fix a GS hang on VI

Broken by one of the cleanups: 0d46c3bc9d09b376d74f7399e1a2d1b0a923640b
Not applicable to stable.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

radeonsi: remove TC L2 cache flush for index buffers on VI

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

svga: whitespace fixes in svga_sampler_view.c

svga: whitespace fixes in svga_resource_buffer.c

mesa: Remove GL_ARB_sampler_object depth compare error checking.

Version 3: Simplify the code comment, word wrap commit description.

Version 2: Return GL_FALSE if ARB_shadow is unsupported instead of
pretending to store the value as suggested by Brian Paul.

This fixes a GL error warning on r200 in Wine.

The GL_ARB_sampler_objects extension does not specify a dependency on
GL_ARB_shadow or GL_ARB_depth_texture for setting the depth texture
compare mode and function. Silently ignore attempts to change these
settings. They won't matter without a depth texture being assigned
anyway.

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

svga: round UBO constant buffer size up/down to multiple of 16 bytes

The svga3d device requires constant buffers to be a multiple of 16 bytes
in size.  OpenGL UBOs may not fit that restriction.  As a work-around,
round the size up if possible, else round down.

Note that this patch only effects UBO constant buffers (index 1 or higher),
not the 0th/default constant buffer.

Fixes the game Grim Fandango Remastered.  VMware bug 1510130.

Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>

egl/dri2: enable EGL_KHR_gl_colorspace for swrast

No driver changes needed for softpipe/llvmpipe - things just work.

v2: Whitespace fixes.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Boyan Ding <boyan.j.ding@gmail.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>

egl/dri2: ease srgb __DRIconfig conditionals

One can simplify the if-else chain, by declaring the driconfigs as a
two sized array, whist using srgb as a index to the correct entry.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>

mesa: enable KHR_debug for ES contexts

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

main/get: make KHR_debug enums available everywhere

Move all the enums but CONTEXT_FLAGS. The spec seems quite explicit
about the latter (wrt OpenGL ES)

    "In OpenGL ES versions prior to and including ES 3.1 there is no
    CONTEXT_FLAGS state and therefore the CONTEXT_FLAG_DEBUG_BIT cannot
    be queried."

v2 [Emil Velikov] Rebase.
v3 [Emil Veliokv] Drop the CONTEXT_FLAGS hunk - not applicable for GLES

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

glapi: add function pointers for KHR_debug for gles

v2 [Emil Velikov]
 - Rebase.
 - Correct version in gles11 dispatch_sanity.
 - Move the extension enable to a separate patch.

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

egl: move memcpy to bring conf->base operations together

Signed-off-by: Varad Gautam <varadgautam@gmail.com>
Suggested-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>

egl: restore surface type before linking config to its display

commit c2c2e9a (egl: implement EGL_KHR_gl_colorspace (v2)) leaves
_EGLConfig->SurfaceType set incorrectly before calling _eglLinkConfig(),
and the bad value is passed around to platform_android. set it to zero
as earlier.

v2: Set SurfaceType to 0, rather than surface_type (Suggested by Emil)

Cc: mesa-stable@lists.freedesktop.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91596
Signed-off-by: Varad Gautam <varadgautam@gmail.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>

nouveau: make sure there's always room to emit a fence

I started seeing a lot of situations on nv30 where fence emission
wouldn't fit into the previous buffer (causing assertions). This ensures
that whenever checking for space, we always leave a bit of extra room
for the fence emission commands. Adjusts the nv30 and nvc0 fence
emission logic to bypass the space checking as well.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>

vc4: use nir two-sided-color lowering

Similar to 9ffc1049ca (freedreno/ir3: use nir two-sided-color lowering).
No piglit regression.

Signed-off-by: Boyan Ding <boyan.j.ding@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

vc4: Fix a leak of the last color read/write surface on context destroy.

vc4: Fix a memory leak in the simulator case.

We validate per draw call, and need to free the shader per draw call, too.

mesa: remove unneeded #include of colormac.h

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

radeon/r200: remove unneeded #include of colormac.h

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

i965: remove unneeded #include of colormac.h

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

i915: remove unneeded #include of colormac.h

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

i915: Drop broken front_buffer_reading/drawing optimization

Bring the following commit over to i915:
 commit ec542d74578bbef6b55125dd6aba1dc7f5079e65
 Author: Eric Anholt <eric@anholt.net>
 Date:   Mon Mar 3 10:43:10 2014 -0800

    i965: Drop broken front_buffer_reading/drawing optimization.

Not sure if it might fix anything, but since the i965 and i915 used to
share a bunch of that code, it would seem reasonable the same problems
could be present in the i915 code still, and the i965 approach is well
tested by now so bringing it over seems fairly safe.

No piglit regressions on 855.

v2: Rebase on _mesa_is_front_buffer_* refactor.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

mesa/i965: Refactor brw_is_front_buffer_{drawing,reading} to common code

There are multiple similar implementations of these functions, and a
later patch was going to add another.

v2: Move removing intel_framebuffer to a different patch.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

st/mesa: Don't override NewFramebuffer just to call _mesa_new_framebuffer

v2: Since state_tracker does not call _mesa_init_driver_functions, we
need to initialize the dd::NewFramebuffer pointer to
_mesa_new_framebuffer here.  Suggested by Brian.

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

radeon: Don't override NewFramebuffer just to call _mesa_new_framebuffer

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

i915: Don't override NewFramebuffer just to call _mesa_new_framebuffer

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

i965: Don't override NewFramebuffer just to call _mesa_new_framebuffer

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

i830: Fix culling with user fbos on gen2

Flip the cull bits when rendering to a user fbo on gen2. This
was already done on gen3 (since before git history starts)
but was missing from the gen2 code.

Fixes rendering of the driver+kart model in supertuxkart kart
selection screen.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i915: Adjust line size limits

The hardware can draw lines 0.5 to 7.5 pixels wide. Adjust the limits
to 1.0-7.0. The old limits seems to be from the era when i915 and i965
were sharing this code.

Not really sure if 1.0-7.0 is correct. Maybe it could be 0.5.7.5 as
those are the hw limits, or maybe some combination of the two?

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i915: Enable intel_render path for points

The sub-pixel adjustment for points was killed off in
 commit 60d762aa625095a8c1f9597d8530bb5a6fa61b4c
 Author: Xiang, Haihao <haihao.xiang@intel.com>
 Date:   Wed Jan 2 11:38:51 2008 +0800

    i915: Needn't adjust pixel centers. fix #12944

so if we don't need it in intel_tris.c we don't need it in
intel_render.c either, which means we can allow intel_render.c to render
points.

No apparent regressions on PNV in ES1 or ES2 conformance.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i915: Use COPY_DWORDS for points

The sub-pixel adjustment for points was killed off in
 commit 60d762aa625095a8c1f9597d8530bb5a6fa61b4c
 Author: Xiang, Haihao <haihao.xiang@intel.com>
 Date:   Wed Jan 2 11:38:51 2008 +0800

    i915: Needn't adjust pixel centers. fix #12944

so we can just as well use COPY_DWORDS().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>

i915: Use _tnl_RenderClippedPolygon and _tnl_RenderClippedLine

_tnl_RenderClippedPolygon and _tnl_RenderClippedLine already do most of
what we want so use them.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>