i965: Extend compute-to-mrf pass to understand blocks of MOVs

The current compute-to-mrf pass doesn't handle blocks of MOVs.  Shaders
that end with a texture fetch follwed by an fb write are left like this:

0x00000000: pln(8)          g6<1>F          g4<0,1,0>F      g2<8,8,1>F      { align1 WE_normal 1Q compacted };
0x00000008: pln(8)          g7<1>F          g4.4<0,1,0>F    g2<8,8,1>F      { align1 WE_normal 1Q compacted };
0x00000010: send(8)         g2<1>UW         g6<8,8,1>F
                            sampler (1, 0, 0, 1) mlen 2 rlen 4              { align1 WE_normal 1Q };
0x00000020: mov(8)          g113<1>F        g2<8,8,1>F                      { align1 WE_normal 1Q compacted };
0x00000028: mov(8)          g114<1>F        g3<8,8,1>F                      { align1 WE_normal 1Q compacted };
0x00000030: mov(8)          g115<1>F        g4<8,8,1>F                      { align1 WE_normal 1Q compacted };
0x00000038: mov(8)          g116<1>F        g5<8,8,1>F                      { align1 WE_normal 1Q compacted };
0x00000040: sendc(8)        null            g113<8,8,1>F
                            render ( RT write, 0, 4, 12) mlen 4 rlen 0      { align1 WE_normal 1Q EOT };

This patch lets compute-to-mrf recognize blocks of MOVs and match them to
instructions (typically SEND) that writes multiple registers.  With this,
the above shader becomes:

0x00000000: pln(8)          g6<1>F          g4<0,1,0>F      g2<8,8,1>F      { align1 WE_normal 1Q compacted };
0x00000008: pln(8)          g7<1>F          g4.4<0,1,0>F    g2<8,8,1>F      { align1 WE_normal 1Q compacted };
0x00000010: send(8)         g113<1>UW       g6<8,8,1>F
                            sampler (1, 0, 0, 1) mlen 2 rlen 4              { align1 WE_normal 1Q };
0x00000020: sendc(8)        null            g113<8,8,1>F
                            render ( RT write, 0, 20, 12) mlen 4 rlen 0     { align1 WE_normal 1Q EOT };

which is the bulk of the shader db results:

total instructions in shared programs: 987040 -> 986720 (-0.03%)
instructions in affected programs:     844 -> 524 (-37.91%)
GAINED:                                0
LOST:                                  0

The optimization also applies to MRT shaders that write the same
color value to multiple RTs, in which case we can eliminate four MOVs in
a similar fashion.  See fbo-drawbuffers2-blend in piglit for an example.

No measurable performance impact.  No piglit regressions.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
ilo: fix fence reference counting

The old code was complicated, and was wrong when *ptr is NULL.
configure: Don't special case Cygwin to use gnu99, define _XOPEN_SOURCE instead

Revert "build: Build on Cygwin with gnu99 instead of c99." and define
_XOPEN_SOURCE appropriately.

This reverts commit 53e36d333c9b619c1a5fe9a8d2d08665654b0234.

Since Cygwin 1.7.18 (April 2013), it's headers correctly prototype strtoll()
when using -std=c99, and correctly prototype strdup() when _XOPEN_SOURCE is
defined appropriately, so this workaround is no longer needed.

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Cc: Vinson Lee <vlee@freedesktop.org>
i965/fs: Track dependencies in instruction scheduling per reg offset.

Previously instruction scheduling tracked dependencies on a per-register
basis. This meant that there was an artificial dependency between
interpolation instructions writing into the same virtual register.

Instruction scheduling would insert a number of instructions between the
two instructions in this example, when they are actually independent.

   linterp vgrf8+0.0:F, hw_reg2:F, hw_reg3:F, hw_reg6:F
   linterp vgrf8+1.0:F, hw_reg2:F, hw_reg3:F, hw_reg6+16:F

This lead to cases where the first texture coordinate is interpolated at
the beginning of the shader, but the second is done immediately before
the texture operation that uses it as a source.

After this change, the artificial dependency is removed and the
interpolation instructions are scheduled together.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Remove artificial dependency between math instructions.

... on Gen6+. I'm not actually sure which class Gen6 fits into.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
gallium: fix u_default_transfer_inline_write for textures

This doesn't fix any known issue. In fact, radeon drivers ignore all
the discard flags for textures and implicitly do "discard range"
for any write transfer.

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
radeonsi: mark MSAA config state as dirty at the beginning of CS

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

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
glsl: Fix the foreach_in_list_reverse macro.

We clearly don't want to start at the head and walk backwards; we want
to start at the last real element before the tail sentinel.  If the list
is empty, tail_pred will be the head sentinel, and we'll stop.

Nothing uses this function, so I guess nobody noticed it was broken.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/disasm: Fix disassembly of the any16h/all16h predicates.

BRW_PREDICATE_ALIGN1_ANY16H was incorrectly being disassembled as
"all16h", and ALL16H would probably print as "(null)".

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
nv50/ir: use unordered_set instead of list to keep track of var uses

The set of variable uses does not need to be ordered in any way, and
removing/adding elements is a fairly common operation in various
optimization passes.

This shortens runtime of piglit test fp-long-alu to ~22s from ~4h

Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
nvc0: allocate more space before a counter is configured

On nvc0, a counter can have up to 6 sources instead of only one
for nve4+. This fixes a crash when a counter uses more than
one source.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
mesa: protect the debug state with a mutex

We are about to change mesa to spawn threads for deferred glCompileShader and
glLinkProgram, and we need to make sure those threads can send compiler
warnings/errors to the debug output safely.

Signed-off-by: Chia-I Wu <olv@lunarg.com>
glsl: rename strtod.c to strtod.cpp

We want to add a static object to initialize locale_t in the following commit.

Signed-off-by: Chia-I Wu <olv@lunarg.com>
glsl: initialize locale_t with a static object

The compiler may be used by multiple contexts simultaneously and needs to be
thread-safe.

Signed-off-by: Chia-I Wu <olv@lunarg.com>
glsl: protect anonymous struct id with a mutex

There may be two contexts compiling shaders at the same time, and we want the
anonymous struct id to be globally unique.

Signed-off-by: Chia-I Wu <olv@lunarg.com>
glsl: protect glsl_type with a mutex

glsl_type has several static hash tables and a static ralloc context.  They
need to be protected by a mutex as they are not thread-safe.

Signed-off-by: Chia-I Wu <olv@lunarg.com>
glsl: add a generic thread pool data structure

It can be used to implement, for example, threaded glCompileShader and
glLinkProgram.

v2: allow tasks to "complete" other tasks

Signed-off-by: Chia-I Wu <olv@lunarg.com>
glsl: add a singleton GLSL thread pool

This thread pool will be used by contexts to queue compilation tasks.

Signed-off-by: Chia-I Wu <olv@lunarg.com>
mesa: add infrastructure for threaded shader compilation

Add _mesa_enable_glsl_threadpool to enable the thread pool for a context, and
add ctx->Const.DeferCompileShader and ctx->Const.DeferLinkProgram to
fine-control what gets threaded.

Setting DeferCompileShader to true will make _mesa_glsl_compile_shader be
executed in a worker thread.  The function is thread-safe so there is no
restriction on DeferCompileShader.

Setting DeferLinkProgram to true will make _mesa_glsl_link_shader be executed
in a worker thread.  The function is thread-safe only when certain driver
functions (as documented in struct gl_constants) are thread-safe.  It is
drivers' responsibility to fix those driver functions before setting
DeferLinkProgram.

When DeferLinkProgram is set, drivers are not supposed to inspect the context
in their LinkShader callbacks.  Instead, NotifyLinkShader is added.  Drivers
should inspect the context in NotifyLinkShader and save what they need for
LinkShader in gl_shader_program.

As a final note, most applications will not benefit from threaded shader
compilation because they check GL_COMPILE_STATUS/GL_LINK_STATUS immediately,
giving the worker threads no time to do their jobs.  A possible improvement is
to split LinkShader into two parts: the first part links and error checks
while the second part optimizes and generates the machine code.  With the
split, we can always defer the second part to the thread pool.

Signed-off-by: Chia-I Wu <olv@lunarg.com>
i965: add drirc option multithread_glsl_compiler

Setting it to a non-zero value N will cause shader compilation to be deferred
to a thread pool.  When N is greater than 1, it indicates the maximum number
of threads in the pool.  When N is 1, the number of threads is up to the
driver (two for i965).

Signed-off-by: Chia-I Wu <olv@lunarg.com>