gallium/hud: add an option to rename each data source

useful for radeonsi performance counters

v2: allow specifying both : and =

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

gallium: remove TGSI_OPCODE_SUB

It's redundant with the source modifier.

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

gallium: remove TGSI_OPCODE_ABS

It's redundant with the source modifier.

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

st/nine: Remove all usage of ureg_SUB in nine_shader

This is required to drop gallium SUB.

Signed-off-by: Axel Davy <axel.davy@ens.fr>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>

st/nine: Remove all usage of ureg_SUB in nine_ff

This is required to remove gallium SUB.

Signed-off-by: Axel Davy <axel.davy@ens.fr>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>

st/nine: Do not map SUB and ABS to their gallium equivalent.

This is required for gallium SUB and ABS to be removed.

Signed-off-by: Axel Davy <axel.davy@ens.fr>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>

configure: Fix another bashism.

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

st/mesa: fix a segfault when prog->sh.data is NULL

Broken by:
   st/mesa: get Version from gl_program rather than gl_shader_program

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

docs: add news item and link release notes for 13.0.3

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

docs: add sha256 checksums for 13.0.3

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

docs: add release notes for 13.0.3

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

st/va: fix incorrect argument in vl_compositor_cleanup

This fixes the mistake introduced in commit
b6737a8bcd03ea68952799144c0c6e6e6679bee9

Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

swr: remove unneeded llvm version check

Old test caused breakage with llvm-svn (4.0.0svn), and not needed as
the minimum required llvm version for swr is 3.6.

Reviewed-by: George Kyriazis <george.kyriazis@intel.com>

swr: fix windows build break

wrap lp_bld_type.h around extern "C".
Windows decorates global variables, so when used from .cpp files, need
to use an undecorated version.

Also, removed related and unneeded code from swr_screen.cpp

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>

radeonsi: update clip_regs if clip_disable changes to fix a hang

This seems to fix the GPU hangs caused by:

commit ed3190b3f3a776fc8c75b1e6130a88079166d115
Author: Marek Olšák <marek.olsak@amd.com>
Date:   Sun Nov 13 18:41:43 2016 +0100

    radeonsi: don't export ClipVertex and ClipDistance[] if clipping is disabled

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99219

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

st/mesa: enable GLSLOptimizeConservatively for drivers that want it

GLSL compilation now takes 24% less time with the Gallium noop driver.
I used my shader-db for the measurement. The difference for the whole
radeonsi driver can be ~10%.

The generated TGSI is mostly the same. For example, the compilation success
rate with a TGSI->GCN bytecode converter without any optimizations is
the same. Note that glsl_to_tgsi does its own copy propagation and simple
register allocation.

shader-db GCN report:
- Talos spills fewer SGPRs.
- DOTA 2 spills more SGPRs.
- The average shader-db score is better, but it's just due to randomness.

29045 shaders in 17564 tests
Totals:
SGPRS: 1325929 -> 1325017 (-0.07 %)
VGPRS: 1010808 -> 1010172 (-0.06 %)
Spilled SGPRs: 1432 -> 1399 (-2.30 %)
Spilled VGPRs: 93 -> 92 (-1.08 %)
Private memory VGPRs: 688 -> 688 (0.00 %)
Scratch size: 2540 -> 2484 (-2.20 %) dwords per thread
Code Size: 39336732 -> 39342936 (0.02 %) bytes
Max Waves: 217937 -> 217969 (0.01 %)

Reviewed-by: Eric Anholt <eric@anholt.net>

glsl_to_tgsi: do fewer optimizations with GLSLOptimizeConservatively

Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: add gl_constants::GLSLOptimizeConservatively

to reduce the amount of GLSL optimizations for drivers that can do better.

Reviewed-by: Eric Anholt <eric@anholt.net>

gallium: add PIPE_CAP_GLSL_OPTIMIZE_CONSERVATIVELY

Drivers with good compilers don't need aggressive optimizations before TGSI.

Reviewed-by: Eric Anholt <eric@anholt.net>

glsl: run do_lower_jumps properly in do_common_optimizations

so that backends don't have to run it manually

Reviewed-by: Eric Anholt <eric@anholt.net>

i965: Print VS output VUE map in Vulkan too.

We need to move this to the shared layer.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>

i965: Fix last slot calculations

If the VUE map has slots at the end which the shader does not write,
then we'd "flush" (constructing an URB write) on the last output it
actually wrote.  Then, we'd construct another SEND with EOT, but with
no actual payload data.  That's not legal.

For example, SSO programs have clip distance slots allocated no matter
what, but the shader may not write them.  If it doesn't write any user
defined varyings, then the clip distance slots will be the last ones.

Found while debugging
dEQP-VK.tessellation.shader_input_output.gl_position_vs_to_tcs_to_tes

Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>

docs: Mark GL_ARB_gpu_shader_fp64 and OpenGL 4.0 as done for i965/hsw+

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

docs: add GL_ARB_gpu_shader_fp64 and OpenGL 4.0 support for Intel Haswell.

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

i965: add a kernel_features bitfield to intel screen

We can use this to track various features that may or may not be supported
by the hw / kernel. Currently, we usually do this by checking the generation
and supported command parser versions in various places thoughtout the driver
code. With this patch, we centralize all these checks in just once place at
screen creation time, then we just query the bitfield wherever we need to
check if a particular feature is supported.

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

i965/gen7: Enable OpenGL 4.0 in Haswell when supported

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

i965: get rid of brw->can_do_pipelined_register_writes

Instead, check the screen field directly.

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

i965: Move the pipelined test for SO register access to the screen

Moving the test to the screen places it alongside the other global HW
feature tests that want to be shared between contexts.

Also, we need to know if we support pipelined register writes at
screen creation time so that we can tell if we can expose OpenGL 4.0
in gen7.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

i965/disasm: remove printing hstride and width in align16 DF source regions

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

vec4: use DIM instruction when loading DF immediates in HSW

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

glcpp: Remove illegal characters from tests

Some of the existing tests were using '@' and '"' incidentally within the test
body. Neither of these characters are actually legal for GLSL. And since we
are planning to start generating errors for illegal characters, we need to
first make the test suite clean.

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

glcpp: Exhaustively test all legal characters in GLSL

Here, each legal character (as defined by GLSL Language Specification version
4.30.6, section 3.1) appears at least once in the input file. Obviously,
characters with special meaning (like '#' and '\') aren't treated exhaustively
with respect to all their possible uses. We have many other tests for that.

Here, we're simply ensuring that the test suite sees every legal character at
least once.

v2 (by Ken): Fix expectations, move to src/compiler, renumber tests.

   Carl's .expected:            Updated .expected:

   ..                           ..

   . .                          . .
   . .                          . .
   . .                          . .
   . .                          . .
   .                            ..
   .                            .
   .                            .
   .

(For some reason, the original test expected ".." to produce two lines.
glcpp, cpp, and mcpp all follow my updated behavior, so I believe it to
be correct.)

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

glcpp: Allow vertical tab and form feed characters in GLSL

Of course, these aren't really useful for anything, but the GLSL language
specification does allow them:

The source character set used for the OpenGL shading languages,
outside of comments, is a subset of UTF-8. It includes the following
characters:
...

White space: the space character, horizontal tab, vertical tab, form
feed, carriage-return, and line- feed.

[GLSL Language Specification 4.30.6, section 3.1]

So treat vertical tab ('\v' or ^K) and form-feed ('\f' or ^L) as horizontal
space characters.

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

glcpp: Add testing for no space between macro name and replacement list

GCC's preprocessor accepts a macro definition where there is no space between
the macro's identifier name and the replacementlist. (GCC does emit a "missing
space" warning that we don't, but that's fine.)

This is an exhaustive test that verifies that all legal GLSL characters that
could possibly be interpreted as separating the macro name from the
replacement list are interpreted as such. So the testing here includes all
valid GLSL symbols except for:

  * Characters that can be part of an identifier (a-z, A-Z, 0-9, _)

  * Backslash, (allowed only as line continuation)

  * Hash, (allowed only to introduce pre-processor directive, or as part of a
           paste operator in a replacement list---but not as first token of
           replacement list)

  * Space characters (since the point of the testing is to have missing space)

  * Left parenthesis (which would indicate a function-like macro)

v2 (Ken): Move to src/compiler, renumber tests.

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

spirv: compute push constant access offset & range

v2: Move relative push constant relative offset computation down to
    _vtn_load_store_tail() (Jason)

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

spirv: move block_size() definition

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

va: call texture_get_handle while the mutex is being held

The context may be used by texture_get_handle.

Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: 13.0 <mesa-stable@lists.freedesktop.org>

vdpau: call texture_get_handle while the mutex is being held

The context may be used by texture_get_handle.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99158

Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: 13.0 <mesa-stable@lists.freedesktop.org>

radeonsi: capitalize VM hex addr when dumping buffer list

Useful when debugging with R600_DEBUG=vm,check_vm to match
addr in both outputs.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

i965: remove unused brwInitVtbl declaration

function was removed by b3360d23ac1db61390b2ac8963756c6133ba6e23

Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>

i965: remove brw_context dependency from intel_batchbuffer_init()

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

i965: make intel_batchbuffer_free() take a batchbuffer as argument

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

i965: make intel_batchbuffer_emit_dword() take a batchbuffer as argument

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

i965: Make intel_bachbuffer_reloc() take a batchbuffer argument

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

nir: fix loop iteration count calculation for floats

Fixes performance regression in SynMark PSPom caused by loops with float
counters not always unrolling.

For example:

   for (float i = 0.02; i < 0.9; i += 0.11)
      ...

Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>

gallium/hud: add a path separator between dump directory and filename

It's more user friendly and it avoids to write files in unexpected
places.

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

r600/sb: Fix loop optimization related hangs on eg

Make sure unused ops and their references are removed, prior to entering
the GCM (global code motion) pass, to stop GCM from breaking the loop
logic and thus hanging the GPU.

Turns out, that sb has problems with loops and node optimizations
regarding associative folding:

- the global code motion (gcm) pass moves ops up a loop level/basic block
until they've fulfilled their total usage count
- if there are ops folded into others, the usage count won't be
fulfilled and thus the op moved way up to the top
- within GCM the op would be visited and their deps would be moved
alongside it, to fulfill the src constaints
- in a loop, an unused op is moved out of the loop and GCM would move
the src value ops up as well
- now here arises the problem: if the loop counter is one of the src
values it would get moved up as well, the loop break condition would
never get hit and the shader turn into an endless loop, resulting in the
GPU hanging and being reset

A reduced (albeit nonsense) piglit example would be:

[require]
GLSL >= 1.20

[fragment shader]

uniform int SIZE;
uniform vec4 lights[512];

void main()
{
    float x = 0;
    for(int i = 0; i < SIZE; i++)
        x += lights[2*i+1].x;
}

[test]
uniform int SIZE 1
draw rect -1 -1 2 2

Which gets optimized to:

===== SHADER #12 OPT ================================== PS/BARTS/EVERGREEN =====
===== 42 dw ===== 1 gprs ===== 2 stack =========================================
ALU 3 @24
     1      y: MOV                R0.y,  0
            t: MULLO_UINT         R0.w,  [0x00000002 2.8026e-45].x, R0.z

LOOP_START_DX10 @22
PUSH @6
ALU 1 @30 KC0[CB0:0-15]
     2 M    x: PRED_SETGE_INT     __.x,  R0.z, KC0[0].x
JUMP @14 POP:1
LOOP_BREAK @20
POP @14 POP:1
ALU 2 @32
     3      x: ADD_INT            R0.x,  R0.w, [0x00000002 2.8026e-45].x

TEX 1 @36
               VFETCH             R0.x___, R0.x,   RID:0   MFC:16 UCF:0 FMT[..]
ALU 1 @40
     4      y: ADD                R0.y,  R0.y, R0.x
LOOP_END @4
EXPORT_DONE        PIXEL 0     R0.____  EOP
===== SHADER_END ===============================================================

Notice R0.z being the loop counter/break condition relevant register
and being never incremented at all. Also some of the loop content
has been moved out of it, to fulfill the requirements for the one unused
op.

With a debug build of mesa this would produce an error like
error at : PRED_SETGE_INT     __, __, EM.2,    R1.x.2||FP@R0.z, C0.x
  : operand value R1.x.2||FP@R0.z was not previously written to its gpr
and the compilation would fail due to this. On a release build it gets
passed to the GPU.

When using this patch, the loop remains intact:

===== SHADER #12 OPT ================================== PS/BARTS/EVERGREEN =====
===== 48 dw ===== 1 gprs ===== 2 stack =========================================
ALU 2 @24
     1      y: MOV                R0.y,  0
            z: MOV                R0.z,  0
LOOP_START_DX10 @22
PUSH @6
ALU 1 @28 KC0[CB0:0-15]
     2 M    x: PRED_SETGE_INT     __.x,  R0.z, KC0[0].x
JUMP @14 POP:1
LOOP_BREAK @20
POP @14 POP:1
ALU 4 @30
     3      t: MULLO_UINT         T0.x,  [0x00000002 2.8026e-45].x, R0.z

     4      x: ADD_INT            R0.x,  T0.x, [0x00000002 2.8026e-45].x

TEX 1 @40
               VFETCH             R0.x___, R0.x,   RID:0   MFC:16 UCF:0 FMT[..]
ALU 2 @44
     5      y: ADD                R0.y,  R0.y, R0.x
            z: ADD_INT            R0.z,  R0.z, 1
LOOP_END @4
EXPORT_DONE        PIXEL 0     R0.____  EOP
===== SHADER_END ===============================================================

Piglit: ./piglit summary console -d results/*_gpu_noglx
        name: unpatched_gpu_noglx patched_gpu_noglx
        ----  ------------------- -----------------
        pass:               18016             18021
        fail:                 748               743
        crash:                  7                 7
        skip:                1124              1124
        timeout:                0                 0
        warn:                  13                13
        incomplete:             0                 0
        dmesg-warn:             0                 0
        dmesg-fail:             0                 0
        changes:                0                 5
        fixes:                  0                 5
        regressions:            0                 0
        total:              19908             19908

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94900
Tested-by: Heiko Przybyl <lil_tux@web.de>
Tested-on: Barts PRO HD6850
Signed-off-by: Heiko Przybyl <lil_tux@web.de>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>

editorconfig: Fix up the tab rendering width.

Our editorconfig file looked sensible, saying that we wanted to indent
with spaces and use 3/4/whatever space indentation.  However, the spec has
this little surprise:

    "tab_width: a whole number defining the number of columns used to
     represent a tab character. This defaults to the value of indent_size
     and doesn't usually need to be specified."

so once my editor started respecting editorconfig, the files that have
tabs left in them started getting rendered wrong, showing up like this in
brw_program.c:

   case GL_COMPUTE_PROGRAM_NV: {
      struct brw_program *prog = rzalloc(NULL, struct brw_program);
      if (prog) {
    prog->id = get_new_program_id(brw->screen);

    return _mesa_init_gl_program(&prog->program, target, id);
      }
      else
    return NULL;
   }

Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>

meta: Disable dithering during glGenerateMipmap

Fixes tests 'dEQP-GLES3.functional.texture.mipmap.*.generate.rgba5551*' on
Intel Broadwell 0x1616.

The GL 4.5 spec describes the algorithm of glGenerateMipmap as:

    The contents of the derived images are computed by repeated, filtered
    reduction of the level base image.  [...] No particular filter algorithm is
    required, though a box filter is recommended as the default filter.

Consider a texture for which all pixels are identical at level 0.
From the spec's description above, one may reasonably assume that the "filtered
reduction" of level 0 produces a new miplevel for which again all pixels are
identical. For any 2x2 subspan of identical pixels, it is difficult to see how
the "filtered reduction" of that subspan can produce a pixel that differs from
the source pixels.

Dithering during _mesa_meta_GenerateMipmap() violated that reasonable
assumption.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99210
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org

doc/features.txt: update for freedreno

I lost track of who created initial patch (Ilia?).. Romain rebased it.
I pushed it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95460
Signed-off-by: Rob Clark <robdclark@gmail.com>

i965: Remove perf monitor/query backend

In its current state the unified i965 backend for
AMD_performance_monitor and INTEL_performance_query isn't able to report
meaningful Observation Architecture metrics since we haven't so far had
the necessary kernel support to fully configure the OA unit, nor the
corresponding support for normalizing the counters into a form that can
be usefully interpreted by application developers (as opposed to raw
values that may, for example, scale by the number of EUs there are).

So that we can focus on implementing just one of these extensions fully
and since we anticipate some significant backend changes as we look to
use a new kernel interface to configure the OA unit, this patch removes
the current backend. This will simplify our ability to update the
frontend infrastructure and backend interface before updating our
support for performance counters.

Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

vl/zscan: fix "Fix trivial sign compare warnings"

The variable actually needs to be signed, otherwise converting it to a
float doesn't work as expected.

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98914
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Cc: "13.0" <mesa-stable@lists.freedesktop.org>
Fixes: 1fb4179f927 ("vl: Fix trivial sign compare warnings")

st/va: error handling

handle the cases when vl_compositor_set_csc_matrix(),
vl_compositor_init_state() and vl_compositor_init() fail

Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

st/vdpau: error handling

handle the cases when vl_compositor_set_csc_matrix(),
vl_compositor_init_state() and vl_compositor_init() fail

Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

vl/compositor: implement error handling

pipe_buffer_map and pipe_buffer_create may return NULL

Signed-off-by: Nayan Deshmukh <nayan26deshmukh@gmail.com>
Reviewed-by: Christian König <christian.koenig@amd.com>

i965/vec4: enable ARB_gpu_shader_fp64 for Haswell

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

i965/vec4: adjust spilling costs for 64-bit registers.

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

i965/vec4: prevent spilling of DOUBLE_TO_SINGLE destination

FROM_DOUBLE opcodes are setup so that they use a dst register
with a size of 2 even if they only produce a single-precison
result (this is so that the opcode can use the larger register to
produce a 64-bit aligned intermediary result as required by the
hardware during the conversion process). This creates a problem for
spilling though, because when we attempt to emit a spill for the
dst we see a 32-bit destination and emit a scratch write that
allocates a single spill register, making the intermediary writes
go beyond the size of the allocation.

Prevent this by avoiding to spill the destination register of these
opcodes.

Alternatively, we can avoid this by splitting the opcode in two: one
that produces a 64-bit aligned result and one that takes the 64-bit
aligned result as input and produces a 32-bit result from it.

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

i965/vec4: avoid spilling of registers that mix 32-bit and 64-bit access

When 64-bit registers are (un)spilled, we need to execute data shuffling
code before writing to or after reading from memory. If we have instructions
that operate on 64-bit data via 32-bit instructions, (un)spills for the
register produced by 32-bit instructions will not do data shuffling at all
(because we only see a normal 32-bit istruction seemingly operating on
32-bit data). This means that subsequent reads with that register using DF
access will unshuffle data read from memory that was never adequately
shuffled when it was written.

Fixing this would require to identify which 32-bit instructions write
64-bit data and emit spill instructions only when the full 64-bit
data has been written (by multiple 32-bit instructions writing to different
offsets of the same register) and always emit 64-bit unspills whenever
64-bit data is read, even when the instruction uses a 32-bit type to read
from them.

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

i965/vec4: support basic spilling of 64-bit registers

The current spilling code can't spill vgrf allocations larger than 1
but SIMD4x2 doubles require 2 vgrfs, so we need to permit this case (which
is handled properly for DF data types by emitting 2 scratch messages and
doing data shuffling). We accomplish this by not auto-disabling spilling
for vgrf allocations with a size of 2, and then disable spilling on any
register with an offset != 0B (which indicates array access).

Disable spilling of partial DF reads/writes because these don't read/write
data for both logical threads and our scratch messages for 64-bit data
need data for both threads to be present.

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

i965/vec4: run scalarize_df() after spilling

Spilling of 64-bit data requires data shuffling for the corresponding
scratch read/write messages. This produces unsupported swizzle regions
and writemasks that we need to scalarize.

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

i965/vec4: prevent src/dst hazards during 64-bit register allocation

8-wide compressed DF operations are executed as two separate 4-wide
DF operations. In that scenario, we have to be careful when we allocate
register space for their operands to prevent the case where the first
half of the instruction overwrites the source of the second half.

To do this we mark compressed instructions as having hazards to make
sure that ther register allocators assigns a register regions for the
destination that does not overlap with the region assigned for any
of its source operands.

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

i965/vec4/scalarize_df: support more swizzles via vstride=0

By exploiting gen7's hardware decompression bug with vstride=0 we gain the
capacity to support additional swizzle combinations.

This also fixes ZW writes from X/Y channels like in:

mov r2.z:df r0.xxxx:df

Because DF regions use 2-wide rows with a vstride of 2, the region generated
for the source would be r0<2,2,1>.xyxy:DF, which is equivalent to r0.xxzz, so
we end up writing r0.z in r2.z instead of r0.x. Using a vertical stride of 0
in these cases we get to replicate the XX swizzle and write what we want.

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

i965/vec4/scalarize_df: do not scalarize swizzles that we can support natively

Certain swizzles like XYZW can be supported by translating only the first two
64-bit swizzle channels to 32-bit channels. This happens with swizzles such
that the first two logical components, when translated to 32-bit channels and
replicated across the second dvec2 row, select the same channels specified by
the 3rd and 4th logical swizzle components.

Notice that this opens up the possibility that some instructions are not
scalarized and can end up with XY or ZW 32-bit writemasks. Make sure we always
scalarize in such cases.

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

i965/vec4: split instructions that read 64-bit interleaved attributes

Stages that use interleaved attributes generate regions with a vstride=0
that can hit the gen7 hardware decompression bug.

v2:
- Make static the function and fix indent (Matt)

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

i965/vec4: dump subnr for FIXED_GRF

This came in handy when debugging the payload setup for Tess Eval,
since it prints correct subnr for attributes that can be loaded
in the second half of a register.

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

i965/vec4/tes: consider register offsets during attribute setup

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

i965/vec4/tes: fix setup_payload() for 64bit data types

Use a width of 2 with 64-bit attributes.

Also, if we have a dvec3/4 attribute that gets split across two registers
such that components XY are stored in the second half of a register and
components ZW are stored in the first half of the next, we need to fix
regioning for any instruction that reads components Z/W of the attribute.
Notice this also means that we can't support sources that read cross-dvec2
swizzles (like XZ for example).

v2: don't assert that we have a single channel swizzle in the case that we
    have to fix up Z/W access on the first half of the next register. We
    can handle any swizzle that does not cross dvec2 boundaries, which
    the double scalarization pass should have prevented anyway.

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

i965/vec4/tes: fix input loading for 64bit data types

v2: use byte_offset() instead of offset()

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

i965/vec4/tcs: fix outputs for 64-bit data

v2: use byte_offset() instead of offset()

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

i965/vec4/tcs: fix input loading for 64-bit data

v2: use byte_offset() instead of offset()

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

i965/vec4/gs: fix input loading for 64bit data

v2 (Iago):
   - Adapt 64-bit path to component packing changes.

Signed-off-by: Samuel Iglesias Gonsálvez <siglesias@igalia.com>
Signed-off-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

i965/vec4: fix store output for 64-bit types

We need to shuffle the data before it is written to the URB. Also,
dvec3/4 need two vec4 slots.

v2: use byte_offset() instead of offset().

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

i965/vec4: fix attribute setup for doubles

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

i965/vec4: fix indentation in lower_attributes_to_hw_regs()

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

i965/vec4: make emit_pull_constant_load support 64-bit loads

This way callers don't need to know about 64-bit particularities and
we reuse some code.

v2:
  - use byte_offset() instead of offset()
  - only mark the surface as used once

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

i965/vec4: fix move_push_constants_to_pull_constants() for 64-bit data

v2: adapt to changes in offset()

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

i965/vec4: fix indentation in move_push_constants_to_pull_constants()

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

i965/vec4: fix move_uniform_array_access_to_pull_constant() for 64-bit data

v2: adapt to changes in offset()

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

i965/vec4: fix scratch writes for 64bit data

Mostly the same stuff as usual: we ned to shuffle the data before we
write and we need to emit two 32-bit write messages (with appropriate
32-bit writemask channels set) for a full dvec4 scratch write.

v2: use byte_offset() instead of offset().

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

i965/vec4: fix scratch reads for 64bit data

v2: Setup for a 64-bit scratch read by checking the type size of the
    correct register

v3: Use byte_offset() instead of offset()

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

i965/vec4: fix scratch offset for 64bit data

A vec4 is 16 bytes and a dvec4 is 32 bytes so for doubles we have
to multiply the reladdr by 2. The reg_offset part is in units of 16
bytes and is used to select the low/high 16-byte chunk of a full
dvec4, so we don't want to multiply that part of the address.

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

i965/vec4: do not split scratch read/write opcodes

64-bit scratch read/writes require to shuffle data around so we need
to have access to the full 64-bit data. We will do the right thing
for these when we emit the messages.

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

i965/vec4: Do not use DepCtrl with 64-bit instructions

The BDW PRM says that it is not supported, but it seems that gen7 is also
affected, since doing DepCtrl on double-float instructions leads to
GPU hangs in some cases, which is probably not surprising knowing that
this is not supported in new hardware iterations. The SKL PRMs do not
mention this restriction, so it is probably fine.

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

i965/vec4: extend the DWORD multiply DepCtrl restriction to all gen8 platforms

v2:
   - Add Broxton as Intel's internal PRMs says that it is needed (Matt).

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

i965/vec4: don't copy propagate misaligned registers

This means we would copy propagate partial reads or writes and that can affect
the result.

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

i965/vec4: don't propagate single-precision uniforms into 4-wide instructions

Otherwise we end up producing code that violates the register region
restriction that says that when execsize == width and hstride != 0
the vstride can't be 0.

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

i965/vec4: Prevent copy propagation from violating pre-gen8 restrictions

In gen < 8 instructions that write more than one register need to read
more than one register too. Make sure we don't break that restriction
by copy propagating from a uniform.

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

i965/vec4: prevent copy-propagation from values with a different type size

Because the meaning of the swizzles and writemasks involved is different,
so replacing the source would lead to different semantics.

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

i965/vec4: don't constant propagate 64-bit immediates

v2: Also check if the instruction source target is 64-bit. (Samuel)

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

i965/vec4: Fix SSBO stores for 64-bit data

In this case we need to shuffle the 64-bit data before we write it
to memory, source from reg_offset + 1 to write components Z and W
and consider that each DF channel is twice as big.

v2: use byte_offset() instead of offset().

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

i965/vec4: Fix SSBO loads for 64-bit data

Same requirements as for UBO loads.

v2:
  - use byte_offset() instead of offset() (Iago)
  - keep the const. offset as an immediate like the original code did (Juan)

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

i965/vec4: Fix UBO loads for 64-bit data

We need to emit 2 32-bit load messages to load a full dvec4. If only
1 or 2 double components are needed dead-code-elimination will remove
the second one.

We also need to shuffle the result of the 32-bit messages to form
valid 64-bit SIMD4x2 data.

v2:
 - use byte_offset() instead of offset() (Iago)
 - keep the const. offset as an immediate like the original code did (Juan)

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

i965/vec4: Add a shuffle_64bit_data helper

SIMD4x2 64bit data is stored in register space like this:

r0.0:DF  x0 y0 z0 w0
r1.0:DF  x1 y1 z1 w1

When we need to write data such as this to memory using 32-bit write
messages we need to shuffle it in this fashion:

r0.0:DF  x0 y0 x1 y1
r0.1:DF  z0 w0 z1 w1

and emit two 32-bit write messages, one for r0.0 at base_offset
and another one for r0.1 at base_offset+16.

We also need to do the inverse operation when we read using 32-bit messages
to produce valid SIMD4x2 64bit data from the data read. We can achieve this
by aplying the exact same shuffling to the data read, although we need to
apply different channel enables since the layout of the data is reversed.

This helper implements the data shuffling logic and we will use it in
various places where we read and write 64bit data from/to memory.

v2 (Curro):
  - Use the writemask helper and don't assert on the original writemask
    being XYZW.
  - Use the Vec4 IR builder to simplify the implementation.

v3 (Iago):
  - Use byte_offset() instead of offset().

v3:
  - Fix typo (Matt)
  - Clarify the example and fix indention (Matt).

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

i965/vec4: support multiple dispatch widths and groups in the IR builder.

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

i965/vec4: Lower 64-bit MAD

The previous patch made sure that we do not generate MAD instructions
for any NIR's 64-bit ffma, but there is nothing preventing i965 from
producing MAD instructions as a result of lowerings or optimization
passes. This patch makes sure that any 64-bit MAD produced inside the
driver after translating from NIR is also converted to MUL+ADD before
we generate code.

v2:
  - Use a copy constructor to copy all relevant instruction fields from
    the original mad into the add and mul instructions

v3:
  - Rename the lowering and fix commit log (Matt)

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

i965/vec4/nir: do not emit 64-bit MAD

RepCtrl=1 does not work with 64-bit operands so we need to use RepCtrl=0.

In that situation, the regioning generated for the sources seems to be
equivalent to <4,4,1>:DF, so it will only work for components XY, which
means that we have to move any other swizzle to a temporary so that we can
source from channel X (or Y) in MAD and we also need to split the instruction
(we are already scalarizing DF instructions but there is room for
improvement and with MAD would be more restricted in that area)

Also, it seems that MAD operations like this only write proper output for
channels X and Y, so writes to Z and W also need to be done to a temporary
using channels X/Y and then move that to channels Z or W of the actual dst.

As a result the code we produce for native 64-bit MAD instructions is rather
bad, and much worse than just emitting MUL+ADD. For reference, a simple case
of a fully scalarized dvec4 MAD operation requires 15 instructions if we use
native MAD and 8 instructions if we emit ADD+MUL instead. There are some
improvements that we can do to the emission of MAD that might bring the
instruction count down in some cases, but it comes at the expense of a more
complex implementation so it does not seem worth it, at least initially.

This patch makes translation of NIR's 64-bit FMMA instructions produce MUL+ADD
instead of MAD. Currently, there is nothing else in the vec4 backend that emits
MAD instructions, so this is sufficient and it helps optimization passes see
MUL+ADD from the get go.

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

i965/vec4: Skip swizzle to subnr in 3src instructions with DF operands

We make scalar sources in 3src instructions use subnr instead of
swizzles because they don't really use swizzles.

With doubles it is more complicated because we use vstride=0 in
more scenarios in which they don't produce scalar regions. Also
RepCtrl=1 is not allowed with 64-bit operands, so we should avoid
this.

v2: Fix typo (Matt)

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

i965/vec4: fix indentation in pack_uniform_registers

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

i965/vec4: fix pack_uniform_registers for doubles

We need to consider the fact that dvec3/4 require two vec4 slots.

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