st/mesa: add support for viewport index semantic

This adds GS output and FS input support, even though FS input
support isn't supported until GLSL 4.30 from what I can see.

Signed-off-by: Dave Airlie <airlied@redhat.com>
st/mesa: add support for GL_ARB_viewport_array (v0.2)

this just ties the mesa code to the pre-existing gallium interface,
I'm not sure what to do with the CSO stuff yet.

0.2: fix min/max bounds

Acked-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Dave Airlie <airlied@redhat.com>
r600g: add support for multiple viewports.

tested on rv635 and barts.

Signed-off-by: Dave Airlie <airlied@redhat.com>
docs/GL3.txt: denote r600g support for ARB_viewport_array

Signed-off-by: Dave Airlie <airlied@redhat.com>
i965/fs: Simplify FS_OPCODE_SET_SAMPLE_ID stride mashing a bit.

stride(brw_vec1_reg(...) ...) takes some register, changes the strides,
then changes the strides again.  Let's do it once.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
i965/fs: Simplify FS_OPCODE_SET_OMASK stride mashing a bit.

In the first case, we can simply call stride(mask, 16, 8, 2) rather than
creating a new register with a different stride, then immediately
changing it a second time.

In the second case, the stride was already what we wanted, so we can
just use mask without any changes at all.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
glsl: Add locking to builtin_builder singleton

Consider a multithreaded program with two contexts A and B, and the
following scenario:

1. Context A calls initialize(), which allocates mem_ctx and starts
   building built-ins.
2. Context B calls initialize(), which sees mem_ctx != NULL and assumes
   everything is already set up.  It returns.
3. Context B calls find(), which fails to find the built-in since it
   hasn't been created yet.
4. Context A finally finishes initializing the built-ins.

This will break at step 3.  Adding a lock ensures that subsequent
callers of initialize() will wait until initialization is actually
complete.

Similarly, if any thread calls release while another thread is still
initializing, or calling find(), the mem_ctx/shader would get free'd while
from under it, leading to corruption or use-after-free crashes.

Fixes sporadic failures in Piglit's glx-multithread-shader-compile.

Bugzilla: https://bugs.freedesktop.org/69200
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.1 10.0" <mesa-stable@lists.freedesktop.org>
i965: Don't call abort() on an unknown device.

If we don't recognize the PCI ID, we can't reasonably load the driver.
However, calling abort() is quite rude - it means the application that
tried to initialize us (possibly the X server) can't continue via
fallback paths.  We already have a more polite mechanism - failing to
create the context.  So, just use that.

While we're at it, improve the error message.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73024
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Tested-by: Lu Hua <huax.lu@intel.com>
vl: add H264 encoding interface

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Leo Liu <leo.liu@amd.com>
omx: fix some minor configure.ac issues

Matt Turner noted the incorrect order, but I somehow forgotten to
change it before pushing upstream. The other one is a typo during rebase.

Signed-off-by: Christian König <christian.koenig@amd.com>
omx/radeonsi: fix target

Another minor typo.

Signed-off-by: Christian König <christian.koenig@amd.com>
configure: error out when building radeonsi without gallium-llvm

--enable-gallium-llvm is required by radeonsi. Currently we
check only for LLVM_VERSION_INT which is 0, whenever gallium-llvm
is disabled explicitly.

./configure --with-gallium-drivers=r600,radeonsi --disable-gallium-llvm

v2: Correct typo in error message. Spotted by Tom Stellard

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
pipe-loader: drop obsolete libudev.h include

All the udev code is in the loader, so there is no
reason for us to include this header.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
configure: drop LIBUDEV_CFLAGS from X11_INCLUDES

The cflags are explicitly included in the only Makefile that
handles udev dependant code.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
egl_dri2: remove LIBUDEV_CFLAGS from Makefile.am

None of the code within builds or (explicitly) requires udev.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
egl-static: stop linking against libudev

No longer required since all the udev code is in the loader.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
gallium/tests: do not link against libudev

Previously the linking was required due to dependency of udev in the
pipe-loader. Now this is no longer the case, as we dlopen the library.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
opencl: do not link against libudev

Previously the linking was required due to dependency of udev in the
pipe-loader. Now this is no longer the case, as we dlopen the library.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
gbm: drop unneeded dependency of libudev

As of recently we dlopen the library, additionally the only
code that is including the libudev.h header, is the loader.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
configure: cleanup libudev handling

Add the explicit note about the required version during configure.
Require the same version (151) of udev when building the pipe-loader.
Mention the udev version requirement in GBM Requires.private.

v2: Resolve a couple of silly typos. Spotted by Ilia
v3: Cleanup platfrom/platform typo. Spotten by Stefan

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