glcpp: Check version_resolved in the proper place.

The check was in the wrong place, such that if a shader incorrectly put
a preprocessor token before the #version declaration, the version would
be resolved twice, leading to a segmentation fault when attempting to
redefine the __VERSION__ macro.

 #extension GL_ARB_sample_shading: require
 #version 130
 void main() {}

Also, rename glcpp_parser_resolve_version to
             glcpp_parser_resolve_implicit_version to avoid confusion.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glcpp: Resolve implicit GLSL version to 100 if the API is ES.

Fixes a regression since b2d1c579 where ES shaders without a #version
declaration would fail to compile if their precision declaration was
wrapped in the standard #ifdef GL_ES check.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74066
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Add constant evaluation of ir_binop_bfm.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Use bitfieldInsert in ldexp() lowering.

Shaves a few instructions off of lowered ldexp().

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Set proper swizzle when a channel is missing in vectorizing.

Previously, for example if the x channel was missing from a series of
assignments we were attempting to vectorize, the wrong swizzle mask
would be applied.

   a.y = b.y;
   a.z = b.z;
   a.w = b.w;

would be incorrectly transformed into

   a.yzw = b.xyz;

Fixes two transform feedback tests in the ES3 conformance suite.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73978
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73954
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Avoid combining statements from different basic blocks.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74113
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
gallivm: Workaround http://llvm.org/PR18600

We have code generation paths that carry out swizzles of AoS vectors via
bitwise shifts, as these tend to generate more efficient code than
straightforward byte shuffles.  But when the input is a constant the
additional bitwise arithmetic operations somehow don't really get
constant propagated properly, evenutally causing assertion failure in
InstCombine pass.

Therefore avoid the bug by using the trivial shuffles for constant
inputs.

Although the sample LLVM IR can cause a crash with any LLVM version,
this was only seen in practice with LLVM 3.2.

Reviewed-by: Matthew McClure <mcclurem@vmware.com>
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
loader: include dlfcn.h when building with HAVE_LIBUDEV

The code depending on the definitions is already wrapped
in the same conditional so go ahead and wrap the include.

Otherwise we'll brake compilation on platforms that are
missing the header. Add assert.h in there as well, as it
is introduced and used in the same fashon.

Cc: Eric Anholt <eric@anholt.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74122
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
c11: Add missing stdlib.h include.

For malloc/free.

Silences gcc mingw warnings.
r600g,radeonsi: Don't set resource_create in r600_common_screen_init()

r600g and radeonsi have different implementations of resource_create.

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

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
mesa: Allow depth = 0 parameter for TexImage3D.

Fixes the tests for the depth parameter for TexImage3D calls when the
target type is GL_TEXTURE_2D_ARRAY or GL_TEXTURE_CUBE_MAP_ARRAY
so that a depth value of 0 is accepted. Previously, the check
incorrectly required the depth argument to be atleast 1.

Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
gbm: Make libgbm.so.1 symlink.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Ignore 'centroid' interpolation qualifier in case of persample shading

I missed this change in commit f5cfb4a. It fixes the incorrect
rendering caused in Dolphin Emulator.

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

Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Tested-by: Markus Wick <wickmarkus@web.de>
Reviewed-by: Matt Turner <mattst88@gmail.com>
loader: fix running with --disable-egl builds

I sometimes build without EGL just for speed purposes, however
it no longer finds my drivers when I do due to the HAVE_LIBUDEV
defines being wrong.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
mesa: Generate correct error code in glDrawBuffers()

OpenGL 3.3 spec expects GL_INVALID_OPERATION:
 "For both the default framebuffer and framebuffer objects, the
  constants FRONT, BACK, LEFT, RIGHT, and FRONT AND BACK are not
  valid in the bufs array passed to DrawBuffers, and will result
  in the error INVALID OPERATION."

But OpenGL 4.0 spec changed the error code to GL_INVALID_ENUM:
 "For both the default framebuffer and framebuffer objects, the
  constants FRONT, BACK, LEFT, RIGHT, and FRONT_AND_BACK are not
  valid in the bufs array passed to DrawBuffers, and will result
  in the error INVALID_ENUM."

This patch changes the behaviour to match OpenGL 4.0 spec
Fixes Khronos OpenGL CTS draw_buffers_api.test.

V2: Update the comment in code.

Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965: Add can_do_saturate() method to backend_instruction.

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
i965/fs: Add a saturation propagation optimization pass.

Transforms, for example,

mul     vgrf3, vgrf2, vgrf1
mov.sat vgrf4, vgrf3

into

mul.sat vgrf3, vgrf2, vgrf1
mov     vgrf4, vgrf3

which gives register_coalescing an opportunity to remove the MOV
instruction.

total instructions in shared programs: 1515039 -> 1504634 (-0.69%)
instructions in affected programs:     798586 -> 788181 (-1.30%)
GAINED:                                0
LOST:                                  4

Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>