vbo: document vbo_exec_context fields

Reviewed-by: Marek Olšák <marek.olsak@amd.com>

vbo: minor clean-ups for vbo_exec_fixup_vertex()

Reviewed-by: Marek Olšák <marek.olsak@amd.com>

vbo: add assertion in ATTR_UNION macro

Reviewed-by: Marek Olšák <marek.olsak@amd.com>

vbo: add comments, braces in ATTR_UNION() in vbo_exec_api.c

Reviewed-by: Marek Olšák <marek.olsak@amd.com>

vbo: fix whitespace in vbo_exec_draw.c

Reviewed-by: Marek Olšák <marek.olsak@amd.com>

vbo: move 'tmp' var initialization

Improve readability a bit.

Reviewed-by: Marek Olšák <marek.olsak@amd.com>

vbo: improve fprintf() formatting

Reviewed-by: Marek Olšák <marek.olsak@amd.com>

vbo: simplify vertex array initializations in vbo_context.c

Reviewed-by: Marek Olšák <marek.olsak@amd.com>

vbo: get rid of needless NR_MAT_ATTRIBS constant

Reviewed-by: Marek Olšák <marek.olsak@amd.com>

vbo: fix incorrect switch statement in init_mat_currval()

The variable 'i' is a value in [0, MAT_ATTRIB_MAX-1] so subtracting
VERT_ATTRIB_GENERIC0 gave a bogus value and we executed the default
switch clause for all loop iterations.

This doesn't fix any known issues but was clearly incorrect.

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

mesa: pass caller name to create_textures()

Simpler than the dsa flag approach.

glsl: fix matrix stride calculation for std430's row_major matrices with two columns

This is the result of applying several rules:

From OpenGL 4.3 spec, section 7.6.2.2 "Standard Uniform Block Layout":

"2. If the member is a two- or four-component vector with components
consuming N basic machine units, the base alignment is 2N or 4N,
respectively."
[...]
"4. If the member is an array of scalars or vectors, the base alignment
and array stride are set to match the base alignment of a single array
element, according to rules (1), (2), and (3), and rounded up to the
base alignment of a vec4."
[...]
"7. If the member is a row-major matrix with C columns and R rows, the
matrix is stored identically to an array of R row vectors with C
components each, according to rule (4)."
[...]
"When using the std430 storage layout, shader storage blocks will be
laid out in buffer storage identically to uniform and shader storage
blocks using the std140 layout, except that the base alignment and
stride of arrays of scalars and vectors in rule 4 and of structures in
rule 9 are not rounded up a multiple of the base alignment of a vec4."

In summary: vec2 has a base alignment of 2*N, a row-major mat2xY is
stored like an array of Y row vectors with 2 components each. Because
of std430 storage layout, the base alignment of the array of vectors
is not rounded up to vec4, so it is still 2*N.

Fixes 15 dEQP tests:

dEQP-GLES31.functional.ssbo.layout.single_basic_type.std430.row_major_lowp_mat2
dEQP-GLES31.functional.ssbo.layout.single_basic_type.std430.row_major_mediump_mat2
dEQP-GLES31.functional.ssbo.layout.single_basic_type.std430.row_major_highp_mat2
dEQP-GLES31.functional.ssbo.layout.single_basic_type.std430.row_major_lowp_mat2x3
dEQP-GLES31.functional.ssbo.layout.single_basic_type.std430.row_major_mediump_mat2x3
dEQP-GLES31.functional.ssbo.layout.single_basic_type.std430.row_major_highp_mat2x3
dEQP-GLES31.functional.ssbo.layout.single_basic_type.std430.row_major_lowp_mat2x4
dEQP-GLES31.functional.ssbo.layout.single_basic_type.std430.row_major_mediump_mat2x4
dEQP-GLES31.functional.ssbo.layout.single_basic_type.std430.row_major_highp_mat2x4
dEQP-GLES31.functional.ssbo.layout.single_basic_array.std430.row_major_mat2
dEQP-GLES31.functional.ssbo.layout.single_basic_array.std430.row_major_mat2x3
dEQP-GLES31.functional.ssbo.layout.single_basic_array.std430.row_major_mat2x4
dEQP-GLES31.functional.ssbo.layout.instance_array_basic_type.std430.row_major_mat2
dEQP-GLES31.functional.ssbo.layout.instance_array_basic_type.std430.row_major_mat2x3
dEQP-GLES31.functional.ssbo.layout.instance_array_basic_type.std430.row_major_mat2x4

v2:
- Add spec quote in both commit log and code (Timothy)

Signed-off-by: Samuel Iglesias Gonsalvez <siglesias@igalia.com>
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com>

r600/vce: enable VCE for trinity/richland

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

r600/uvd: disable UVD tiling by default

It has only minimal advantages for post processing and doesn't work with VCE.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

r600g: Enable GL_ARB_gpu_shader5 extension

Signed-off-by: Glenn Kennard <glenn.kennard@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

r600g/sb: SB support for UBO indexing

Signed-off-by: Glenn Kennard <glenn.kennard@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

r600g/sb: Support gs5 sampler indexing (v2)

[airlied: v2 cayman fixups]

Signed-off-by: Glenn Kennard <glenn.kennard@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

i965/vs: Simplify fs_visitor's ATTR file.

Previously, ATTR was indexed by VERT_ATTRIB_* slots; at the end of
compilation, assign_vs_urb_setup() translated those into GRF units,
and converted ATTR to HW_REGs.

This patch moves the transslation earlier, making ATTR work in terms of
GRF units from the beginning.  assign_vs_urb_setup() simply has to add
the number of payload registers and push constants to obtain the final
hardware GRF number.  (We can't do this earlier as those values aren't
known.)

ATTR still supports reg_offset; however, it's simply added to reg.
It's not clear whether this is valuable or not.

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

nouveau: avoid double-emitting fence

The act of ensuring that there is space can cause a flush to happen,
which will emit the current screen fence. If that is the fence we're
trying to wait on, then it will have been emitted as a result of doing
the PUSH_SPACE. Don't attempt to emit it a second time.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Fixes: 8053c9208f (nouveau: avoid emitting new fences unnecessarily)
Cc: mesa-stable@lists.freedesktop.org

glsl: Never allow the sequence operator anywhere in an array size

Fixes:

    spec/glsl-1.20/compiler/structure-and-array-operations/array-size-sequence-in-parenthesis.vert
    spec/glsl-es-1.00/compiler/array-sized-by-sequence-in-parenthesis.vert
    spec/glsl-es-3.00/compiler/array-sized-by-sequence-in-parenthesis.vert

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

glsl: In later GLSL versions, sequence operator is cannot be a constant expression

Fixes:
    ES3-CTS.shaders.negative.constant_sequence

    spec/glsl-es-3.00/compiler/global-initializer/from-sequence.vert
    spec/glsl-es-3.00/compiler/global-initializer/from-sequence.frag

v2: Fix a couple copy-and-paste mistake in the spec quotations.
Suggested by Matt.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

glsl: Add method to determine whether an expression contains the sequence operator

This will be used in the next patch to enforce some language sematics.

v2: Fix inverted logic in
ast_function_expression::has_sequence_subexpression.  The method
originally had a different name and a different meaning.  I fixed the
logic in ast_to_hir.cpp, but I only changed the names in
ast_function.cpp.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Marta Lofstedt <marta.lofstedt@intel.com> [v1]
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

glsl: Restrict initializers for global variables to constant expression in ES

v2: Combine this check with the existing const and uniform checks.  This
change depends on the previous patch (glsl: Only set
ir_variable::constant_value for const-decorated variables).

Fixes:

    ES2-CTS.shaders.negative.initialize
    ES3-CTS.shaders.negative.initialize

    spec/glsl-es-1.00/compiler/global-initializer/from-attribute.vert
    spec/glsl-es-1.00/compiler/global-initializer/from-uniform.vert
    spec/glsl-es-1.00/compiler/global-initializer/from-uniform.frag
    spec/glsl-es-1.00/compiler/global-initializer/from-global.vert
    spec/glsl-es-1.00/compiler/global-initializer/from-global.frag
    spec/glsl-es-1.00/compiler/global-initializer/from-varying.frag
    spec/glsl-es-3.00/compiler/global-initializer/from-uniform.vert
    spec/glsl-es-3.00/compiler/global-initializer/from-uniform.frag
    spec/glsl-es-3.00/compiler/global-initializer/from-in.vert
    spec/glsl-es-3.00/compiler/global-initializer/from-in.frag
    spec/glsl-es-3.00/compiler/global-initializer/from-global.vert
    spec/glsl-es-3.00/compiler/global-initializer/from-global.frag

Note: spec/glsl-es-3.00/compiler/global-initializer/from-sequence.*
still fail because the result of a sequence operator is still considered
to be a constant expression.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92304
Reviewed-by: Tapani Pälli <tapani.palli@intel.com> [v1]
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> [v1]
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

glsl: Only set ir_variable::constant_value for const-decorated variables

Right now we're also setting for uniforms, and that doesn't seem to hurt
things.  The next patch will make general global variables in GLSL ES,
and those definitely should not have constant_value set!

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

glsl: Use constant_initializer instead of constant_value to determine whether to keep an unused uniform

This even matches the comment "uniform initializers are precious, and
could get used by another stage."

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

glsl/linker: Use constant_initializer instead of constant_value to initialize uniforms

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

ff_fragment_shader: Use binding to set the sampler unit

This is the way layout(binding=xxx) works from GLSL.  The old method
just happened to work (and significantly predated support for
layout(binding=xxx)), but future changes will break this.

v2: Remove some stale comments.  Suggested by Matt and Chris Forbes.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "10.6 11.0" <mesa-stable@lists.freedesktop.org>

glsl: Allow built-in functions as constant expressions in OpenGL ES 1.00

In d4a24745 (August 2012), Paul made functions calls not be constant
expressions in GLSL ES 1.00.  Since this feature was added in desktop
GLSL 1.20, we believed that it was added in GLSL ES 3.00.  That turns
out to be completely wrong.  Built-in functions have always been allowed
as constant expressions in GLSL ES, and the patch adds the (many) spec
quotations to prove it.

While we never previously encountered this, a later patch enforces a GLSL
ES 1.00 rule that global variable initializers must be constant
expressions.  Without this fix, several dEQP tests fail.

Fixes:

    tests/spec/glsl-es-1.00/compiler/const-initializer/from-function.frag
    tests/spec/glsl-es-1.00/compiler/const-initializer/from-function.vert
    tests/spec/glsl-es-1.00/compiler/const-initializer/from-sequence-in-function.frag
    tests/spec/glsl-es-1.00/compiler/const-initializer/from-sequence-in-function.vert

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: "10.0 10.1 10.2 10.3 10.4 10.5 10.6 11.0" <mesa-stable@lists.freedesktop.org>
Yes, I know we don't maintain stable branches that far back, but that
*is* how far back this bug goes!

u_vbuf: fix vb slot assignment for translated buffers

Vertex attributes of different categories (constant/per-instance/
per-vertex) go into different buffers for translation, and this is now
properly reflected in the vertex buffers passed to the driver.

Fixes e.g. piglit's point-vertex-id divisor test.

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

glsl: include variable name in error messages about initializers

Also fix style / wrong indentation along the way and make the messages
more uniform.

Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

glsl: shader outputs cannot have initializers

GLSL Spec 4.20.8, 4.3 Storage Qualifiers:

"Initializers in global declarations may only be used in declarations of
 global variables with no storage qualifier, with a const qualifier or
 with a uniform qualifier."

We do this for input variables, but not for output variables. AMD and NVIDIA
proprietary drivers don't allow this either.

Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965: Fix unsafe pointer when dumping VS/FS IR

For the VS and FS stages that use ARB_vertex_program or
ARB_fragment_program we don't have a shader program, however,
when debuging is enabled, we call brw_dump_ir like this:

brw_dump_ir("vertex", prog, &vs->base, &vp->program.Base);

where vs will be NULL (since prog is NULL).

As pointed out by Chris, this &vs->base is not really a dereference,
it simply computes a new address that just happens to be 0x0 because
the offset of base in brw_shader is 0. Then brw_dump_ir will see a
NULL pointer and not do anything. This is why this does not crash at
the moment. However, this does not look very safe (it would crash
for any location of base that is not the first in brw_shader), so
patch it to prevent a potential (even if unlikely) problem in the
future.

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>

mesa/uniforms: fix get_uniform for doubles (v2)

The initial glGetUniformdv support didn't cover all the
casting cases that are apparantly legal, and cts seems to
test for them.

I've updated the piglit test to cover these cases now.

v2: fix indentation - it's all broken in this file (Ilia)
fix src/dst index tracking in light of fp64 support (Ilia)

cc: "11.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Dave Airlie <airlied@redhat.com>

ilo: improve Gen8 defines based on its PRMs

i965/vec4: Implement b2f and b2i using negation.

Curro added this in commit 3ee2daf23d (before the vec4/NIR backend was
added) but it was missed in the new NIR backend. Add it there as well.

instructions in affected programs:     1857 -> 1810 (-2.53%)
helped:                                15

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

nv50,nvc0: don't base decisions on available pushbuf space

We still have to push everything out, might as well kick earlier and
flip pushbufs when we know we'll need it. This resolves some issues with
the new policy of making sure that we always leave a bit of room at the
end for fences.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Fixes: 47d11990b (nouveau: make sure there's always room to emit a fence)
Cc: mesa-stable@lists.freedesktop.org

nouveau: avoid emitting new fences unnecessarily

Right now we emit on every kick, but this is only necessary if something
will ever be able to observe that the fence completed. If there are no
refs, leave the fence alone and emit it another day.

This also happens to work around an issue for the kick handler -- a kick
can be a result of e.g. nouveau_bo_wait or explicit kick, or it can be
due to lack of space in the pushbuf. We want the emit to happen in the
current batch, so we want there to always be enough space. However an
explicit kick could take the reserved space for the implicitly-triggered
kick's fence emission if it happened right after. With the new mechanism,
hopefully there's no way to cause two fences to be emitted into the same
reserved space.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Fixes: 47d11990b (nouveau: make sure there's always room to emit a fence)
Cc: mesa-stable@lists.freedesktop.org

nvc0: make use of NVC0_COMPUTE_CLASS for GF110

In theory, GF110+ should also support NVC8_COMPUTE_CLASS but, in practice,
a ILLEGAL_CLASS dmesg fail appears when using it.

This fixes compute support and MP performance counters on GF110.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>

i965/gs: Make MAX_GS_INPUT_VERTICES a #define in brw_context.h.

For scalar VS, I'll need this in brw_fs.cpp as well.  It seems silly to
redeclare it in three places.

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

i965/vs: Map scalar VS input locations properly; avoid tons of MOVs.

Previously, we used nir_lower_io with the scalar type_size function,
which mapped VERT_ATTRIB_* locations to...some numbers.  Then, in
fs_visitor::nir_setup_inputs(), we created temporaries indexed by
those numbers, and emitted MOVs from the actual ATTR registers to
those temporaries.  Virtually all of these were copy propagated away,
but it's still ugly.

This patch reworks our input lowering to produce NIR lower_input
intrinsics that properly index into the ATTR file, so we can access
it directly.

No changes in shader-db.

v2: Fix unreachable() message (Ken), update commit message (Matt).

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

i965/vs: Fix a subtlety in the nr_attributes == 0 workaround.

nr_attributes is used to compute first_non_payload_grf, which is the
first register we're allowed to use for ordinary register allocation.

The hardware requires us to read at least one pair of values, but we're
completely free to overwrite that garbage register with whatever we like.

Instead of altering nr_attributes, we should alter urb_read_length, which
only affects the amount we ask the VF to read.  This should save us a
register in trivial cases (which admittedly isn't very useful).

While we're at it, improve the explanation in the comments.

v2: Actually do what I said (caught by Ilia).

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

i965/vs: Unify URB entry size/read length calculations between backends.

Both the vec4 and scalar VS backends had virtually identical URB entry
size and read length calculations.  We can move those up a level to
backend-agnostic code and reuse it for both.

Unfortunately, the backends need to know nr_attributes to compute
first_non_payload_grf, so I had to store that in prog_data.  We could
use urb_read_length, but that's nr_attributes rounded up to a multiple
of two, so doing so would waste a register in some cases.

There's more code to be removed in the vec4 backend, but that will
come in a follow-on patch.

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

i965/cfg: Fix cfg_t::dump() when a block has no immediate dominator.

Switch statements introduce a bogus loop with an unconditional break at
the end of the loop, just before the while...so the while is unreachable
and has no immediate dominator.

v2: With less exuberance

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

docs: add news item and link release notes for 11.0.3

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

docs: add sha256 checksums for 11.0.3

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

docs: add release notes for 11.0.3

Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
(cherry picked from commit 914966befcd57764941405707d8f57d3e7e7f768)

i965/gen8: Remove gen<8 checks in gen8 code

Some assertions in gen8_surface_state.c checked for gen < 8.

Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>

i965/gen9: Enable rep clears on gen9

The (gen < 9) check in brw_clear() was too broad. It disabled all types
of fast color clears:
    a. singlesample rep clears
    b. singlesample MCS fast clears
    c. multisample MCS fast clears

The MCS clears are still buggy, but the rep clear works well. So let's
enable it.

Reviewed-by: Neil Roberts <neil@linux.intel.com>

i965/gen9: Disable MCS for 1x color surfaces

Fast color clears are disabled for gen9 (see the checks in
brw_meta_fast_clear), so there is no reason to allocate the MCS and
track its clear/resolve state.

Reviewed-by: Neil Roberts <neil@linux.intel.com>

tgsi: (trivial) kill c99-ism.

program: remove _mesa_init_*_program wrappers

They didn't do anything useful.

Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

program: remove other unused functions

Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

program: remove unused cloning and combining functions

Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

program: remove unused function _mesa_find_line_column

Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

st/mesa: release the glsl_to_tgsi visitor after translation

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

st/mesa: translate tessellation shaders into TGSI when we get them

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

st/mesa: translate geometry shaders into TGSI when we get them

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

st/mesa: translate fragment shaders into TGSI when we get them

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

st/mesa: translate vertex shaders into TGSI when we get them

The translate functions is split into two:
- translation to TGSI
- creating the variant (TGSI transformations only)

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

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>