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.

i965: Make sure to upload the data for a collection of Stride == 0 arrays.

Commit d631c19db47181129811080bfa772b210d762d4d avoided this problem
by forcing the driver to get the min/max index, but that commit was
broken, so just fix the driver problem (confusion between "do I need
to upload any data?" and "do I need the index bounds in order to
upload any data?").

mesa: Delay s_texcombine.c memory allocation until it's used.

Generally we're using fragment programs in all our drivers, so wasting
4MB for code that's never called is pretty lame.  Reduces i965 memory
allocation for a short shader program from 21,932,128B to 17,737,816B.

tnl: Delay results allocation until we actually need them.

Decreases i965 peak memory allocation for a trivial shader program
from 23,483,048B to 21,932,128B, since we never actually use tnl for
rendering.

i965/vs: Fix swizzle related assertion

As innocuous as it seemed, ebca47a basically broke the world (e.g.,
>200 piglit regressions).  In vec4_visitor::emit_block_move,
src->swizzle was expected to be BRW_SWIZZLE_NOOP before setting it to
a swizzle that would replicate the existing channels of the source
type to a vec4 (e.g., .xyyy for a vec2).

The original assertion seems to have been a little bogus.  In addition
to being BRW_SWIZZLE_NOOP, src->swizzle might already be a swizzle
that would replicate the existing channels of the source type to a
vec4.  In other words, it might already have the value that we're
about to assign to it.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

mesa: number of combiner terms to pop depends on GL_NV_texture_env_combine4

If GL_NV_texture_env_combine4 is not supported, setting the fourth
combiner term would generate a GL error.
Of course, I noticed this right after committing the previous patch
to use a loop in the first place.  <sigh>

Note that GL_EXT_texture_env_combine is always supported so the first
three combiner terms are always accepted.

mesa: s/INLINE/inline/

INLINE is still seen in some files (some generated files, etc) but this
is a good start.

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

r600: include version.h for _mesa_override_glsl_version() prototype

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

mesa: use !! to simplify some _mesa_set_enable() calls in attrib.c

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

mesa: use loop in pop_texture_group() to restore 4 combiner terms

There's four combiner terms (not 3) with GL_NV_texture_env_combine4.
Use a loop to make the code a little more compact.

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

mesa: Refactor hash_table_{find,remove} to share some code

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

mesa: Document an odd side-effect of hash_table_insert

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

mesa: Remove unused field gl_program::Varying

Lots of things set and copy this field around, but nothing uses it.

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

mesa: Use Add linker_error instead of fail_link

See also 8aadd89.

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

r600g: fix a compiler warning

gallium/docs: update the documentation of capabilities

Still like 13 caps are undocumented.

r600g: move all files from winsys/r600 into drivers/r600

Be sure to reconfigure after this commit.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

winsys/radeon: move GEM domains out of the drivers into winsys

The drivers don't need to care about the domains. All they need to set
are the bind and usage flags. This simplifies the winsys too.

This also fixes on r600g:
- fbo-depth-GL_DEPTH_COMPONENT32F-copypixels
- fbo-depth-GL_DEPTH_COMPONENT16-copypixels
- fbo-depth-GL_DEPTH_COMPONENT24-copypixels
- fbo-depth-GL_DEPTH_COMPONENT32-copypixels
- fbo-depth-GL_DEPTH24_STENCIL8-copypixels
I can't explain it.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

winsys/radeon: remove a redundant parameter 'size' from buffer_from_handle

It's part of pb_buffer already.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

r600g: remove struct radeon (or what's left of it)

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

r600g: move family and chip_class from struct radeon to r600_screen

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

r600g: merge r600_bo with r600_resource

I have moved 'last_flush' and 'binding' from r600_bo to winsys/radeon.
The other members are now part of r600_resource.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

gallium: add PIPE_CAP_TEXTURE_BARRIER

Same issue as with conditional_render.

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

gallium: add PIPE_CAP_CONDITIONAL_RENDER

We were checking whether render_condition is set. That was not reliable,
because it's always set with trace and noop regardless of driver support.

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

gallium: add and use PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS

This removes:
- PIPE_CAP_MAX_TEXTURE_IMAGE_UNITS
- PIPE_CAP_MAX_VERTEX_TEXTURE_UNITS
in favor of the that new per-shader cap.

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

gallium: remove PIPE_CAP_TEXTURE_MIRROR_REPEAT

All drivers support it (well, except Cell). The boolean option is going away
from core Mesa too.

This is a follow-up to Ian Romanick's patch
"mesa: Remove ARB_texture_mirrored_repeat extension enable flag".

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

i915: out-of-bounds write in calc_live_regs()

From a Coverity defect report.

src/mesa/drivers/dri/i915/i915_fragprog.c
   301  /*
   302   * TODO: consider moving this into core
   303   */
   304  static bool calc_live_regs( struct i915_fragment_program *p )
   305  {
   306      const struct gl_fragment_program *program = &p->FragProg;
   307      GLuint regsUsed = 0xffff0000;
-> 308      uint8_t live_components[16] = { 0, };
   309      GLint i;
   310
   311      for (i = program->Base.NumInstructions - 1; i >= 0; i--) {
   312          struct prog_instruction *inst =
&program->Base.Instructions[i];
   313          int opArgs = _mesa_num_inst_src_regs(inst->Opcode);
   314          int a;
   315
   316          /* Register is written to: unmark as live for this and
preceeding ops */
   317          if (inst->DstReg.File == PROGRAM_TEMPORARY) {
-> 318              if (inst->DstReg.Index > 16)
   319                 return false;
   320
-> 321              live_components[inst->DstReg.Index] &= ~inst->DstReg.WriteMask;
   322              if (live_components[inst->DstReg.Index] == 0)
   323                  regsUsed &= ~(1 << inst->DstReg.Index);
   324          }
   325
   326          for (a = 0; a < opArgs; a++) {
   327              /* Register is read from: mark as live for this and preceeding ops */
   328              if (inst->SrcReg[a].File == PROGRAM_TEMPORARY) {
   329                  unsigned c;
   330
   331                  if (inst->SrcReg[a].Index > 16)
   332                     return false;
   333
   334                  regsUsed |= 1 << inst->SrcReg[a].Index;
   335
   336                  for (c = 0; c < 4; c++) {
   337                      const unsigned field = GET_SWZ(inst->SrcReg[a].Swizzle, c);
   338
   339                      if (field <= SWIZZLE_W)
   340                          live_components[inst->SrcReg[a].Index] |= (1U << field);
   341                  }
   342              }
   343          }
   344
   345          p->usedRegs[i] = regsUsed;
   346      }

Reported-by: Vinson Lee <vlee@vmware.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40022
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

i965: Assign instead of compare inside assert

This is from a Coverity defect report.

src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp
  1314  void
  1315  vec4_visitor::emit_block_move(dst_reg *dst, src_reg *src,
  1316                                const struct glsl_type *type, bool
predicated)
...
  1351     /* Do we need to worry about swizzling a swizzle? */
->1352     assert(src->swizzle = BRW_SWIZZLE_NOOP);
  1353     src->swizzle = swizzle_for_size(type->vector_elements);

Reported-by: Vinson Lee <vlee@vmware.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40158
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

i965/gen6: Fix assign instead of compare in assert

This is from a Coverity defect report.

src/mesa/drivers/dri/i965/brw_vec4_emit.cpp
   268  static void
   269  check_gen6_math_src_arg(struct brw_reg src)
   270  {
   271     /* Source swizzles are ignored. */
   272     assert(!src.abs);
   273     assert(!src.negate);
-> 274     assert(src.dw1.bits.swizzle = BRW_SWIZZLE_XYZW);
   275  }

Reported-by: Vinson Lee <vlee@vmware.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40214
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

glcpp: Add a test for #elif with an undefined macro.

As written, this test correctly raises an error for #elif being used
with an undefined macro (and not as an argument to "defined"). If the
preceding #if were '#if 1' then this diagnositc would correctly be
hidden. That allows code such as the following to not raise an error:

#ifndef MAYBE_UNDEFINED
#elif MAYBE_UNDEFINED < 5
...
#endif

So this test case is working as expected already. We add it here just
to improve test coverage.

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

glcpp: Raise error if defining any macro containing two consecutive underscores

The specification reserves any macro name containing two consecutive
underscores, (anywhere within the name). Previously, we only raised
this error for macro names that started with two underscores.

Fix the implementation to check for two underscores anywhere, and also
update the corresponding 086-reserved-macro-names test.

This also fixes the following two piglit tests:

spec/glsl-1.30/preprocessor/reserved/double-underscore-02.frag
spec/glsl-1.30/preprocessor/reserved/double-underscore-03.frag

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

glcpp: Implement token pasting for non-function-like macros

This is as simple as abstracting one existing block of code into a
function call and then adding a single call to that function for the
case of a non-function-like macro.

This fixes the recently-added 097-paste-with-non-function-macro test
as well as the following piglit tests:

spec/glsl-1.30/preprocessor/concat/concat-01.frag
spec/glsl-1.30/preprocessor/concat/concat-02.frag

Also, the concat-04.frag test now passes for the right reason. The
test is intended to fail the compilation, but before this commit it
was failing compilation (and hence passing the test) for the wrong
reason.

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

glcpp: Test a non-function-like macro using the token paste operator

Apparently we never implemented this, (but we've got a GLSL 1.30 test
in piglit that is exercising this case).

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

glcpp: Fix two (or more) successive applications of token pasting

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>