scons: Require LLVM 3.1

Support for prior versions will be removed in the following change.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
configure: Require LLVM 3.1.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
gallivm,draw,llvmpipe: Remove support for versions of LLVM prior to 3.1.

Older versions haven't been tested probably don't work anyway.  But more
importantly, code supporting it is hindering further work.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
gallivm: Stop using module providers.

Nowadays LLVMModuleProviderRef is just an alias for LLVMModuleRef, so
its use just causes unnecessary confusion.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
gallivm: Use LLVM global context.

I saw that LLVM internally uses its global context for some things, even
when we use our own.  Given ours is also global, might as well use
LLVM's.

However, sepearate contexts can still be enabled with a simple source
code modification, for when the need/benefit arises.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
gallivm: Run passes per module, not per function.

This is how it is meant to be done nowadays.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
gallivm: One code memory pool with deferred free.

Provide a JITMemoryManager derivative which puts all generated code into
one memory pool instead of creating a new one each time code is generated.
This saves significant memory per shader as the pool size is 512K and
a small shader occupies just several K.

This memory manager also defers freeing generated code until you tell
it to do so, making it possible to destroy the LLVM engine while keeping
the code, thus enabling future memory savings.

v2: Fix compilation errors with LLVM 3.4 (Jose)

Signed-off-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
gallivm: Separate freeing LLVM intermediate data from freeing final code.

Split free_gallivm_state() into two steps.  First step is
gallivm_free_ir() which cleans up the LLVM scaffolding used to generate
code while preserving the code itself.  Second step is
gallivm_free_code() to free the memory occupied by the code.

v2: s/gallivm_teardown/gallivm_free_ir/ (Jose)

Signed-off-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
draw: Delete unneeded LLVM stuff earlier.

Free up unneeded LLVM stuff immediately after generating vertex shader
code.  Saves about 500K per shader.

v2: Don't bother calling gallivm_free_function (Jose)

Signed-off-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
llvmpipe: Delete unneeded LLVM stuff earlier.

Same as Frank's change to draw module but for llvmpipe module.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
gallivm: Remove gallivm_free_function.

Unused.  Deprecated by gallivm_free_ir().

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
gallivm: Remove lp_func_delete_body.

Not necessary, now that we will free the whole module (hence all
function bodies) immediately after compiling.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
gallium/docs: clarify when query results are reset

It wasn't completely clear from the docs, so I had to figure out by
looking at piglit results.  Hopefully this saves the next driver writer
implementing queries some time.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
mesa/st: provide native integers implementation of ir_unop_any

Previously, ir_unop_any was implemented via a dot-product call, which
uses floating point multiplication and addition. The multiplication was
completely pointless, and the addition can just as well be done with an
or. Since we know that the inputs are booleans, they must already be in
canonical 0/~0 format, and the final SNE can also be avoided.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
tgsi: support parsing texture offsets from text tgsi shaders

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
radeonsi: Fix anisotropic filtering state setup

Bring it back in line with r600g. I broke this in the original radeonsi
bringup. :(

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

Cc: "10.1 10.2" <mesa-stable@lists.freedesktop.org>

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
gallivm: fix output stream flushing in error case for disassembly.

When there's an error, also need to flush the stream, otherwise an assertion
is hit (meaning you don't actually see the error neither).
gallivm: only fetch pointers to constant buffers once

In 1d35f77228ad540a551a8e09e062b764a6e31f5e support for multiple constant
buffers was introduced. This meant we had another indirection, and we did
resolve the indirection for each constant buffer access. This looks very
reasonable since llvm can figure out if it's the same pointer, however it
turns out that this can cause llvm compilation time to go through the roof
and beyond (I've seen cases in excess of factor 100, e.g. from 50 ms to more
than 10 seconds (!)), with all the additional time spent in IR optimization
passes (and in the end all of it in DominatorTree::dominate()).
I've been unable to narrow it down a bit more (only some shaders seem affected,
seemingly without much correlation to overall shader complexity or constant
usage) but it is easily avoidable by doing the buffer lookups themeselves just
once (at constant buffer declaration time).

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
configure: correctly set LD_NO_UNDEFINED

Commit 11623be934f85 was meant to have this hunk, which
I accidently dropped during git rebase.

Cc: 10.2 <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Jonathan Gray <jsg@jsg.id.au>
automake: Honor GL_LIB for gallium libgl-xlib

Use "@GL_LIB@" in src/gallium/targets/libgl-xlib/Makefile.am to produce
the library name specified by the configure --with-gl-lib-name option.

Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>