i965/fs: Extend predicated break pass to predicate WHILE.

Helps a handful of programs in Serious Sam 3 that use do-while loops.

instructions in affected programs:     16114 -> 16075 (-0.24%)

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/vec4: Call opt_algebraic after opt_cse.

The next patch adds an algebraic optimization for the pattern

   sqrt a, b
   rcp  c, a

and turns it into

   sqrt a, b
   rsq  c, b

but many vertex shaders do

   a = sqrt(b);
   var1 /= a;
   var2 /= a;

which generates

   sqrt a, b
   rcp  c, a
   rcp  d, a

If we apply the algebraic optimization before CSE, we'll end up with

   sqrt a, b
   rsq  c, b
   rcp  d, a

Applying CSE combines the RCP instructions, preventing this from
happening.

No shader-db changes.

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/vec4: Optimize sqrt+inv into rsq.

Transform

   sqrt a, b
   rcp  c, a

into

   sqrt a, b
   rsq  c, b

In most cases the sqrt's result is still used, so the improvement here
is that we've broken a dependency between these instructions. Leads to
80 fewer INV instructions and 80 more RSQ.

Occasionally the sqrt's result is no longer used, leading to:

instructions in affected programs:     5005 -> 4949 (-1.12%)

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/fs: Optimize sqrt+inv into rsq.

Transform

   sqrt a, b
   rcp  c, a

into

   sqrt a, b
   rsq  c, b

The improvement here is that we've broken a dependency between these
instructions. Leads to 330 fewer INV instructions and 330 more RSQ.

Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/fs: Set MUL source type to W/UW in 64-bit mul macro on Gen8.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/fs: Allow SIMD16 borrow/carry/64-bit multiply on Gen > 7.

These checks were intended for Gen 7 only. None of these restrictions
apply to Gen 8.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/fs: Emit compressed BFI2 instructions on Gen > 7.

IVB had a restriction that prevented us from emitting compressed
three-source instructions, and although that was lifted on Haswell,
Haswell had a new restriction that said BFI instructions specifically
couldn't be compressed.
galahad: (trivial) handle cubemap arrays

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
galahad: fix indirect draw

Need to unwrap the indirect resource otherwise bad things will happen.

Fixes random crashes and timeouts with piglit's arb_indirect_draw tests.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
i965/fs: Fix an uninitialized value warnings

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965/fs: Fix the build
glx/dri3: Use four buffers until X driver supports async flips

A driver which doesn't have async flip support will queue up flips without any
way to replace them afterwards. This means we've got a scanout buffer pinned
as soon as we schedule a flip and so we need another buffer to keep from
stalling.

When vblank_mode=0, if there are only three buffers we do:

        current scanout buffer = 0 at MSC 0

        Render frame 1 to buffer 1
        PresentPixmap for buffer 1 at MSC 1

                This is sitting down in the kernel waiting for vblank to
                become the next scanout buffer

        Render frame 2 to buffer 2
        PresentPixmap for buffer 2 at MSC 1

                This cannot be displayed at MSC 1 because the
                kernel doesn't have any way to replace buffer 1 as the pending
                scanout buffer. So, best case this will get displayed at MSC 2.

Now we block after this, waiting for one of the three buffers to become idle.
We can't use buffer 0 because it is the scanout buffer. We can't use buffer 1
because it's sitting in the kernel waiting to become the next scanout buffer
and we can't use buffer 2 because that's the most recent frame which will
become the next scanout buffer if the application doesn't manage to generate
another complete frame by MSC 2.

With four buffers, we get:

        current scanout buffer = 0 at MSC 0

        Render frame 1 to buffer 1
        PresentPixmap for buffer 1 at MSC 1

                This is sitting down in the kernel waiting for vblank to
                become the next scanout buffer

        Render frame 2 to buffer 2
        PresentPixmap for buffer 2 at MSC 1

                This cannot be displayed at MSC 1 because the
                kernel doesn't have any way to replace buffer 1 as the pending
                scanout buffer. So, best case this will get displayed at MSC
                2. The X server will queue this swap until buffer 1 becomes
                the scanout buffer.

        Render frame 3 to buffer 3
        PresentPixmap for buffer 3 at MSC 1

                As soon as the X server sees this, it will replace the pending
                buffer 2 swap with this swap and release buffer 2 back to the
                application

        Render frame 4 to buffer 2
        PresentPixmap for buffer 2 at MSC 1

                Now we're in a steady state, flipping between buffer 2 and 3
                waiting for one of them to be queued to the kernel.

        ...

        current scanout buffer = 1 at MSC 1

                Now buffer 0 is free and (e.g.) buffer 2 is queued in
                the kernel to be the scanout buffer at MSC 2

        Render frames, flipping between buffer 0 and 3

When the system can replace a queued buffer, and we update Present to take
advantage of that, we can use three buffers and get:

        current scanout buffer = 0 at MSC 0

        Render frame 1 to buffer 1
        PresentPixmap for buffer 1 at MSC 1

                This is sitting waiting for vblank to become the next scanout
                buffer

        Render frame 2 to buffer 2
        PresentPixmap for buffer 2 at MSC 1

                Queue this for display at MSC 1
                1. There are three possible results:

                  1) We're still before MSC 1. Buffer 1 is released,
                     buffer 2 is queued waiting for MSC 1.

                  2) We're now after MSC 1. Buffer 0 was released at MSC 1.
                     Buffer 1 is the current scanout buffer.

                     a) If the user asked for a tearing update, we swap
                        scanout from buffer 1 to buffer 2 and release buffer
                        1.

                     b) If the user asked for non-tearing update, we
                        queue buffer 2 for the MSC 2.

                In all three cases, we have a buffer released (call it 'n'),
                ready to receive the next frame.

        Render frame 3 to buffer n
        PresentPixmap for buffer n

                If we're still before MSC 1, then we'll ask to present at MSC
                1. Otherwise, we'll ask to present at MSC 2.

Present already does this if the driver offers async flips, however it does
this by waiting for the right vblank event and sending an async flip right at
that point.

I've hacked the intel driver to offer this, but I get tearing at the top of
the screen. I think this is because flips are always done from within the
ring, and so the latency between the vblank event and the async flip happening
can cause tearing at the top of the screen.

That's why I'm keying the need for the extra buffer on the lack of 2D
driver support for async flips.

Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Jason Ekstrand <jason.ekstrand@intel.com>
Tested-by: Dylan Baker <baker.dylan.c@gmail.com>
glx/dri3: Provide error diagnostics when DRI3 allocation fails

Instead of just segfaulting in the driver when a buffer allocation fails,
report error messages indicating what went wrong so that we can debug things.

As a simple example, chromium wraps Mesa in a sandbox which doesn't allow
access to most syscalls, including the ability to create shared memory
segments for fences. Before, you'd get a simple segfault in mesa and your 3D
acceleration would fail. Now you get:

$ chromium --disable-gpu-blacklist
[10618:10643:0930/200525:ERROR:nss_util.cc(856)] After loading Root Certs, loaded==false: NSS error code: -8018
libGL: pci id for fd 12: 8086:0a16, driver i965
libGL: OpenDriver: trying /local-miki/src/mesa/mesa/lib/i965_dri.so
libGL: Can't open configuration file /home/keithp/.drirc: Operation not permitted.
libGL: Can't open configuration file /home/keithp/.drirc: Operation not permitted.
libGL error: DRI3 Fence object allocation failure Operation not permitted
[10618:10618:0930/200525:ERROR:command_buffer_proxy_impl.cc(153)] Could not send GpuCommandBufferMsg_Initialize.
[10618:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(236)] CommandBufferProxy::Initialize failed.
[10618:10618:0930/200525:ERROR:webgraphicscontext3d_command_buffer_impl.cc(256)] Failed to initialize command buffer.

This made it pretty easy to diagnose the problem in the referenced bug report.

Bugzilla: https://code.google.com/p/chromium/issues/detail?id=415681
Signed-off-by: Keith Packard <keithp@keithp.com>
Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Matt Turner <mattst88@gmail.com>
llvmpipe: Add missing LLVMGetGlobalContext() arg in lp_test_format.c.

Fix build error introduced with commit
eedbce9c63a3f385908bdc8a69e8be98dd3522ff.

lp_test_format.c: In function ‘test_format_unorm8’:
lp_test_format.c:226:4: error: too few arguments to function ‘gallivm_create’
    gallivm = gallivm_create("test_module_unorm8");
    ^
In file included from ../../../../src/gallium/auxiliary/gallivm/lp_bld_format.h:38:0,
                 from lp_test_format.c:42:
../../../../src/gallium/auxiliary/gallivm/lp_bld_init.h:58:1: note: declared here
 gallivm_create(const char *name, LLVMContextRef context);
 ^

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84538
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
i965: Fix spelling of GEN7_SAMPLER_EWA_ANISOTROPIC_ALGORITHM

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
i965: Fix typo in comment

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
i965: Delete CACHE_NEW_BLORP_CONST_COLOR_PROG.

Unused since krh rewrote fast clears to use meta.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965: Fix INTEL_DEBUG=state to work with 64-bit dirty bits.

This will keep INTEL_DEBUG=state working when we add BRW_NEW_* bits
beyond 1 << 31.  We missed doing this when widening the driver flags
from uint32_t to uint64_t.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965: Use ~0ull when flagging all BRW_NEW_* dirty flags.

~0 is 0xFFFFFFFF, which only covers the first 32 bits.  We need all 64.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
i965: Use "1ull" instead of "1" in BRW_NEW_* defines.

Now that the bitfield is a uint64_t, we should use 1ull.  Currently, we
only have 32 entries, so 1 works fine, but it's not future-proof.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>