The formula we were previously using for asinh:

    asinh x = ln(x + sqrt(x * x + 1))

is numerically unstable: when x is a large negative value, the quantity

    x + sqrt(x * x + 1)

is a small positive value (on the order of 1/(2|x|)).  Since the
logarithm function is very sensitive in this range, any error in the
computation of the square root manifests as a large error in the
result.

This patch changes to the equivalent formula:

    asinh x = sign(x) * ln(abs(x) + sqrt(x * x + 1))

which is only slightly more expensive to compute, and is numerically
stable for all x.

Fixes piglit tests
spec/glsl-1.30/execution/built-in-functions/[fv]s-asinh-*.

Reviewed-by: Chad Versace <chad@chad-versace.us>
Acked-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

Fixes the glsl-1.30/compiler/built-in-functions/trunc-* tests under 1.30.

Reviewed-by: Chad Versace <chad@chad-versace.us>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Reviewed-by: Chad Versace <chad@chad-versace.us>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Somehow we managed to get the unsigned int vectors, but not scalar.
Fixes _mesa_problem complaints in piglit's uint tests.

Reviewed-by: Chad Versace <chad@chad-versace.us>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Reviewed-by: Chad Versace <chad@chad-versace.us>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Bitshifts are one of the rare places that GLSL allows mixed base types
without an implicit conversion occurring.

Reviewed-by: Chad Versace <chad@chad-versace.us>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

For hardware drivers, we only have ir_to_mesa called for the purposes
of potential swrast fallbacks (basically never on a 1.30 driver),
which we don't really care about.  This will allow 1.30 to be
implemented without rewriting swrast for it.

Reviewed-by: Chad Versace <chad@chad-versace.us>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

On pre-GEN6 chips, the VUE slots set aside for clip distance aren't
actually used, so there is no reason for the clipper to waste time
interpolating them.

When commit 62bad54727 changed the enum
value used to represent these VUE slots, that caused the clipper to
start interpolating them as an accidental side effect.  This patch
reverts to the old clipper behavior.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

This patch corrects two errors in the computation of the psiz/flags
VUE slot on pre-GEN5 when using the new VS backend:

- The clip flags (which should be stored in the w component of the
  first VUE slot) were being accidentally duplicated in all other
  components of that VUE slot, causing partially clipped triangles to
  sometimes disappear completely.

- The OR instruction wasn't being stored in "inst", causing the
  BRW_PREDICATE_NORMAL flag to be applied to the wrong instruction.

This patch fixes regressions in clipping behavior when using shaders
on GEN4-5.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

This constructor was storing its argument in the wrong field of the
"imm" enum, resulting in it being converted to a float when it should
have remained an unsigned integer.  This was preventing clipping from
working properly on pre-GEN6.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

In pre-GEN6, when using clip planes, both the vertex shader and the
clipper need access to the client-supplied clip planes, since the
vertex shader needs them to set the clip flags, and the clipper needs
them to determine where to insert new vertices.

With the old VS backend, we used a clever optimization to avoid
placing duplicate copies of these planes in the CURBE: we used the
same block of memory for both the clipper and vertex shader constants,
with the clip planes at the front of it, and then we instructed the
clipper to read just the initial part of this block containing the
clip planes.

This optimization was tricky, of dubious value, and not completely
working in the new VS backend, so I've removed it.  Now, when using
the new VS backend, separate parts of the CURBE are used for the
clipper and the vertex shader.  Note that this doesn't affect the
number of push constants available to the vertex shader, it simply
causes the CURBE to occupy a few more bytes of URB memory.

The old VS backend is unaffected.  GEN6+, which does clipping entirely
in hardware, is also unaffected.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Now that i965 supports 8 clip planes instead of 6, the size of the
brw_vs_compile::userplane array needs to be increased to 8.  Changed
the array size to MAX_CLIP_PLANES so that if the number changes again
in the future, this array size won't be missed.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

When using user-defined clipping planes, the i965 driver compacts the
array of clipping planes so that disabled clipping planes do not
appear in it--this saves precious push constant space and makes it
easier to generate the pre-GEN6 clip program.  As a result, when
enabling clipping planes in GEN6+ hardware, we always enable clipping
planes 0 through n-1 (where n is the number of clipping planes
enabled), regardless of which clipping planes the user actually
requested.

However, we can't do this when using gl_ClipDistance, because it would
be prohibitively complex to compact the gl_ClipDistance array inside
the user-supplied vertex shader.  So, when enabling clipping planes in
GEN6+ hardware, if gl_ClipDistance is in use, we need to pass the
user-supplied enable flags directly through to the hardware rather
than just enabling the first n planes.

Fixes Piglit test vs-clip-distance-enables.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Since the i965 driver supports 8 clipping planes now, we need 4 bits
to store the number of user clipping planes, not 3.

In theory this isn't strictly necessary, since brw_clip.h is only used
on pre-GEN6, and pre-GEN6 only advertises support for 6 clipping
planes, but it seems wise to err on the safe side.

In the process I removed the pad0 element of struct
brw_clip_prog_key--it doesn't seem necessary because the compiler
automatically inserts padding if needed.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

It was replaced by _mesa_override_glsl_version().

Reviewed-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad@chad-versace.us>

Override the context's GLSL version if the environment variable
MESA_GLSL_VERSION_OVERRIDE is set. Valid values for
MESA_GLSL_VERSION_OVERRIDE are integers, such as "130".

MESA_GLSL_VERSION_OVERRIDE has the same behavior as INTEL_GLSL_VERSION,
except that it applies to all drivers, not just Intel's. Since the former
supercedes the latter, this patch disables the latter.

Reviewed-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad@chad-versace.us>

stObj->base.BaseLevel and firstImage->base.Level have the same value
but the later looks more consistent in the function call.

To match makefile build.

Unlike on Unix, os.rename(src, dst) will fail on Windows if the dst file
already exists.  Remove it first.

Broken by 6dd284f7c8.

This is required for D3D1x and supported by hardware.

So that GL_VERSION includes the git head hash id when building with scons.

Reviewed-by: José Fonseca <jfonseca@vmware.com>

Again, the check was needlessly specific: this works fine on Gen7.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

The check was designed to forbid it on old generations (Gen5/Ironlake),
not on new ones.  It just works on Gen7/Ivybridge.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

It's handled by MapTextureImage() now.

It's handled by MapTextureImage() now.

The mesa core code uses MapTextureImage() like we need now.

v2: Drop mapping around _mesa_generate_mipmap for compressed, since
    the whole path ends up going through MapTextureImage(), and the
    meta decompression code ended up causing us to lose track of the
    region that was originally mapped and assertion fail.

v2: Changes by Brian to MapTexImage in the decompression path.
v3: Changes by anholt to fix srcRowStride for decompression of NPOT.

Tested-by: Brian Paul <brianp@vmware.com> (v2)

Tested-by: Brian Paul <brianp@vmware.com>

Note that the implementation before and after appears to be broken in
its handling of Z24_S8 vs S8_Z24.

Tested-by: Brian Paul <brianp@vmware.com>

Tested-by: Brian Paul <brianp@vmware.com>

Tested-by: Brian Paul <brianp@vmware.com>

This code is about to stop needing ->Data and using MapTextureImage().

Tested-by: Brian Paul <brianp@vmware.com>

This changes drivers to not map the texture on their own before
calling _mesa_get_compressed_teximage().

Tested-by: Brian Paul <brianp@vmware.com>

EXT_texture_integer also specifies border color should be a color
union, the values are used according to the texture sampler format.

(update docs)

Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Brian Paul <brianp@vmware.com>

It is necessary to manually set the GL version to 3.0 in order to run
Piglit tests that use glGetUniform*().

This patch allows one to override the version of the OpenGL context by
setting the environment variable MESA_GL_VERSION_OVERRIDE.

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Chad Versace <chad@chad-versace.us>

This is a follow-up to commit
2d686fe911a89fa477ee3848da41ebfb100500bf, which added decoding of
GL_CLIP_DISTANCE[67] to the _mesa_set_enable() function.  This patch
makes the following additional fixes:

- Uses GL_CLIP_DISTANCEi enums consistently within enable.c rather
  than the deprecated GL_CLIP_PLANEi enums.

- Generates an error if the user tries to access a clip flag that is
  unsupported by the hardware.

- Applies the same change to _mesa_IsEnabled(), so that querying clip
  flags using glIsEnabled() works properly.

- Applies corresponding changes to get.c, so that querying clip flags
  using glGet*() works properly.

Fixes piglit test clip-flag-behavior.

Reviewed-by: Brian Paul <brianp@vmware.com>

Caught by valgrind.  I never saw a segfault from it (probably because
it's hard to have much more of any other file than GRF).

We call all the other drm_intel_bo pointers in intel/*.h "bo", so this
one was rather out of place.

Acked-by: Kenneth Graunke <kenneth@whitecape.org>

We get called for TexImage higher up, and in a relatively normal way
(pixels == NULL is common for FBO setup).

Acked-by: Kenneth Graunke <kenneth@whitecape.org>