gallivm: Fix build with LLVM >= 3.6 r215967.

This LLVM 3.6 commit changed EngineBuilder constructor.

commit 3f4ed32b4398eaf4fe0080d8001ba01e6c2f43c8
Author: Rafael Espindola <rafael.espindola@gmail.com>
Date:   Tue Aug 19 04:04:25 2014 +0000

    Make it explicit that ExecutionEngine takes ownership of the modules.

    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215967 91177308-0d34-0410-b5e6-96231b3b80d8

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
r300g: Fix path to test programs for out-of-tree builds

Fixes make check in that case.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Teach os_get_total_physical_memory about Cygwin

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
i965/vec4: Allow reswizzling writemasks when swizzle is single-valued.

total instructions in shared programs: 4288033 -> 4266151 (-0.51%)
instructions in affected programs:     930915 -> 909033 (-2.35%)
glcpp: Use printf instead of "echo -n" in glcpp-test

I noticed that with /bin/sh on Mac OS X, "echo -n" does not work as
desired, (it actually prints "-n" rather than suppressing the final
newline). There is a /bin/echo that could be used (it actually works)
instead of the builtin echo.

But I decided it's more robust to just use printf rather than
hardcoding /bin/echo into the script.
glcpp: Fix glcpp-test-cr-lf "make check" test for Mac OS X

There were two problems with the way this script used sed on OS X:

  1. The OS X sed doesn't interpret "\r" in a replacement list as a
     carriage-return character, (instead it was inserting a literal
     'r' character).

     We fix this by putting an actual ^M character into the source of
     the script, (rather than a two-character escape sequence hoping
     for sed to do the right thing).

  2. When generating the test files with LF-CR ("\n\r") newlines, the
     OS X sed was adding an undesired final newline ("\n") at the end
     of the file. We avoid this by first using sed to add the ^M
     before the newlines, then using tr to swap the \r and \n
     characters. This way, sed never sees any lines ending with
     anything but \n, so it doesn't get confused and doesn't add any
     bogus extra newlines.

Tested-by: Vinson Lee <vlee@freedesktop.org>

Vinson's testing confirmed that this patch fixes FreeBSD as well.
mesa: Use a recursive mutex for the texture lock.

This avoids problems with things like meta operations calling functions
that want to take the lock while the lock is already held.  Basically,
the point is to guard against API reentrancy across threads...not to
guard against ourselves.

Dave Airlie opposed this change, but it makes master usable again and no
one proposed a better solution.  We can revert this if/when someone
does.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Tested-by: Chris Forbes <chrisf@ijw.co.nz>
i965,meta: Stop unlocking the texture to try and prevent deadlocks.

Unlocking the texture is not safe: another thread could come in and grab
it.  Now that we use a recursive mutex, this should work.  This also fixes
texture lock deadlocks in the new meta fast clear path.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
Tested-by: Chris Forbes <chrisf@ijw.co.nz>
st/clover: Fix build against LLVM SVN >= r215967 v2

v2: Tom Stellard
  - Properly destroy the Module

Reviewed-by: Francisco Jerez <currojerez@riseup.net>
radeon: Add work-around for missing Hainan support in clang < 3.6 v2

v2:
  - Add missing break.

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

CC: "10.2" <mesa-stable@lists.freedesktop.org>
pipe-loader: Fix memory leak v2

v2:
  - Change driver_name to char*

Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
CC: "10.2" <mesa-stable@lists.freedesktop.org>
r600g/compute: Use the first parameter in evergreen_set_global_binding()
r600g/compute: Don't initialize vertex_buffer_state masks to 0x2

cs_vertex_buffer_state.enabled_mask and
cs_vertex_buffer_state.dirty_mask are both updated when
r600_set_constant_buffer() is called, so we don't need to manually
update these values.

This fixes a crash with OpenCL programs that have a kernel with no
arguments.

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

CC: "10.2" <mesa-stable@lists.freedesktop.org>
r600g: Fix flat/smooth shade state toggle

If only the flat/smooth shade state changed between
two render calls the prior code would miss updating the
hardware state.

Also add check for sprite coord, potentially same type
of issue otherwise for it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81967
Signed-off-by: Glenn Kennard <glenn.kennard@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
radeonsi: add new CIK pci ids

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: mesa-stable@lists.freedesktop.org
radeonsi: add new SI pci ids

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: mesa-stable@lists.freedesktop.org
Increment version to 10.4.0-devel

Now that the 10.3 branch has been created
glx: Fix build since 679c2ef "glx/drisw: add support for DRI2rendererQueryExtension", when only building drisw renderer

v2:
- Move dri*_query_renderer_* into their respective dri*_priv.h headers
- Drop then unnneeded include of dri2.h from dri2_query_renderer.c
- Rename dri2_query_renderer.c as dri_common_query_renderer.c, as it's contents
now are used for more than dri[23]

Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Makefile: Switch from md5sums to sha256sums

We switched to these several stable releases ago, (since the MD5 algorithm has
been broken for some time), but only now did I get around to fixing this in
the Makefile rather than just performing this step manually.

CC: "10.2 10.3" <mesa-stable@lists.freedesktop.org>
docs: Add my notes on stable-branch patch criteria

This captures the set of rules I have been using for stable-branch management,
(starting with a discussion on the mesa-dev mailing list on July 2013, and
then refined through my own experience of performing stable-branch releases
since then).