intel/fs: Don't use automatic exec size inference

The automatic exec size inference can accidentally mess things up if
we're not careful.  For instance, if we have

add(4)    g38.2<4>D    g38.1<8,2,4>D    g38.2<8,2,4>D

then the destination register will end up having a width of 2 with a
horizontal stride of 4 and a vertical stride of 8.  The EU emit code
sees the width of 2 and decides that we really wanted an exec size of 2
which doesn't do what we wanted.

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

intel/fs: Explicitly set EXECUTE_1 where needed

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

intel/eu: Explicitly set EXECUTE_1 where needed

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

intel/eu: Make automatic exec sizes a configurable option

We have had a feature in codegen for some time that tries to
automatically infer the execution size of an instruction from the width
of its destination.  For things such as fixed function GS, clipper, and
SF programs, this is very useful because they tend to have lots of
hand-rolled register setup and trying to specify the exec size all the
time would be prohibitive.  For things that come from a higher-level IR,
however, it's easier to just set the right size all the time and the
automatic exec sizes can, in fact, cause problems.  This commit makes it
optional while enabling it by default.

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

intel/fs: Rework zero-length URB write handling

Originally we tried to handle this case based on slots_valid.  However,
there are a number of ways that this can go wrong.  For one, we throw
away any trailing slots which either aren't written or are set to
VARYING_SLOT_PAD.  Second, even if PSIZ is a valid slot, we may not
actually write anything there.  Between the lot of these, it was
possible to end up in a case where we tried to do a regular URB write
but ended up with a length of 1 which is invalid.  This commit moves it
to the end and makes it based on a new boolean flag urb_written.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable@lists.freedesktop.org

intel/compiler/fs: Set up subgroup invocation as a system value

Subgroup invocation is computed using a vector immediate and some
dispatch-aware arithmetic.  Unfortunately, due to the vector arithmetic,
and the fact that it's frequently read 16-wide, it's not something that
can easily be CSEd by the back-end compiler.  There are a few different
possible approaches to this problem:

 1) Emit the code to calculate the subgroup invocation on-the-fly and
    trust NIR to do the CSE.  This is what we were doing.

 2) Add a back-end instruction for the subgroup ID.  This has the
    advantage of helping the back-end compiler with CSE but has the
    downside of very poor scheduling for the calculation because it has
    to be emitted in the back-end.

 3) Emit the calculation at the top of the program and re-use the
    result.  This gets rid of the CSE problem but comes at the cost of
    an extra live register.

This commit switches us from 1) to 3).  We choose to store the subgroup
invocation values as a W type to reduce the impact of the extra live
register.  Trusting NIR and using 1) was fine but we're soon going to
want to use the subgroup invocation value for other things in the
back-end compiler and this makes it much easier to do without having to
worry about CSE problems.

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

intel/cs: Push subgroup ID instead of base thread ID

We're going to want subgroup ID for SPIR-V subgroups eventually anyway.
We really only want to push one and calculate the other from it.  It
makes a bit more sense to push the subgroup ID because it's simpler to
calculate and because it's a real API thing.  The only advantage to
pushing the base thread ID is to avoid a single SHL in the shader.

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

intel/cs: Re-run final NIR optimizations for each SIMD size

With the advent of SPIR-V subgroup operations, compute shaders will have
to be slightly different depending on the SIMD size at which they
execute.  In order to allow us to do dispatch-width specific things in
NIR, we re-run the final NIR stages for each sIMD width.

One side-effect of this change is that we start rallocing fs_visitors
which means we need DECLARE_RALLOC_CXX_OPERATORS.

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

intel/compiler: Move the destructor from vec4_visitor to backend_shader

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

i965/fs: Get rid of the early return in brw_compile_cs

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

intel/cs: Rework the way thread local ID is handled

Previously, brw_nir_lower_intrinsics added the param and then emitted a
load_uniform intrinsic to load it directly.  This commit switches things
over to use a specific NIR intrinsic for the thread id.  The one thing I
don't like about this approach is that we have to copy thread_local_id
over to the new visitor in import_uniforms.

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

intel/fs: Mark 64-bit values as being contiguous

This isn't often a problem , when we're in a compute shader, we must
push the thread local ID so we decrement the amount of available push
space by 1 and it's no longer even and 64-bit data can, in theory, span
it.  By marking those uniforms contiguous, we ensure that they never get
split in half between push and pull constants.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable@lists.freedesktop.org

intel/cs: Ignore runtime_check_aads_emit for CS

It's only set on gen4-5 which clearly don't support compute shaders.

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

intel/cs: Stop setting dispatch_grf_start_reg

Nothing ever reads it for compute shaders because it's always 1.

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

intel/cs: Drop max_dispatch_width checks from compile_cs

The only things that adjust fs_visitor::max_dispatch_width are render
target writes which don't happen in compute shaders so they're
pointless.

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

intel/fs: Remove min_dispatch_width from fs_visitor

It's 8 for everything except compute shaders.  For compute shaders,
there's no need to duplicate the computation and it's just a possible
source of error.

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

intel/fs: use pull constant locations to check for first compile of a shader

Before, we bailing in assign_constant_locations based on the minimum
dispatch size.  The more direct thing to do is simply to check for
whether or not we have constant locations and bail if we do.  For
nir_setup_uniforms, it's completely safe to do it multiple times because
we just copy a value from the NIR shader.

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

intel/fs: Retype dest to match value in read[First]Invocation

This is what we really wanted all along.  Always retyping to D works
because that's what get_nir_src() always gives us, at least for 32-bit
types.  The SPIR-V variants of these operations accept arbitrary types
and we need this if we're going to handle 64 or 16-bit values.

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

intel/fs: Uniformize the index in readInvocation

The index is any value provided by the shader and this can be called in
non-uniform control flow so we can't just take component 0.  Found by
inspection.

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

intel/fs: Protect opt_algebraic from OOB BROADCAST indices

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

i965/fs/nir: Don't stomp 64-bit values to D in get_nir_src

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

i965/fs/nir: Minor refactor of store_output

Stop retyping the output of shuffle_64bit_data_for_32bit_write.  It's
always BRW_REGISTER_TYPE_D which is perfectly fine for writing out.
Also, when we change get_nir_src to return something with a 64-bit type
for 64-bit values, the retyping will not be at all what we want.  Also,
retyping the output based on src.type before we whack it back to 32 bits
is a problem because the output is always 32 bits.

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

i965/fs: Return a fs_reg from shuffle_64bit_data_for_32bit_write

All callers of this function allocate a fs_reg expressly to pass into
it.  It's much easier if we just let the helper allocate the register.
While we're here, we switch it to doing the MOVs with an integer type so
that we don't accidentally canonicalize floats on half of a double.

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

i965/fs/nir: Simplify 64-bit store_output

The swizzles weren't doing any good because swiz is just XYZW.  Also, we
were emitting an extra set of MOVs because shuffle_64bit_data_for_32bit
already does a MOV for us.  Finally, the temporary was only ever used
inside the inner loop so there's no need for it to actually be an array.

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

intel/fs: Use the original destination region for int MUL lowering

Some hardware (CHV, BXT) have special restrictions on register regions
when doing integer multiplication.  We want to respect those when we
lower to DxW multiplication.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable@lists.freedesktop.org

intel/fs: Fix integer multiplication lowering for src/dst hazards

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable@lists.freedesktop.org

intel/fs: Fix MOV_INDIRECT for 64-bit values on little-core

The same workaround we need for 64-bit values on little core also takes
care of the Ivy Bridge problem and does so a bit more efficiently so we
can drop that code while we're here.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable@lists.freedesktop.org

intel/eu: Fix broadcast instruction for 64-bit values on little-core

We're not using broadcast for any 32-bit types right now since we mostly
use it for emit_uniformize on 32-bit buffer indices.  However, SPIR-V
subgroups are going to need it for 64-bit so let's make it work.

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

intel/eu/reg: Add a subscript() helper

This is similar to the identically named fs_reg helper.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable@lists.freedesktop.org

intel/eu: Just modify the offset in brw_broadcast

This means we have to drop const from a variable but it also means that
100% of the code which deals with the offset limit is in one place.

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

intel/compiler: Add some restrictions to MOV_INDIRECT and BROADCAST

These restrictions effectively already existed due to the way we use
indirect sources but weren't being directly enforced.

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

intel/fs: Use a pair of 1-wide MOVs instead of SEL for any/all

For some reason, the any/all predicates don't work properly with SIMD32.
In particular, it appears that a SEL with a QtrCtrl of 2H doesn't read
the correct subset of the flag register and you end up getting garbage
in the second half.  Work around this by using a pair of 1-wide MOVs and
scattering the result.  This fixes the any/all instructions for SIMD32.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: mesa-stable@lists.freedesktop.org

intel/fs: Use an explicit D type for vote any/all/eq intrinsics

The any/all intrinsics return a boolean value so D or UD is the correct
type.  Unfortunately, get_nir_dest has the annoying behavior of
returnning a float type by default.  This causes format conversion which
gives us -1.0f or 0.0f in the register.  If the consumer of the result
does an integer comparison to zero, it will give you the right boolean
value but if we do something more clever based on the 0/~0 assumption
for booleans, this will give the wrong value.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable@lists.freedesktop.org

intel/fs: Don't stomp f0.1 in SIMD16 ballot

In fragment shaders f0.1 is used for discards so doing ballot after a
discard can potentially cause the discard to not happen.  However, we
don't support SIMD32 fragment shaders yet so this isn't a problem.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable@lists.freedesktop.org

intel/fs: Use ANY/ALL32 predicates in SIMD32

We have ANY/ALL32 predicates and, for the most part, they work just
fine.  (See the next commit for more details.)  Also, due to the way
that flag registers are handled in hardware, instruction splitting is
able to split the CMP correctly.  Specifically, that hardware looks at
the execution group and knows to shift it's flag usage up correctly so a
2H instruction will write to f0.1 instead of f0.0.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Cc: mesa-stable@lists.freedesktop.org

intel/fs: Be more explicit about our placement of [un]zip

Before, we were careful to place the zip after the last of the split
instructions but did unzip on-demand.  This changes things so that the
unzips go before all of the split instructions and the unzip comes
explicitly after all the split instructions.  As a side-effect of this
change, we now emit the split instruction from highest SIMD group to
lowest instead of low to high.  We could have kept the old behavior, but
it shouldn't matter and this made the code easier.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable@lists.freedesktop.org

intel/fs: Pass builders instead of blocks into emit_[un]zip

This makes it far more explicit where we're inserting the instructions
rather than the magic "before and after" stuff that the emit_[un]zip
helpers did based on block and inst.

Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Cc: mesa-stable@lists.freedesktop.org

intel/fs: Use a pure vertical stride for large register strides

Register strides higher than 4 are uncommon but they can happen.  For
instance, if you have a 64-bit extract_u8 operation, we turn that into
UB -> UQ MOV with a source stride of 8.  Our previous calculation would
try to generate a stride of <32;8,8>:ub which is invalid because the
maximum horizontal stride is 4.  To solve this problem, we instead use a
stride of <8;1,0>.  As noted in the comment, this does not work as a
destination but that's ok as very few things actually generate that
stride.

Reviewed-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Cc: mesa-stable@lists.freedesktop.org

broadcom/vc5: Skip emitting textures that aren't used.

Fixes crashes when ARB_fp uses texture[1] but not 0, as in piglit's
fp-fragment-position.

broadcom/vc5: Add missing SRGBA8 ETC2 support.

Fixes piglit oes_compressed_etc2_texture-miptree srgb8-alpha8.

broadcom/vc5: Disable early Z test when the FS writes Z.

Fixes piglit early-z.

broadcom/vc5: Shift the min/max lod fields by the BASE_LEVEL.

The lod clamping is what limits you between base and last level, and the
base level field is just there to help decide where the min/mag change
happens.

Fixes tex-miplevel-selection GL2:texture()

broadcom/vc5: Add support for anisotropic filtering.

broadcom/vc5: Fix mipmap filtering enums.

The ordering of the values was even less obvious than I thought, with both
the mip filter and the min filter being in different bits depending on
whether the mip filter is none.

Fixes piglit fs-textureLod-miplevels.shader_test

broadcom/vc5: Fix height padding of small UIF slices.

The HW doesn't pad the slice's height to make a full 4x4 group of UIF
blocks.  We just need to pad to columns, and the start of the next column
appears in the bottom of the previous column's last block.

Fixes piglit fs-textureOffset-2D.

broadcom/vc5: Print the actual offsets in HW for our resource layout debug.

The alignment of level 0 is non-obvious, so it's hard to turn a faulting
address into a slice without this.

broadcom/vc5: Set the available VS outputs to match the FS inputs.

Fixes piglit glsl-es-3.00/minimum-maximums.txt.

broadcom/vc5: Set the max texture LOD bias.

The field is signed 8.8, so the usual 16.0f fits.  Fixes piglit
gl-2.1-minmax.

broadcom/vc5: Fix translation of stencil ops.

They aren't quite in the same order as the gallium defines.  Fixes piglit
gl-2.0-two-sided-stencil.

broadcom/vc5: Move stencil state packing to the CSO.

Only the stencil ref comes in as dynamic state at emit time.

broadcom/vc5: Introduce a helper for pre-packing our V3DXX structs.

This is so much more pleasant to write than the manual
V3D33_whatever_pack() calls, and will be useful for when we start doing
actual per-V3D compiles.

broadcom/vc5: Add a cl_emit() variant for merging with a pre-packed struct.

Cleans up the hand-written code, at the cost of another ugly macro.

broadcom/vc5: Skip emitting depth offset while disabled.

The enable flag is also in the rasterizer state, so it will be emitted
once it's needed.

broadcom/vc5: Don't emit stencil config if not doing stencil test.

As with blending, we'll have the bit flagged again when it gets reenabled
in CONFIGURATION_BITS, so there's no need to emit test state if we're not
testing.

broadcom/vc5: Don't emit updated blend factors/funcs while disabled.

The dirty bit will be flagged again when re-enbaled.  Keeps us from
emitting blend state in CLs that never do blending.

broadcom/vc5: Fix missing enum decode for indexed primitives.

broadcom/vc5: Drop padding bits from the bottom of the TSDA address.

Fixes misaligned-looking addresses in decode.

broadcom/vc5: Make sure the TMU indirect struct is appropriately aligned.

I was hoping that this would help with fbo-generatemipmap hangs, but no
luck.

broadcom/genxml: Fix decoding of groups with small fields.

Groups containing fields smaller than a byte probably not being decoded
correctly.  For example:

    <group count="32" start="32" size="4">
      <field name="Vertex Element Enables" start="0" end="3" type="uint"/>
    </group>

gen_field_iterator_next would properly walk over each element of the
array, incrementing group_iter.  However, the code to print the actual
values only considered iter->field->start/end, which are 0 and 3 in the
above example.  So it would always fetch bits 3:0 of the current byte,
printing the same value over and over.

Cc: Eric Anholt <eric@anholt.net>

broadcom/vc5: Use DEPTH24_STENCIL8 for rendering to depth-only textures.

The HW puts the pad bits at the top for DEPTH_COMPONENT24, but we need it
at the bottom for texturing.  Using the format with stencil probably means
we won't be able to do Z24 and separate S8, but I wasn't planning on
supporting that anyway.

Fixes hiz-depth-read-fbo-d24-s0

anv: Suffix anv-private 'VK' tokens with 'ANV'

I saw VK_IMAGE_ASPECT_ANY_COLOR_BIT while hacking anv_formats.c and got
confused. "Huh? What extension added that?". No extension defines it;
anv_private.h defines it.

To remove confusion, rename the anv-private VK tokens as if they were
extension tokens with the ANV vendor suffix.

I found only two such tokens:

    VK_IMAGE_ASPECT_ANY_COLOR_BIT
    VK_IMAGE_ASPECT_PLANES_BITS

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

anv: Remove unused variable 'gen'

In anv_physical_device_get_format_properties().

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>

radeonsi: add si_screen::has_ls_vgpr_init_bug

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi: use ac_create_target_machine

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi: use ac_get_llvm_processor_name

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi/gfx9: don't set gs_table_depth

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi/gfx9: limit the scissor bug workaround to Vega10 and Raven only

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>

radeonsi: remove unused field in the PCI ID table

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

mesa: fix deleting the dummy ATI_fs

The DummyShader is used by GenFragmentShadersATI() as a placeholder to
mark IDs as allocated. Context cleanup wants to delete everything in
ctx->Shared->ATIShaders, and crashes on these placeholders with this
backtrace:
==15060== Invalid free() / delete / delete[] / realloc()
==15060==    at 0x482F478: free (vg_replace_malloc.c:530)
==15060==    by 0x57694F4: _mesa_delete_ati_fragment_shader (atifragshader.c:68)
==15060==    by 0x58B33AB: delete_fragshader_cb (shared.c:208)
==15060==    by 0x5838836: _mesa_HashDeleteAll (hash.c:295)
==15060==    by 0x58B365F: free_shared_state (shared.c:377)
==15060==    by 0x58B3BC2: _mesa_reference_shared_state (shared.c:469)
==15060==    by 0x578687F: _mesa_free_context_data (context.c:1366)
==15060==    by 0x595E9EC: st_destroy_context (st_context.c:642)
==15060==    by 0x5987057: st_context_destroy (st_manager.c:772)
==15060==    by 0x5B018B6: dri_destroy_context (dri_context.c:217)
==15060==    by 0x5B006D3: driDestroyContext (dri_util.c:511)
==15060==    by 0x4A1CBE6: dri3_destroy_context (dri3_glx.c:170)
==15060==  Address 0x7b5dae0 is 0 bytes inside data symbol "DummyShader"

Also, DeleteFragmentShadersATI() should not assert on DummyShader, just
remove the hash entry.

Normally one would define a shader after GenFragmentShadersATI(), and
BindFragmentShaderATI() replaces the placeholder with a real object.
However, the specification doesn't say that one has to define a shader
for each allocated ID.

Signed-off-by: Miklós Máté <mtmkls@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>

gallium: Guard assertions by NDEBUG instead of DEBUG

This matches the standard assert.h header.

Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

meson: only turn on Mesa's DEBUG for buildtype==debug

As discussed in this thread:
https://lists.freedesktop.org/archives/mesa-dev/2017-November/175104.html

Cc: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Acked-by: Andres Rodriguez <andresx7@gmail.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Tested-by: Chad Versace <chadversary@chromium.org>

meson: switch default build type to debugoptimized

As discussed in this thread:
https://lists.freedesktop.org/archives/mesa-dev/2017-November/175104.html

Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Michel Dänzer <michel@daenzer.net>
Cc: Christian Schmidbauer <ch.schmidbauer@gmail.com>
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Cc: Ernst Sjöstrand <ernstp@gmail.com>
Signed-off-by: Eric Engestrom <eric.engestrom@imgtec.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Acked-by: Andres Rodriguez <andresx7@gmail.com>
Acked-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Reviewed-by: Chad Versace <chadversary@chromium.org>
Tested-by: Chad Versace <chadversary@chromium.org>

meson: drop GLESv1 .so version back to 1.0.0

autotools generates libGLESv1_CM.so.1.0.0, so let's make sure meson
does the same.

Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>

meson: standardize .so version to major.minor.patch

This `version` field defines the filename for the .so.
The plan .so as well as .so.$major are always symlinks to this.

Unless I'm mistaken, only the major is ever used, so this shouldn't
matter, but for consistency with autotools (and in case it does matter),
let's always have all 3 major.minor.patch components.

(The soname isn't affected, and is always .so.$major)

Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>

ac/nir: for ubo load use correct num_components

I was hacking something stupid in doom, and hit an assert for the bitcast
following this, it definitely looks like this should be the number of 32-bit
components, not the instr level ones.

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

nir: fix a typo

Signed-off-by: Mun Gwan-gyeong <elongbug@gmail.com>
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>

glsl: Allow precision mismatch on dead data with GLSL ES 1.00

Commit 259fc505454ea6a67aeacf6cdebf1398d9947759 added linker error for
mismatching uniform precision, as required by GLES 3.0 specification and
conformance test-suite.

Several Android applications, including Forge of Empires, have shaders
which violate this rule, on a dead varying that will be eliminated.
The problem affects a big number of applications using Cocos2D engine
and other GLES implementations accept this, this poses a serious
application compatibility issue.

Starting from GLSL ES 3.0, declarations with conflicting precision
qualifiers are explicitly prohibited. However GLSL ES 1.00 does not
clearly specify the behavior, except that

  "Uniforms are defined to behave as if they are using the same storage in
  the vertex and fragment processors and may be implemented this way.
  If uniforms are used in both the vertex and fragment shaders, developers
  should be warned if the precisions are different. Conversion of
  precision should never be implicit."

The word "used" is not clear in this context and might refer to
 1) declared (same as GLES 3.x)
 2) referred after post-processing, or
 3) linked after all optimizations are done.

Looking at existing applications, 2) or 3) seems to be widely adopted.
To avoid compatibility issues, turn the error into a warning if GLSL ES
version is lower than 3.0 and the data is dead in at least one of the
shaders.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97532
Signed-off-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965: disable NIR linking on HSW and below

Fixes: 379b24a40d3d "i965: make use of nir linking"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103537
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>

radv: move is_local up to the winsys level.

We can avoid adding the buffer in the non-local case, this will
avoid all the overhead of the indirect call.

Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

radv: wrap cs_add_buffer in an inline. (v2)

The next patch will try and avoid calling the indirect function.

v2: add a missing conversion.

Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

radv: when loading regs no need to add buffer

The function that calls us has just added the buffer to the
list already, no need to try and add it again.

Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

radv: pre-calculate user_data_0 registers and store in pipeline

There's no point recalculating these the whole time on descriptor
emission, just store them at pipeline creation.

Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

docs: Mark GLX_ARB_context_flush_control done

Requires an unreleased X server, but from the client GLX side this is as
done as it gets.

Signed-off-by: Adam Jackson <ajax@redhat.com>

i965: Enable flush control

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Neil Roberts <neil@linux.intel.com>

drisw: Enable flush control for llvmpipe and softpipe

Hilariously this is a fairly big win.  Neil's multi-context-test
improves from ~24 to ~36 fps with llvmpipe on a Core i5-3317U.  softpipe
also improves, from about 2.25 to 3.09 fps (when it's that slow, you're
allowed to be that precise).

I'd have added it to swrast classic, but the testcase wants GL 3.0 and
shaders, and that's not a thing classic has, so I figured making it work
on softpipe was crime enough.

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>

gallium: Wire up flush control

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>

egl: Implement EGL_KHR_context_flush_control

Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>

glx: Implement GLX_ARB_context_flush_control

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Neil Roberts <neil@linux.intel.com>

dri: Add a flush control extension

This advertises that the driver can accept a new context attribute
__DRI_CTX_ATTRIB_RELEASE_BEHAVIOR.

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Neil Roberts <neil@linux.intel.com>

dri: Change __DriverApiRec::CreateContext to take a struct for attribs

Previously the CreateContext method of __DriverApiRec took a set of
arguments to describe the attribute values from the window system API's
CreateContextAttribs function. As more attributes get added this could
quickly get unworkable and every new attribute needs a modification for
every driver.

To fix that, pass the attribute values in a struct instead.  The struct
has a bitmask to specify which members are used. The first three members
(two for the GL version and one for the flags) are always set. If the
bit is not set in the attribute mask then it can be assumed the
attribute has the default value. Drivers will error if unknown bits in
the mask are set.

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Neil Roberts <neil@linux.intel.com>

intel: Don't flush the old context in intelMakeCurrent

It shouldn't be necessary to flush the context within the driver
implementation because the old context is explicitly flushed in
_mesa_make_current which is called a little further on. It is useful to
only have a single place that flushes when switching contexts to make it
easier to later implement the GL_KHR_context_flush_control extension.

The flush in intelMakeCurrent was added in commit 5505865 to implement
the GLX semantics that the context should be flushed when it is
released.  When the commit was made there was no flush in
_mesa_make_current because it was only added later in 93102b4c. I think
that later commit effectively makes the first commit redundant.

Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Neil Roberts <neil@linux.intel.com>

egl/dri2: Factor out context attribute initialization

Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>

etnaviv: Don't over-pad compressed textures

HALIGN_FOUR/SIXTEEN has no meaning for compressed textures, and we can't
render to them anyway. So use the tightest possible packing. This
avoids bugs with non-power-of-two block sizes.

Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

etnaviv: ASTC texture support

Add ASTC texture support for hardware that supports this
(currently only GC3000 on i.MX6qp is known to have this).

Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

etnaviv: Update from rnndb

Updated as of etnav_viv commit 3b4a8ec.

Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

radv: add initial copy descriptor support. (v2)

It appears the latest dota2 vulkan uses this,
and we get a hang in VR mode without it.

v2: remove finishme I left in after finishing.

Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Andres Rodriguez <andresx7@gmail.com>
Cc: "17.2 17.3" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

gallium/u_vbuf: use signed vertex buffers offsets for optimal uploads

Uploaded data must start at (stride * start), because we can't modify
start in all cases. If it's the first allocation, it's also the amount
of memory wasted. If the starting offset is larger than the size of
the upload buffer, the buffer is re-created, used for 1 upload, and then
thrown away. If the upload is small, most of the buffer space is unused
and wasted. Keep doing that and the OOM killer comes. It's actually
pretty quick.

With signed VB offsets, we can set min_out_offset = 0
in u_upload_alloc/u_upload_data.

This fixes OOM situations with SPECviewperf.

radeonsi: enable signed vertex buffer offsets

gallium: add PIPE_CAP_SIGNED_VERTEX_BUFFER_OFFSET

automake: include git_sha1.h.in in release tarball

Fixes:

make[2]: Leaving directory '/home/local/mesa/mesa-17.4.0-devel/_build/sub/src'
make[2]: *** No rule to make target '../../../src/git_sha1.h.in', needed by 'git_sha1.h'.  Stop.
Makefile:660: recipe for target 'all-recursive' failed

Fixes: 16be271c6ee618e79c7d "git_sha1_gen: use git_sha1.h.in on all build systems"
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>