freedreno/a3xx/compiler: fix neg mov's

create_mov() was fixed up to handle neg/abs properly for interal mov's,
using absneg.f, but forgot to fix it for TGSI MOV's.  The problem with
using add.f to handle negated mov's is that we can only take a single
const reg src.  So:

  MOV TEMP[n], -CONST[m]

would turn into:

  add.f Rdst, (neg)CONST[m], 0.0

which would not work.  Anyways, just remove the extra code and always
use create_mov() which DTRT.

This fixes piglit vs-op-neg-int test.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
freedreno/a3xx/compiler: add CEIL

fixes piglit glsl-fs-ceil

Signed-off-by: Rob Clark <robclark@freedesktop.org>
i965: Stop advertising GL_MESA_ycbcr_texture.

The "new" fragment shader backend has never supported the necessary
color conversion code for this to work.  We began using the new backend
in Mesa 7.10 for GLSL (commit a81d423d93f22a948f3aa4bf73, October 2010),
and for ARB_fragment_program in Mesa 9.1 (commit 97615b2d8c7c3cea6fd3a4,
August 2012).

I haven't heard any complaints, so I don't think anyone will miss this
feature.  I believe mplayer used it at one point, but these days
defaults to other paths anyway.

Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <idr@freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
svga: move LIST_INITHEAD(dirty_buffers) earlier in svga_context_create()

Fixes a crash in svga_context_flush_buffers() if we use the 'draw' module
for AA lines (when the device doesn't support that feature).  We need to
initialize this list before we setup the swtnl pieces.

Found/fixed by Charmaine Lee.

Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
freedreno/a3xx: assert() -> debug_assert()

We hit this assert with some piglit tests.  Which appears to be a bug
outside of freedreno.  Previously we were relying on assert() being
redefined to debug_assert() so that we didn't crash in release builds.
Somehow that stopped working.  So just use debug_assert() directly.

Signed-off-by: Rob Clark <robclark@freedesktop.org>
glx: drop obsolete _XUnlock_Mutex in __glXInitialize error path

With commit 1f1928db001(glx: Drop _Xglobal_lock while we create and
initialize glx display) we've split the big _Xglobal_lock handling in
a more fine grained manner.

Unfortunatelly we forgot to drop the unlock_mutex on the error paths,
leading to undefined behaviour as the mutex is already unlocked.

Cc: Kristian Høgsberg <krh@bitplanet.net>
Cc: "9.2 10.0 10.1"  <mesa-stable@lists.freedesktop.org>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Partially revert "st/xa: Fix advertized version number and try to avoid future discrepancies"

This reverts commit 61bedc3d6b08943f015f9d590c07a6af36c2a92c.

As the header is the one defining the API/ABI and is distributed
during installation, we should be using it rather than re-defining
the XA version in configure.ac.

Bump the version in the header to 2.2.0, to reflect what was the
original intent of commit 42158926c6d7d3ddbe61b9a04d60544ff1b50a96.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Partially revert bba9c28 "configure: use LIB_EXT rather than hardcoded .so"

Filenames passed to dlopen() don't need to use the platform's default extension
for shared libraries.

Using the '.so' extension when dlopen()ing DRI drivers is hardcoded into mesa
and the X server, so it should be hardcoded here in the Makefile as well.

A similar fix is probably also needed for gallium DRI drivers.

(Consider that if we were starting from scratch, perhaps we would use a custom
extension like .dri instead)

Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
build: force .so extension for the gallium dri modules

While linux uses .so as a default extension for shared libraries that is
not the case for other platforms. The loader in libGL (and others) assumes
that the dri module will always have a .so extension, thus it will fail
to load on the affected platforms.

Spotted-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>