configure.ac: Compute the required llvm static libraries only once

In order to determine which static LLVM libraries are needed we pass
a list of components to llvm-config and it generates the list of
library dependencies for us.  The advantage of only calling llvm-config
one time is that it can determine if two components depend on the same
library and then add it to the output list only once.  The old practice
of having each driver call llvm-config to add its own dependencies to
$(LLVM_LIBS) caused many libraries to be added to this variable multiple
times.
configure.ac: Force use of LLVM shared libs with --enable-opencl v2

If we build clover with LLVM static libraries, then clover and also each
pipe_*.so driver that is built will contain their own static copy of
LLVM.  The recent automake changes have uncovered a problem where
the pipe_*.so drivers try to use clover's LLVM symbols.  This causes
LLVM's static registry objects to be initialized each time
a pipe_*.so driver is loaded by clover.  Initializing these objects
multiple times is not allowed and leads to assertion failures in the
LLVM code.

We can avoid all these problems by having clover and all the pipe_*.so
drivers link against the same LLVM shared library.

https://bugs.freedesktop.org/show_bug.cgi?id=59334
https://bugs.freedesktop.org/show_bug.cgi?id=59534

v2:
  - Fix shared library detection when LLVM is built with CMake
Revert "Revert "targets/opencl: Link against libgallium.la instead of libgallium.a""

This reverts commit 7824ab807050c03c6df01c44774914dcbef88248.

Now that we force linking with LLVM shared libs when building clover,
we can link against libgallium.la with no problems.
st/dri: add null-pointer check, remove duplicated local variable

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
st/dri: disallow recursion in dri_flush

ST_FLUSH_FRONT may call driThrottle, which is implemented with dri_flush.
This prevents double flush as well as fence leaks caused by a recursion
in the middle of throttling.

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

Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
st/mesa: advertise OES_depth_texture_cube_map if GLSL 1.30 is supported

Reviewed-by: Brian Paul <brianp@vmware.com>
st/mesa: implement ARB_internalformat_query v2

Reviewed-by: Brian Paul <brianp@vmware.com>
intel: callocing a 32 byte temp is silly, so don't

I believe that the size used to vary, so the dynamic allocation is
necessary.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
intel: Fix ReadPixels on buffers whose width >= 32kbytes

When possible, glReadPixels calls are performed using the hardware
blitter.  However, according to the Ivy Bridge PRM, Vol1 Part4,
section 1.2.1.2 (Graphics Data Size Limitations):

    The BLT engine is capable of transferring very large quantities of
    graphics data. Any graphics data read from and written to the
    destination is permitted to represent a number of pixels that
    occupies up to 65,536 scan lines and up to 32,768 bytes per scan
    line at the destination. The maximum number of pixels that may be
    represented per scan line’s worth of graphics data depends on the
    color depth.

With an RGBA32F color buffer (which has 16 bytes per pixel) this
imposes a maximum width of 2048 pixels.

To make matters worse, if the pitch of the buffer is 32k or greater,
intel_miptree_map_blit's call to intelEmitCopyBlit will overflow
intelEmitCopyBlit's src_pitch and dst_pitch parameters (which are
16-bit signed integers).

We can conveniently avoid both problems by avoiding the readpixels
blit path when the miptree's pitch is >= 32k.

Fixes gles3conform "half_float" tests when the buffer width is greater
than 2048.

Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
libgl-xlib/build: Link with C++ when LLVM is used

Also link-in libX11 and libXext.

Tested-by: Brian Paul <brianp@vmware.com>
i965/vs: Do headerless texturing for texelFetchOffset().

For texelFetchOffset(), we just add the texel offsets to the coordinate
rather than using the message header's offset fields.  So we don't
actually need a header on Gen5+.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
glsl: Clean up case statement in builtin_variables.cpp's add_variable.

The case statement purported to handle the addition of ir_var_const_in
and ir_var_inout builtin variables.  But no such variables exist.
This patch removes the unnecessary cases, and adds a comment
explaining why they're not needed.

Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
glsl: Eliminate ambiguity between function ins/outs and shader ins/outs

This patch replaces the three ir_variable_mode enums:

- ir_var_in
- ir_var_out
- ir_var_inout

with the following five:

- ir_var_shader_in
- ir_var_shader_out
- ir_var_function_in
- ir_var_function_out
- ir_var_function_inout

This eliminates a frustrating ambiguity: it used to be impossible to
tell whether an ir_var_{in,out} variable was a shader in/out or a
function in/out without seeing where the variable was declared in the
IR.  This complicated some optimization and lowering passes, and would
have become a problem for implementing varying structs.

In the lisp-style serialization of GLSL IR to strings performed by
ir_print_visitor.cpp and ir_reader.cpp, I've retained the names "in",
"out", and "inout" for function parameters, to avoid introducing code
churn to the src/glsl/builtins/ir/ directory.

Note: a couple of comments in the code seemed to indicate that we were
planning for a possible future in which geometry shaders could have
shader-scope inout variables.  Our GLSL grammar rejects shader-scope
inout variables, and I've been unable to find any evidence in the GLSL
standards documents (or extensions) that this will ever be allowed, so
I've eliminated these comments.

Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
glsl: Disable structure splitting for shader ins/outs.

Previously, it didn't matter whether structure splitting tried to
split shader ins/outs, because structs were prohibited from being used
for shader ins/outs.  However, GLSL 3.00 ES supports varying structs.
In order for varying structs to work, we need to make sure that
structure splitting doesn't get applied to them, because if it does,
then the linker won't be able to match up varyings properly.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
glsl: Generalize compute_packing_order for varying structs.

This patch paves the way for allowing varying structs by generalizing
varying_matches::compute_packing_order to handle any type of varying.
Previously, we packed in the order (vec4, vec2, float, vec3), with
matrices being packed according to the size of their columns.  Now, we
pack everything according to its number of components mod 4, in the
order (0, 2, 1, 3).

There is no behavioural change for vectors.  Matrices are now packed
slightly differently:

- mat2x2 gets assigned PACKING_ORDER_VEC4 instead of
  PACKING_ORDER_VEC2.  This is slightly better, because it guarantees
  that the matrix occupies a single varying slot.

- mat2x3 gets assigned PACKING_ORDER_VEC2 instead of
  PACKING_ORDER_VEC3.  This is kind of a wash.  Previously, mat2x3 had
  a 25% chance of having neither of its columns double parked, a 50%
  chance of having exactly one of its columns double parked, and a 25%
  chance of having both of its columns double parked.  Now it always
  has exactly one of its columns double parked.

- mat3x3 gets assigned PACKING_ORDER_SCALAR instead of
  PACKING_ORDER_VEC3.  This doesn't affect much, since in both cases
  there is no guarantee of how the matrix will be aligned.

- mat4x2 gets assigned PACKING_ORDER_VEC4 instead of
  PACKING_ORDER_VEC2.  This is slightly better for the same reason as
  in mat2x2.

- mat4x3 gets assigned PACKING_ORDER_VEC4 instead of
  PACKING_ORDER_VEC3.  This is slightly better for the same reason as
  in mat2x2.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
glsl: Update lower_packed_varyings to handle varying structs.

This patch adds code to lower_packed_varyings to handle varyings of
type struct.  Varying structs are currently packed in the most naive
possible way (in declaration order, with no gaps), so there is a
potential loss of runtime efficiency.  In a later patch it would be
nice to replace this with a "flattening" approach (wherein a varying
struct is flattened to individual varyings corresponding to each of
its structure elements), so that the linker can align each structure
element independently.  However, that would require a significantly
more complex implementation.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
glsl: Disable transform feedback of varying structs.

It is not clear from the GLSL ES 3.00 spec how transform feedback is
supposed to apply to varying structs:

- There is no specification for how the structure is to be packed when
  it is recorded into the transform feedback buffer.

- There is no reasonable value for GetTransformFeedbackVarying to
  return as the "type" of the variable.

We currently have a Khronos bug requesting clarification on how this
feature is supposed to work
(https://cvs.khronos.org/bugzilla/show_bug.cgi?id=9856).

This patch just disables transform feedback of varying structs for
now; we can implement the proper behaviour once we find out from
Khronos what it is.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
glsl: Allow varying structs in GLSL ES 3.00 and GLSL 1.50.

Previously I thought that varying structs had been added to GLSL ES
3.00 by mistake, because chapter 11 of the GLSL ES 3.00 spec
("Counting of Inputs and Outputs") failed to mention how structs
should be handled.  Khronos has clarified
(https://cvs.khronos.org/bugzilla/show_bug.cgi?id=9828) that varying
structs are indeed required, and that chapter 11 will be modified to
indicate that the minimal reference packing algorithm flattens varying
structs to their individual components.

Mesa doesn't flatten varying structs to their individual components,
but this is ok, since it packs varyings of all kinds with no wasted
space at all (except where this is impossible due to differing
interpolation modes), so it will outperform the minimal reference
packing algorithm in all but the most pathological cases.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
intel: Fix glCopyTexSubImage on buffers whose width >= 32kbytes

When possible, glCopyTexSubImage calls are performed using the
hardware blitter.  However, according to the Ivy Bridge PRM, Vol1
Part4, section 1.2.1.2 (Graphics Data Size Limitations):

    The BLT engine is capable of transferring very large quantities of
    graphics data. Any graphics data read from and written to the
    destination is permitted to represent a number of pixels that
    occupies up to 65,536 scan lines and up to 32,768 bytes per scan
    line at the destination. The maximum number of pixels that may be
    represented per scan line’s worth of graphics data depends on the
    color depth.

With an RGBA32F color buffer (which has 16 bytes per pixel) this
imposes a maximum width of 2048 pixels.  Other pixel formats have
accordingly larger limits.

To make matters worse, if the pitch of the buffer is 32k or greater,
intel_copy_texsubimage's call to intelEmitCopyBlit will overflow
intelEmitCopyBlit's src_pitch and dst_pitch parameters (which are
16-bit signed integers).

We can conveniently avoid both problems by avoiding use of the blitter
when the miptree's pitch is >= 32k.

Fixes gles3conform "framebuffer_blit_functionality_magnifying_blit"
tests when the buffer width is equal to 8192.

Note: this is very similar to the recent patch "intel: Fix ReadPixels
on buffers whose width >= 32kbytes" except that it applies to
glCopyTexSubImage instead of glReadPixels.  In a future patch it would
be nice to refactor the code so that (a) overflow is avoided, and (b)
intelEmitCopyBlit is responsible for checking whether the blitter can
handle the width, so that all callers of intelEmitCopyBlit work
properly, rather than just these two.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965/disasm: Fix horizontal stride of dest registers

The bug: The printed horizontal stride was the numerical value of the
  BRW_HORIZONTAL_$N enum.
The fix: Translate the enum before printing.

Note: This is a candidate for the stable releases.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>