There was already a loop here to look for multiple token pastes, but
it was mistakenly incrementing the iterator counter after performing
one paste.

Instead, leave the loop iterator in place to coalesce as many tokens
as necessary into one.

This fixes the recently add 096-paste-twice test as well as the
following piglit test:

	spec/glsl-1.30/preprocessor/concat/concat-03.frag

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Carl Worth <cworth@cworth.org>

This is something that piglit is exercising that currently fails.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Carl Worth <cworth@cworth.org>

Remove NeedValidate and ValidateTnlModule.

Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad@chad-versace.us>

The GL spec says that luminance values are returned as (l, 0, 0, 1),
L/A values as (l, 0, 0, a) and intensity values as (i, 0, 0, 1).
Use the pixel transfer scale controls to implement that.
This fixes a few failures in the new piglit getteximage-formats
test when getting a compressed L or L/A image.

If color material mode is enabled, constant buffer entries related
to the material coefficients will depend on glColor.  So add
_NEW_CURRENT_ATTRIB to the bitset returned for material-related
constants in _mesa_program_state_flags().

This fixes a bug exercised by the new piglit draw-arrays-colormaterial
test.

Note: This is a candidate for the 7.11 branch.

This hasn't been needed so far since none of the core Mesa code paths
that call ctx->Driver.AllocTextureImageBuffer() are used with the
state tracker.  That will change in upcoming patches.
Note that this function duplicates some code seen in the st_TexImage()
function.  That can be cleaned up later.

The target, level and texObj can be obtained through the texImage
parameter.  We could make similar changes for the TexImage() hooks too.

Reviewed-by: Eric Anholt <eric@anholt.net>

This fixes a build error introduced with commit
"winsys/svga: Update to vmwgfx kernel module 2.1"
if both the svga driver and the xorg state tracker was enabled
at the same time.

If needed we can re-add a minimal target for basic functionality.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>

When an FBO is rendering to a texture (rather than a renderbuffer),
Gallium sets up an internal renderbuffer to handle the rendering, and
copies over enough texture state to make this work.

InternalFormat was missed out, causing glTexCopyImage to take a slow
path unnecessarily.

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

Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Brian Paul <brianp@vmware.com>

Introduces fence objecs and a size limit on query buffers.
The possibility to map the fifo from user-space is gone, and
replaced by an ioctl that reads the 3D capabilities.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecranz <jakob@vmware.com>

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>

Don't store references to these on the surface but on the context.
References to transfers are still stored on the surface since we allow
only a single map of a surface at a time.

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>

All drivers remaining in Mesa support this extension.  This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.

This extension was previously not supported on mach64, mga, and savage
(Savage3D and other pre-Savage4).

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

All drivers remaining in Mesa support this extension.  This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.

This extension was previously not supported on i810, mach64, mga,
savage, sis, and tdfx (Voodoo Banshee and Voodoo3).

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

All drivers remaining in Mesa support this extension.  This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.

This extension was previously not supported on mach64.

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

All drivers remaining in Mesa support this extension.  This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.

This extension was previously not supported on mach64, mga, or r128.

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

All drivers remaining in Mesa support this extension.  This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.  The existing support is already partially
broken in Mesa (e.g., querying GL_TEXTURE_ENV_MODE in OpenGL ES 2.x).
This patch does not change the situation in any way.

It looks like the only hardware supported by Mesa that cannot do
ARB_texture_env_combine is pre-NV10 NVIDA chips.  It appears that
these chips cannot do the GL_SUBTRACT mode.  Based on looking at older
copies of nvOpenGLspecs.pdf found on the net, NVIDIA never supported
ARB_texture_env_combine on those chips either.

This extension was previously not supported on mach64, mga (G200),
r128, savage, sis, and tdfx (Voodoo Banshee and Voodoo3).

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

All drivers remaining in Mesa support this extension.  This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.  The existing support is already partially
broken in Mesa (e.g., querying GL_TEXTURE_ENV_MODE in OpenGL ES 2.x).
This patch does not change the situation in any way.

This extension was previously not supported on mach64, mga (G200),
savage (Savage3D and other pre-Savage4), sis, and tdfx (Voodoo
Banshee).

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

All drivers remaining in Mesa support this extension.  This extension
is either required or optional features in desktop OpenGL, OpenGL ES
1.x, and OpenGL ES 2.x.  The existing support is already partially
broken in Mesa (e.g., querying GL_CLIENT_ACTIVE_TEXTURE in OpenGL ES
2.x).  This patch does not change the situation in any way.

This extension was previously not supported on i810, mga (G200), or
tdfx (Voodoo Banshee).

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

This turns some of the null check warnings in commit
023ca40d80 back to asserts, as
the underlying cause of fdo bug 40591 should be fixed now.

Prevents segfaults when a opaque tile is found without state change.

Instead of None.

We can use the core Mesa code for glGetTexImage() since it handles the
image mapping/unmapping now.  We'll keep the decompress_with_blit() path
in the hope that it's faster than core Mesa's software decompression code.

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

It's part of pb_buffer already.

It may happen when two drivers share one winsys.

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>