targets/xvmc: automake: link against libmesautil.la

Or the build will fail due to unresolved symbols.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
targets/omx: automake: link against libmesautil.la

Or the build will fail due to unresolved symbols.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
gallium/tests: automake: link against libmesautil.la

Or the build will fail due to unresolved symbols.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
llvmpipe/tests: automake: link against libmesautil.la

Or the build will fail due to unresolved symbols.

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
libgl-xlib: drop duplicate mesautil from scons build

Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@intel.com>
meta: Disable dithering during glBlitFramebuffer

According to the GL spec the only fragment operations that should affect
glBlitFramebuffer are “the pixel ownership test, the scissor test, and sRGB
conversion”. That implies that dithering should not be performed so we need to
disable it when implementing the blit with a render.

Before commit 05b52efbc97731 the dithering state would be left as whatever the
application picks (the default being GL_TRUE) and after that commit it was
explicitly enabled. Neither of these were correct.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81828
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
mesa: update glext.h to version 20140725

Reviewed-by: Matt Turner <mattst88@gmail.com>
mesa: update glxext.h to version 20140725

Reviewed-by: Matt Turner <mattst88@gmail.com>
mesa: update wglext.h to version 20140630

Reviewed-by: Matt Turner <mattst88@gmail.com>
glsl_to_tgsi: Fix typo shader_program -> shader

This was a regression introduced by commit
f4b0ab7afd83c811329211eae8167c9bf238870c ('st/mesa: fix incorrect size
of UBO declarations') which caused an assertion failure while compiling
shaders of e.g. UE4 demos.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81834
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa: make vertex array type error checking a little more efficient

Compute the bitmask of supported array types once instead of every
time we call a GL vertex array function.

Reviewed-by: Matthew McClure <mcclurem@vmware.com>
st/mesa: adjust Z coordinates for quad clearing

Specify the quad's Z position in clip coordinate space, not
normalized Z space.  Use viewport scale, translation = 0.5, 0.5.

Before, we were specifying the quad's Z position in [0,1] and using
viewport scale=1.0, translate=0.0.  That works fine, unless your
driver needs to work in clip coordinate space and needs to
reconstruct viewport near/far values from the scale/translation
factors.  The VMware svga driver falls into that category.

When we did that reconstruction we wound up with near=-1 and far=1
which are outside the limits of [0,1].  In some cases, this caused
the quad to be drawn at the wrong depth.  In other cases it was
clipped away.

Fixes some scissored depth clears with VMware driver.  This should
have no effect on other drivers.  We're already using these values
for the glBitmap and glDraw/CopyPixels code.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
util/tests/hash_table: Link against libmesautil instead of libmesa

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

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
mesa: Add a format description CSV file

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa: Add python to parse the formats CSV file

The basic concept for the format parser was taken from the format CSV
parser in gallium/auxilliary/util.  However, this one has been altered in a
number of ways:

 * Removed big endian vs. little endian stuff (mesa doesn't need it)
 * Better documentation: Almost every method has a full docstring
 * An actual Swizzle class with methods for composition and inverses
 * Over-all cleaner (in my opinion) implementation and class interactions
 * A few bug fixes

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa/main: Add python code to generate the format_info structure

This adds a python script called format_info.py that is used to generate a
single format_info.c file that contains the filled-out format_info array.

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa/formats: Autogenerate the format_info structure from a CSV file

Instead of a having all of the format metadata in a gigantic hard-to-edit
array of type struct format_info, we now have a human-readable CSV file.
The CSV file also contains more format information than the format_info
struct contained so we can potentially make format_info more detailed later.

The python to generate the format information was added the previous
commit.  This commit turns it on in both automake and scons builds.

v2: Split into two commits and stuff to generate format_info.c from scons

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa/formats: Remove IndexBits

Mesa hasn't supported color-indexed textures for some time.  This is 0 for
all texture formats, so we don't need to store it.

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa/formats: Add layout and swizzle information

v2: Move the MESA_FORMAT_SWIZZLE enum to the top of the file

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
mesa/imports: Add a _mesa_half_is_negative helper function

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>