mesa/get: Move MAX_LIGHTS from GL/ES2 to GL/ES1.

It's required for ES 1.0 and 1.1, and isn't specified for ES 2.

While the comment says Mesa depends on it internally, removing it from
ES2 doesn't seem to regress any Piglit or ES2 conformance tests.

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

meta: Don't enable TEXTURE_RECTANGLE when it's unsupported.

In particular, drivers don't enable this in ES 1.1 contexts.

Prior to this, none of the OpenGL ES 1.1 conformance tests passed.

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

i915g: Silence warning.

We still need to investigate LIS7 though.

i915g: Fix comment.

mesa: remove some unneeded forward struct declarations

st/mesa: fix comment

mesa: remove unused _mesa_rescale_teximage2d() function

It was only used by the old tdfx driver, IIRC.

mesa: remove unused gl_texture_image::DriverData field

Was only used by some older/removed DRI drivers.

st/mesa: don't use gl_texture_image::RowStride

It's always the same as the texture width.

st/mesa: completely stop using gl_texture_image::Data

Instead, use the new st_texture_image::TexData field to hold texture
images that don't fit the parent object's mipmap buffer.

st/mesa: stop using gl_texture_image::Data when mapping/unmapping textures

Since core Mesa no longer depends on gl_texture_image::Data pointing to
mapped texture buffers we don't have to mess with it all over the place
in the state tracker.  Now Data is only used to point to malloc'd memory
that holds images which don't fit in the texture object's mipmap buffer.

mesa: get rid of imageOffsets arrays in texstore code

These were used to find the start of a 3D image slice (or 2D array texture
slice) given a base address.  Instead, use a simple array of address of
image slices instead.

This is a step toward getting rid of the gl_texture_image::ImageOffsets
field.

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

st/glx: remove the duplicated Drawable member.

If you want to access it, you should use the Drawable in xlib_drawable instead.

glsl: Consider "__" in identifers as reserved.

Fixes double-underscore-*.frag.

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

swrast: update texfetch_funcs table for new int/uint formats

This only adds dummy entries to the table to fix failed assertions.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=41491

i965 Gen6: Implement gl_ClipVertex.

This patch implements proper support for gl_ClipVertex by causing the
new VS backend to populate the clip distance VUE slots using
VERT_RESULT_CLIP_VERTEX when appropriate, and by using the
untransformed clip planes in ctx->Transform.EyeUserPlane rather than
the transformed clip planes in ctx->Transform._ClipUserPlane when a
GLSL-based vertex shader is in use.

When not using a GLSL-based vertex shader, we use
ctx->Transform._ClipUserPlane (which is what we used prior to this
patch).  This ensures that clipping is still performed correctly for
fixed function and ARB vertex programs.  A new function,
brw_select_clip_planes() is used to determine whether to use
_ClipUserPlane or EyeUserPlane, so that the logic for making this
decision is shared between the new and old vertex shaders.

Fixes the following Piglit tests on i965 Gen6:
- vs-clip-vertex-const-accept
- vs-clip-vertex-const-reject
- vs-clip-vertex-different-from-position
- vs-clip-vertex-equal-to-position
- vs-clip-vertex-homogeneity
- vs-clip-based-on-position
- vs-clip-based-on-position-homogeneity
- clip-plane-transformation clipvert_pos
- clip-plane-transformation pos_clipvert
- clip-plane-transformation pos

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

mesa: Add a gl_vert_result for gl_ClipVertex.

Before this patch, clip planes didn't work properly in Mesa when using
vertex shaders, because Mesa assigned both gl_ClipVertex and
gl_Position to the same gl_vert_result (VERT_RESULT_HPOS).  As a
result, backends couldn't distinguish between the two variables, so
any shader that wrote different values to them would fail to work
properly.

This patch paves the way for proper support of gl_ClipVertex by
creating a new enumerated value in gl_vert_result for it
(VERT_RESULT_CLIP_VERTEX).  After this patch, a back-end may add
support for gl_ClipVertex using the following algorithm:

- If using a user-supplied GLSL vertex shader:
  - If the bit corresponding to VERT_RESULT_CLIP_VERTEX is set in
    gl_program::OutputsWritten:
    - Clip using the vertex shader output VERT_RESULT_CLIP_VERTEX and
      the clip planes defined in gl_context::Transform.EyeUserPlane.
  - Else:
    - Clip using the vertex shader output VERT_RESULT_HPOS and the
      clip planes defined in gl_context::Transform.EyeUserPlane.
- Else (either using fixed function or an ARB vertex program):
  - Clip using the vertex shader output VERT_RESULT_HPOS and the clip
    planes defined in gl_context::Transform._ClipUserPlane (*)

where (*) represents the normal Mesa behavior before this patch.

An example of implementing the above algorithm can be found in the
patch that follows this one, which implements gl_ClipVertex in i965
Gen6.

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

llvmpipe: Fix the 4 planes (lines) case properly.

The previous change was not effective for lines, because there is no
4 planes 4x4 block rasterization path: it is handled by the 16x16 block
case too, and the 16x16 block was not being budged as it should.

This fixes assertion failures on line rasterization.

llvmpipe: Ensure the 16x16 special rasterization path does not touch outside the tile.

llvmpipe has a few special rasterization paths for triangles contained in
16x16 blocks, but it allows the 16x16 block to be aligned only to a 4x4
grid.

Some 16x16 blocks could actually intersect the tile
if the triangle is 16 pixels in one dimension but 4 in the other, causing
a buffer overflow.

The fix consists of budging the 16x16 blocks back inside the tile.

mesa: update fbo format tablet for integer types.

This updates the fbo format table for the integer types.

Signed-off-by: Dave Airlie <airlied@redhat.com>

mesa/texstore: add texstore paths for all the integer types.

This just adds the entries to the table and fixes the asserts up.

The int32 one is definitely wrong, since it uses a float temp
which will lose precision, but its no worse than now.

Signed-off-by: Dave Airlie <airlied@redhat.com>

mesa/texformat: update choose_tex_format for integer types.

This adds the integer types to the tex format chooser.

Signed-off-by: Dave Airlie <airlied@redhat.com>

mesa/formats: add rest of integer formats.

This is taken from reading EXT_texture_integer + EXT_texture_rg in combination,

Comments on necessity of each format, naming of formats and bugs in the
formats tables please.

Is there any formats I've missed?

Eric looked over this to make sure its consistent at least.

As I've changed the ordering of things in the format table, the follow
patches are required to avoid regression.

Signed-off-by: Dave Airlie <airlied@redhat.com>

texstore: create texstore table on first access.

As per Brian's suggestion we can generate this table at first start
to make sure its correct. This is a sad workaround for compilers which
don't support named initialiser. (its 2011).

Signed-off-by: Dave Airlie <airlied@redhat.com>

glsl: Remove unneeded headers.

egl: restore missing \ in Makefile

r200/r300/r600: remove dangling radeon_tex_getimage.c symlinks.

Commit d1fda903 (radeon: Drop mapping we were doing around
glGetTexImage()) removed the common Radeon source file
radeon_tex_getimage.c, and pulled it out of the r200, r300, r600, and
radeon makefiles.  But it left behind the symlinks that were being
used to share that file among the four directories.

This patch removes the dangling symlinks.

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

glapi: Enclose glapi.h in an extern "C" block when included by C++.

Fixes a build failure introduced in commit
b7fa0d0727a3a9e1f64d3cfc7a0f157b35dec09e.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-and-tested-by: Paul Berry <stereotype441@gmail.com>

scons: add new files to src/mesa/SConscript

softpipe: fix Z interpolation invariance bug

We want quad/pixel Z values to be interpolated exactly the same for
multi-pass algorithms.  Because of how the optimized Z-test code is
written, we can't cull the first quad in a run even if it's totally
killed.  See the comment for more info.

NOTE: This is a candidate for the 7.11 branch.

softpipe: add check for DO_PSTIPPLE_IN_HELPER_MODULE

We only want to generate the fragment shader variant that does
stippling if DO_PSTIPPLE_IN_HELPER_MODULE is being used.

mesa: Remove unused gl_program::Attributes

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

mesa: Determine GL_ACTIVE_ATTRIBUTE_MAX_LENGTH by walking the GLSL IR.

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

mesa: Determine GL_ACTIVE_ATTRIBUTES by walking the GLSL IR.

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

mesa: Remove unused gl_shader_program::Attributes

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

mesa: Make _mesa_GetActiveAttribARB use the attributes in the shader IR

Instead of relying on the mirror in the Mesa IR assembly shader, just
use the variables actually stored in the GLSL IR.  This will be a bit
slower, but nobody cares about the performance of glGetActiveAttrib.

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

mesa: Move _mesa_GetActiveAttribARB to shader_query.cpp

This just folds get_active_attrib into _mesa_GetActiveAttribARB
and moves the resulting function function to the other source file.
More changes are coming soon.

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

linker: Use gl_shader_program::AttributeBindings for attrib locations

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

mesa: Add gl_shader_program::AttributeBindings

This currently mirrors the state tracking
gl_shader_program::Attributes, but I'm working towards eliminating
that.

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

mesa: Move _mesa_BindAttribLocationARB to shader_query.cpp

This just folds bind_attrib_location into _mesa_BindAttribLocationARB
and moves the resulting function function to the other source file.
More changes are coming soon.

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

mesa: Add string_to_uint_map facade class

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Acked-by: Paul Berry <stereotype441@gmail.com>

mesa: Add hash_table_replace

hash_table_replace doesn't use get_node to avoid having to hash the key twice.

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

mesa: Move _mesa_GetAttribLocationARB to shader_query.cpp

This allows querying the linked shader itself rather than the Mesa IR.
This is the first step towards removing gl_program::Attributes.

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

glsl: Delete symbol table in post-link shaders

The symbol table in the linked shaders may contain references to
variables that were removed (e.g., unused uniforms).  Since it may
contain junk, there is no possible valid use.  Delete it and set the
pointer to NULL.

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

glapi: regen API files for new extension

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>

mesa: Remove ARB_draw_buffers extension enable flag

All drivers in Mesa have supported this extension for eons.  This
extension is an optional features in desktop OpenGL (via
GL_ARB_draw_buffers) and OpenGL ES 2.x (via GL_NV_draw_buffers).

The extension is not usable in OpenGL ES 1.x.  There is no
glDrawBuffers* entry point in OpenGL ES 1.x contexts, and glGet*v
generate errors when MAX_DRAW_BUFFERS or DRAW_BUFFERi is queried.

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

mesa: Advertise NV_fbo_color_attachments on OpenGL ES 2.0

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

mesa: Advertise NV_draw_buffers in OpenGL ES 2.0

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

mesa/es: Allow querying GL_DRAW_BUFFERi in OpenGL ES 2.0

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

mesa/es: Allow querying GL_MAX_COLOR_ATTACHMENTS in OpenGL ES 2.0

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

mesa/es: Allow other color attachments in OpenGL ES 2.0

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

mesa/es: Make glDrawBuffersNV available in OpenGL ES 2.0

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

glapi: Add entry point for NV_draw_buffers

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

glapi: Move ARB_draw_buffers extension to a separate file

This also moves ATI_draw_buffers.  This is to facilitate enabling
NV_draw_buffers in OpenGL ES 2.0.

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

mesa/es: Remove redundant renderbuffer target validation

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

mesa/es: Validate FBO target enum in Mesa code rather than the ES wrapper

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

mesa/es: Validate FBO attachment enum in Mesa code rather than the ES wrapper

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

configure: replace pkg-config calls with $(PKG_CONFIG) in the makefiles.

Us poor souls who cross compile mesa want to be able to specify which pkg-config to pick, or at least just change one place.

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>

st/glx: Set the drawable attribute on xmesa_buffer creation.

Otherwise we'll be unable to use our pbuffers.

r300g: fix rendering with a non-zero index bias in draw_elements_immediate

NOTE: This is a candidate for the stable branches.

docs: Update references to README files

Signed-off-by: Guillem Jover <guillem@hadrons.org>
Signed-off-by: Brian Paul <brianp@vmware.com>

Remove remnants of legacy glide support

Signed-off-by: Guillem Jover <guillem@hadrons.org>
Signed-off-by: Brian Paul <brianp@vmware.com>

Ignore all shared objects

Signed-off-by: Guillem Jover <guillem@hadrons.org>
Signed-off-by: Brian Paul <brianp@vmware.com>

r600g: fix parsing TGSI declarations

It was a lucky coincidence that it worked.

nouveau: remove unused code, unused var

i915: don't include texstore.h

i965: remove unneeded includes of texstore.h

swrast: fix delayed texel buffer allocation regression

Commit 617cdcd4c7b1cffb584c829c35bdf9c9bf04627b delayed the texel
buffer allocation until texture_combine() is called.  But the
texel buffer is needed sooner in _swrast_texture_span() at line 649.

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

mesa: fix warning (MSVC error) about void pointer arithmetic

i965: Add support for GL_EXT_texture_array and GL_MESA_texture_array.

intel: Add a safety check for mapping 1D texture arrays.

So easy to screw up with the crazy way GL manages them.

intel: Add debug output to intel_map_texture_image.

intel: Add a helper function for getting miptree size from a texture image.

With 1D array textures, we no longer agree between the GL information
about width/height/depth of a texture and how we lay out a miptree.

i965: Refactor out the cube map setup for general texture array setup.

This is just moving the code out with s/6/slices/.

mesa: Reuse existing make_2d_mipmap for 2D array generation.

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

mesa: Make the uncompressed sw mipmap gen path do a Map per 1D array slice.

This also fixes what was probably a bug in 1D arrays with border.

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

mesa: When storing texture data for a 1D array, map each slice separately.

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

swrast: When asked to map a slice of a 1D array, give back that slice.

Until now, we've been treating 1D arrays as a single slice, and each
array slice is actually just a row of the 2D texture.  While swrast
still stores them this way, hardware drivers think that 1D arrays have
actual separate slices not stored as contiguous rows.

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

intel: Consolidate texture validation copy code, and reuse it correctly.

The path for ->Data was failing to be called for the FBO draw offset
fallback, and also had mismatched compressed texture support code.

This drops the intel_prepare_render() in the blit path.  We aren't
copying to/from a GL_FRONT buffer, so it doesn't matter.

intel: Clean up the function chain for mapping texture images for swrast.

Too many separate functions each called from one location (in
different files).  This code should all die soon when swrast starts
using MapTextureImage.

intel: Make PBO TexImage use AllocTextureImageBuffer like non-PBO does.

Now that whole block that also lives in AllocTextureImageBuffer can go
away.

intel: Rely on Mesa core for glTexImage storage.

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

intel: Allocate s8z24 separate renderbuffers from AllocTextureImageBuffer().

Before, we were only allocating these from our TexImage, so if the
texture image was set up in any other way (non-accelerated
glGenerateMipmaps()), they'd be missing or wrong.

intel: Add an AllocTextureImageBuffer() implementation using miptrees.

Now we can rely on Mesa core for uploads of data without introducing
an extra copy at validate time.

mesa: Convert _mesa_generate_mipmap to MapTexImage()-based access.

Now that we can zero-copy generate the mipmaps into brand new
glTexImage()-generated storage using MapTextureImage(), we no longer
need to allocate image->Data in mipmap generate.  This requires
deleting the drivers' old overrides of the miptree tracking after
calling _mesa_generate_mipmap at the same time, or the drivers
promptly lose our newly-generated data.

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

i965: Stop lowering integer division to multiply and reciprocal.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: Reverse the operands for INT DIV prior to Gen6.

Apparently on Gen4 and 5, the denominator comes first.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965/vs: Implement integer quotient and remainder math operations.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965/fs: Implement integer quotient and remainder math operations.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: Set the signed/unsigned type bit in Gen4/5 math messages.

It never mattered before since we only did floating point math.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: Fix message and response length calculations for INT DIV.

Both POW and INT DIV need a message length of 2; previously, we only
checked for POW.

Also, BRW_MATH_FUNCTION_INT_DIV_QUOTIENT_AND_REMAINDER has a response
length of 2; previously, we only checked for SINCOS.  We don't use this
message, but in case we ever decide to, we may as well fix it now.

While we're at it, just move these computations into
brw_set_math_message, since they're entirely based on the function.
This fixes it for both brw_math and the old backend's brw_math_16.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

i965: Fix assertions about register types for INT DIV in brw_math.

BRW_MATH_FUNCTION_REMAINDER was missing.  Also, it seems worthwhile to
assert that INT DIV's arguments are signed/unsigned integers.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

ir_to_mesa: Don't assertion fail on integer modulus.

Drivers implementing GLSL 1.30 want to do integer modulus, and until we
can stop generating code via ir_to_mesa, it's easier to make it silently
generate rubbish code.  Multiply will do.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

r300/compiler: Fix error in OMOD optimization

Classic compiler mistake.  In the example below, the OMOD optimization
was combining instructions 4 and 10, but since there was an instruction
(#8) in between them that wrote to the same registers as instruction 10,
instruction 11 was reading the wrong value.

Example of the mistake:

Before OMOD:
4: MAD temp[0].y, temp[3]._y__, const[0]._x__, const[0]._y__;
...
8: ADD temp[2].x, temp[1].x___, -temp[4].x___;
...
10: MUL temp[2].x, const[1].y___, temp[0].y___;
11: FRC temp[5].x, temp[2].x___;

After OMOD:
4: MAD temp[2].x / 8, temp[3]._y__, const[0]._x__, const[0]._y__;
...
8: ADD temp[2].x, temp[1].x___, -temp[4].x___;
...
11: FRC temp[5].x, temp[2].x___;

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

r300/compiler: Rewrite source swizzles when using OMOD

r300/compiler: Fix rc_normal_rewrite_writemask()

This function had not been updated to use conversion swizzles.

r300/compiler: Use consistent src swizzles for transcendent instructions

Source swizzles for transcendent instructions were being stored in the X
channel regardless of what channel the instruction was writing.
This was causing problems for some helper functions that were expecting
source swizzles to occupy channels corresponding to the instruction's
writemask.  This commit makes transcendent instructions follow the same
convention as normal instructions for representing source swizzles.

Previous behavior:
LG2 temp[0].y, input[0].x___;

Current behavior:
LG2 temp[0].y, input[0]._x__;

mesa: Respect GL_RASTERIZER_DISCARD for various meta-type operations.

From the EXT_transform_feedback spec:

    Primitives can be optionally discarded before rasterization by calling
    Enable and Disable with RASTERIZER_DISCARD_EXT. When enabled, primitives
    are discared right before the rasterization stage, but after the optional
    transform feedback stage. When disabled, primitives are passed through to
    the rasterization stage to be processed normally. RASTERIZER_DISCARD_EXT
    applies to the DrawPixels, CopyPixels, Bitmap, Clear and Accum commands as
    well.

And the GL 3.2 spec says it applies to ClearBuffer* as well.

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

mesa: Add missing glGetIntegerv() support for ARB_color_buffer_float tokens.

Fixes piglit ARB_color_buffer_float/api-get

Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>

Revert "vbo: Don't discount stride == 0 for testing all varyings in VBOs."

This reverts commit d631c19db47181129811080bfa772b210d762d4d.

The commit was broken, and ended up returning false all the time
because nobody in the world binds every single possible vertex array.
On further reflection, we don't want to discount stride == 0: This
function is just used for deciding to calculate whether to compute the
bonuds on the index, and there's no sense in computing index bounds
when stride == 0.

For the separate question of "how much data do I upload for this
vertex element?", the i965 driver was fixed to upload the data.

Fixes a regression of about 2x in 3DMMES, and most importantly, makes
Hammerfight playable.