mesa: remove support for software alpha buffers

This was only used by the xlib driver to add an alpha channel to the
front/window color buffer.  This was no longer going to work well with
the move to direct mapping of renderbuffers.

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

xlib: remove xm_image.[ch] files

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

xlib: remove a ton of old xlib driver cruft

The days of 1-bpp, 8-bpp and dithering are long behind us.

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

xlib: use MESA_FORMAT_XRGB8888 for pixmap surfaces

We no longer have software-allocated alpha buffers so we can forget
about the alpha channel.

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

xlib: remove software alpha buffer support

Seldom used and this won't work when we move to using Map/UnmapRenderbuffer
everywhere.  This will let us remove a bunch of core Mesa code too.

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

mesa: replace GLstencil with GLubyte

intel: Fix intel_map_renderbuffer() for depthstencil buffers with separate stencil

For a depthstencil buffer with separate stencil,
intel_renderbuffer::region is null. (The regions are kept in hidden depth
and stencil buffers). Since the region is null, intel_map_renderbuffer()
assumed there was no data and returned a null map pointer, which in turn
was dereferenced (!) by MapRenderbuffer's caller.

This patch fixes intel_map_renderbuffer() to map the hidden depth buffer
through the GTT and return that as the mapped pointer. Also, the stencil
bits are scattered and gathered when needed.

Fixes the following Piglit tests on gen7:
    fbo/fbo-readpixels-depth-formats
    hiz/hiz-depth-read-fbo-d24s8
    hiz/hiz-stencil-read-fbo-d24s8
    EXT_packed_depth_stencil/fbo-clear-formats
    EXT_packed_depth_stencil/fbo-depth-GL_DEPTH24_STENCIL8-blit
    EXT_packed_depth_stencil/fbo-depth-GL_DEPTH24_STENCIL8-drawpixels
    EXT_packed_depth_stencil/fbo-depth-GL_DEPTH24_STENCIL8-readpixels
    EXT_packed_depth_stencil/fbo-depthstencil-GL_DEPTH24_STENCIL8-readpixels-24_8
    EXT_packed_depth_stencil/fbo-depthstencil-GL_DEPTH24_STENCIL8-readpixels-FLOAT-and-USHORT
    EXT_packed_depth_stencil/fbo-stencil-GL_DEPTH24_STENCIL8-readpixels

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

intel: Fix software detiling of system stencil buffers

If a window system stencil buffer had a region with odd height, then the
calculated y offset needed for software detiling was off by one.  The bug
existed in intel_{map,unmap}_renderbuffer_s8() and in the intel_span.c
accessors.

Fixes the following Piglit tests on gen7:
    general/depthstencil-default_fb-readpixels-24_8
    general/depthstencil-default_fb-readpixels-FLOAT-and-USHORT

Fixes SIGABRT in the following Piglit tests on gen7:
    general/depthstencil-default_fb-blit
    general/depthstencil-default_fb-copypixels
    general/depthstencil-default_fb-drawpixels-24_8
    general/depthstencil-default_fb-drawpixels-FLOAT-and-USHORT

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

intel: Fix intel_unmap_renderbuffer_s8()

When gathering the temporary buffer's pixles into the gem buffer, we had
the two buffers juxtaposed. Oops.

Fixes the following Piglit tests on gen7:
   general/GL_SELECT - alpha-test enabled
   general/GL_SELECT - depth-test enabled
   general/GL_SELECT - no test function
   general/GL_SELECT - scissor-test enabled
   general/GL_SELECT - stencil-test enabled

Fixes SIGABRT in Piglit tests EXT_framebuffer_object/fbo-stencil-* on
gen7.

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

intel: Refactor intel_map_renderbuffer()

The function already implements 3 cases (map through GTT, blit to
a temporary, and detile stencil buffer to temporary), and a 4th will be
added soon: scatter/gather for depthstencil buffers using separate
stencil.  For sanity's sake, this factors each case out into its own
function.

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

ir_to_mesa: don't init unfirom if link failed

Don't call set_unfiform_initializers if link failed, or it would trigger
a GL_INVALID_OPERATION error. That's not an expected behavior of
glLinkProgram function.

Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>

glsl: Always search for an exact function signature match.

Previously, we would fail to compile the following shader due to a bug
in lazy built-in importing:

    #version 130
    void main() {
        float f = abs(5.0);
        int i = abs(5);
    }

The first call, abs(5.0), would fail to find a local signature, look
through the built-ins, and import "float abs(float)".

The second call, abs(5), would find the newly imported float signature
in the local shader, and settle for that.  Unfortunately, it failed to
search the built-ins for the correct/exact signature, "int abs(int)".

Thus, abs(5) ended up being a float, causing a bizarre type error when
we tried to assign it to an int.

Fixes piglit test builtin-overload-matching.frag.

This is /not/ a candidate for stable branches, as it should only be
possible to trigger this bug using GLSL 1.30's built-in functions that
take integer arguments.  Plus, the changes are fairly invasive.

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

glsl: Split code to generate an ir_call out from match_function_by_name.

match_function_by_name performs two fairly separate tasks:
1. Hunt down the appropriate ir_function_signature for the callee.
2. Generate the actual ir_call (assuming we found the callee).

Both of these are complicated.  The first has to handle exact/inexact
matches, lazy importing of built-in prototypes, different scoping rules
for 1.10, 1.20+, and ES.  Not to mention printing a user-friendly error
message with pretty-printed "maybe you meant this" candidate signatures.

The second has to deal with void/non-void functions, pre-call implicit
conversions for "in" parmeters, and post-call "out" call conversions.

Trying to do both in one function is just too unwieldy.  Time to split.

This patch purely moves the code to generate an ir_call into a separate
function and reindents it.  Otherwise, the code is identical.

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

glsl: Add a new matching_signature() variant that returns exact/inexact.

When matching function signatures across multiple linked shaders, we
often want to see if the current shader has _any_ match, but also know
whether or not it was exact.  (If not, we may want to keep looking.)

This could be done via the existing mechanisms:

   sig = f->exact_matching_signature(params);
   if (sig != NULL) {
      exact = true;
   } else {
      sig = f->matching_signature(params);
      exact = false;
   }

However, this requires walking the list of function signatures twice,
which also means walking each signature's formal parameter lists twice.
This could be rather expensive.

Since matching_signature already internally knows whether a match was
exact or not, we can just return it to get that information for free.

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

r600g: fix the representation of control-flow instructions

We need something that looks like a compiler and not like some hacker
put some functions together. /rant

This is a band-aid for these two problems:
- The R600 and EG control-flow instructions appear in switch statements
  next to each other, causing conflicts when adding new instructions.
- The ALU control-flow instructions are bitshifted by 3 (from CF_INST 26:29
  to CF_INST 23:29, as is defined by r600 ISA) even for EG, where CF_INST
  is 22:29.

To fix this mess, the 'inst' field is bitshifted to the left either by 22, 23,
or 26 (directly in the definitions), such that it can be just or'd when making
bytecode without any shifting. All switch statements have been divided into
two, one for R600 and the other for EG.

Of course, there is a better way to do this, but that is left for future
work.

Tested on RV730 and REDWOOD with no regressions.

v2: minor cleanup as per Alex's comment.

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

glsl: Remove resource count checks from ir_to_mesa and st_glsl_to_tgsi

These checks are now performed by the linker.

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

linker: Validate resource usage in the linker

This is also done in ir_to_mesa and st_glsl_to_tgsi, but that code
will be removed soon.

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

linker: Count the number of uniform components used by a shader during linking

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

linker: Count the number of samplers used by a shader during linking

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

meta: Fix restoring of fixed function texture enables.

If they were disabled on entry, and we enabled one (like for
BlitFramebuffer), we wouldn't disable it on the way out.  Retain the
attempted optimization here (don't keep calling to set each bit for
changes that won't matter) by just setting the bits directly with
appropriate flushing.

Fixes misrendering on the second draw of piglit fbo-blit.

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

meta: Don't forget to flag state when restoring texobjects.

It's unlikely that we changed the object but no other texture
parameter, but be correct anyway.  Noticed by inspection.

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

st/mesa: fix system value to semantic mapping

Broken by addition of SYSTEM_VALUE_VERTEX_ID in
919c53e87a1f6f5322bc1f1486bb3e6b954b00d5.

gallium: add TGSI_SEMANTIC_VERTEXID

r600g: mask write for fake VS export components

r600g: fix op3 & write in merge_inst_groups

r600g: set max max tex/vtx instructions count to 16 for cayman

Cayman is 16 as well.

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

r600g: set max tex/vtx instructions count to 16 for evergreen

According to evergreen-isa doc 16 is max value for evergreen.
More than 16 doesn't work for me.

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>

radeon: further cleanup of shared code

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

radeon: add some missing FireMV pci ids

Note: this is a candidate for the stable branches.

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

mesa/st: Flush stdout after pritingin the GLSL.

Otherwise it gets all garbled with stderr.

glsl: Add missing ';' in action statement.

Addresses the warnings:

  warning: a `;' might be needed at the end of action code
  warning: future versions of Bison will not add the `;'

llvmpipe: Silent warnings about undeclared llvmpipe_check_render_cond.

util: Avoid signed/unsigned comparison in u_trim_pipe_prim().

llvmpipe: Remove unused variables.

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

llvmpipe: Make more resilient to out-of-memory situations.

Most of the code was alright, but we were missing a few paths.

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

draw: Handle failure to allocate aligned_constant_storage.

Also, actually update const_storage_size, therefore avoiding to
unnecessarily reallocate aligned_constant_storage every single time
draw_vs_set_constants() is called.

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

gallivm: Remove duplicate statement.

ary_ge_arx_arz is already set earlier.

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

gallivm: Include stddef.h before the LLVM C++ headers.

Necessary with build against LLVM 2.6, with recent gcc, as LLVM headers
depend on ptrdiff_t but don't properly include stddef.h

llvmpipe: fix unswizzle of packed float types.

I messed up adding the ubyte->float conversion.

This fixes getteximage-formats

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

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

r600g: properly handle cayman in is_alu_vec_unit_inst()

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

r600g: fix cb offset for flushed_depth_texture

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>

r600g: fix stencil buffer ref counting on evergreen

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>

r600g: lazy load for AR register

Emit MOVA* instruction only when AR is used.

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>

r600g: include INTERP_[XY|ZW] in is_alu_vec_unit_inst

This will disallow moving them to the trans slot in merge_inst_groups

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>

glcpp: Add GL_ARB_draw_instanced #define.

i965: Don't try to normalize cubemap coordinates for textureSize.

Although textureSize is represented as an ir_texture with op == ir_txs,
it doesn't have a coordinate, so normalizing it doesn't make sense.

Fixes crashes in oglconform glsl-bif-tex-size basic.samplerCube.* tests.

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

mesa: Fix glFramebufferTexture*() for depth and stencil attachments

This patch solves three bugs.

1. When a texture was attached to the GL_DEPTH_STENCIL_ATTACHMENT point,
Mesa attached the texture only to the depth attachment point
    gl_framebuffer::Attachment[BUFFER_DEPTH]
and failed to attach it to the stencil attachment point
    gl_framebuffer::Attachment[BUFFER_STENCIL]

2. When a texture was attached to the GL_DEPTH_ATTACHMENT point and then
later attached to the GL_STENCIL_ATTACHMENT point, Mesa created two
separate renderbuffer wrappers. This caused a GL error in
glGetFramebufferAttachmentParameteriv().

3. Same as 2, but with depth and stencil juxtaposed.

Fixes Piglit test ARB_framebuffer_object/same-attachment-glFramebufferTexture2D-GL_DEPTH_STENCIL

Note: This is a candidate for the stable branches.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>

i965: Expose GLSL 1.30 on gen6+.

With the gl_VertexID support, everything required should now be
supported.

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

i965: Add support for gl_VertexID and gl_InstanceID.

The compiler setup for these VF-uploaded attributes looks a little
cheesy with mixing system values and real VBO-sourced attributes.  It
would be nice if we could just compute the ATTR[] map to GRF index up
front and use it at visit time instead of using ir->location in the
ATTR file.  However, we don't know the reg_offset at
visit(ir_variable *) time, so we can't do the mapping that early.

Fixes piglit vertexid test.

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

i965: Replace a should-never-happen fallback with asserts where it matters.

We only allow 16 vec4s of attributes in our GLSL/ARB_vp programs, and
1 more element will get used for gl_VertexID/gl_InstanceID.  So it
should never have been possible to hit this fallback, unless there was
another bug.  If you do hit this, you're probably using gl_VertexID
and falling back to swrast won't work for you anyway.

This also updates the limits for gen6+.

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

mesa: Make gl_VertexID be a system value like gl_InstanceID.

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

glsl: Move builtin_variables.h into .cpp.

This used to be script-generated, but now it's just a bunch of static
variables in a .h file for no good reason.

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

glsl: Move ir_variable.cpp to builtin_variables.cpp.

It's only about builtins, not variables in general.

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

state_tracker: remove written but never used variable.

radeon: fix build.

I had a later patch remove this code, but cherry-picked across it.

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

radeon: drop unused constant_cliprect field

radeon: disable texobj state for 3d texture

for 3d texture fallback, disable the texobj state.

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

radeon: use meta bitmap

Now that the stride bug is fixed, enable Bitmap via meta mode.

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

radeon: fix bug with wrong stride being used for rectangluar textures.

This broke the meta bitmap code when it was enabled.

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

i965: remove #include of api_noop.h

xlib: set alpha to 0xff when mapping RGB pixmaps

Fixes a bunch of conform regressions.

swrast: avoid calling _mesa_get_srgb_format_linear() inside a loop

swrast: remove bogus assertion

It would fail for images that were never allocated (and wouldn't be
used during rendering).

svga: don't crash/assert if we fail to allocate a vertex buffer

v2: check if pipe_buffer_map() returns NULL, and return NULL from
svga_vbuf_render_map_vertices().  Per Jose's suggestion.

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

draw: handle out of memory conditions

If the vbuf backend fails to allocate a vertex buffer, don't crash
or assert.

util: check for null vertex buffer object in blit code

Don't crash if we fail to allocate a vertex buffer.

st/mesa: fix OOM failure in bitmap code

vbo: better handling of VBO allocation failures

Previously, if we failed to allocate a VBO (either for display list
compilation or immediate mode rendering) we'd eventually segfault
when trying to map the non-existant buffer or in a glVertex/Color/etc
call when we hit a null pointer.

Now we don't try to map non-existant buffers and if we do fail to
allocate a VBO we plug in no-op functions for glVertex/Color/etc
so we don't segfault.

mesa: replace api_noop.[ch] with vbo_noop.[ch]

None of the code in api_noop.c was used anymore.  The new vbo_noop.c
functions are true no-ops.  They'll be used to no-op glBegin/End functions
when we run out of VBO memory.

vbo: pull some code from api_noop.c into vbo module

Only a handful of functions from api_noop.c are actually used by
the VBO module.  Move them to the VBO module.  With this change,
none of the code in api_noop.c is actually used anymore.

mesa: remove ancient, unused gl_free_control_points prototoype

docs: add another viewperf issue

i965: Make Gen6+ renderbuffer surface updates not depend on NEW_COLOR.

NEW_COLOR is only needed on Gen4-5 as brw_update_renderbuffer_surfaces
only uses ctx->Color when intel->gen < 6.

This should reduce unnecessary state updates.

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

i965: Reorder state atom lists so all the surface state is together.

Not strictly necessary, but seems like a good idea.

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

glsl: Handle constant expressions involving ir_binop_equal/nequal.

Constant expressions which called GLSL's equal() and notEqual()
built-ins on bvecs would hit an assertion failure; we simply forgot to
implement them for booleans.

NOTE: This is a candidate for stable release branches.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>

glsl: Remove textureGradOffset built-ins taking samplerCube parameters.

These simply don't exist in the 1.30 specification---none of the Offset
variants allow samplerCube.  This must have been a cut and paste error
from textureGrad, which /does/ allow cubemaps.

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

glsl: Fix misnamed textureProjOffset prototypes in built-in profiles.

Due to a cut and paste error, these were accidentally misnamed
textureProj() rather than textureProjOffset().

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

glsl: Remove texture built-ins with 'bias' from 1.30 VS profile.

From the GLSL 1.30 spec, section 8.7 "Texture Lookup Functions":
"In all functions below, the bias parameter is optional for fragment
 shaders.  The bias parameter is not accepted in a vertex shader."

This was a cut and paste mistake.

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

i965: Put a proper sampler count in 3DSTATE_VS.

See similar code for 3DSTATE_WM.

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

i965: Upload SAMPLER_STATE pointers for the VS on Ivybridge.

See similar code in gen7_wm_state.c.

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

i965: Move and rename "wm sampler" fields to just "sampler".

brw_wm_samplers actually enables any active samplers regardless of what
pipeline stage is using them, so it doesn't make much sense for it to be
WM-specific.  So, rename it to "brw_samplers."

To properly generalize it, move sampler_count and sampler_offset from
brw_context::wm to a new brw_context::sampler that can be shared without
looking strange.

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

i965: Clean up code for VS pull constant surface creation.

Like for the WM pull constants, we can merge the former prepare/emit
stages into one tracked state atom.  Furthermore, the code that used to
handle the binding table was removed in the last commit, leaving some
rather silly looking short functions that can easily be folded in.

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

i965: Use a single binding table for all pipeline stages.

Although the hardware supports separate binding tables for each pipeline
stage, we don't see much advantage over a single shared table.

Consider the contents of the binding table:
- Textures (16)
- Draw buffers (8)
- Pull constant buffers (1 for VS, 1 for WM)

OpenGL's texture bindings are global: the same set of textures is
available to all shader targets.  So our binding table entries for
textures would be exactly the same in every table.

There are only two pull constant buffers (not many), and although draw
buffers aren't interesting to the VS, it shouldn't hurt to have them in
the table.  The hardware supports up to 254 binding table entries, and
we currently only use 26.

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

i965: Split brw_wm_surfaces state into renderbuffer and texture atoms.

First, the texturing setup code is relevant for all pipeline stages,
while renderbuffer surfaces are only used by the WM.

Secondly, renderbuffer and texture setup depends on a different set of
dirty bits.  There's no reason to walk the array of textures when
changing draw buffers, or vice-versa.

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

i965: Combine the two WM pull constant tracked state atoms.

These were only split for historical reasons: brw_wm_constants used to
be the "prepare" step, while brw_wm_constant_surface was "emit".  Now
that both happen at emit time, it makes sense to combine them.

Call the newly combined state atom "brw_wm_pull_constants" to indicate
help distinguish it from the Gen6+ atoms that handle push constants.

Finally, remove the BRW_NEW_WM_CONSTBUF dirty bit entirely now that it's
never flagged nor used.

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

i965: Rename gen6_*_constants tracked state atoms to "push_constants".

When reading the "brw_wm_constants" and "gen6_wm_constants" atoms
side-by-side, I initially failed to notice the crucial difference:
the Gen6 atoms are for Push Constants, while brw_wm_constants handles
Pull Constants.  (Gen4/5 Push Constants are handled by "brw_curbe.")

Renaming these should clarify the code and save me from constant
confusion over the fact that "gen6_wm_constants" isn't just a newer
version of "brw_wm_constants."

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

i965: Remove nr_surfaces computation from brw_update_wm_surfaces.

This code is fairly fragile, as it depends on the ordering of the
entries in the binding table, which will change soon.

Also, stop listening on the BRW_NEW_WM_CONSTBUF dirty bit as it's no
longer required.

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

i965: Use 0 for the number of binding table entries in 3DSTATE_(VS|WM).

These fields control how many entries the hardware prefetches into the
state cache, so they only impact performance, not correctness.  However,
it's not clear how to use this in a way that's beneficial.

According to the documentation, kernels "using a large number" of
entries may wish to program this to zero to avoid thrashing the cache;
it's unclear how many is too many.  Also, Ironlake's WM was missing this
feature entirely---the count had to be zero.

The dirty bit tracking to handle this complicates the surface state
and binding table setup; removing it should simplify things and make
future refactoring easier.  So just set 0 for the number of entries
rather than trying to compute and track it.

Appears to have no impact on Nexuiz and OpenArena on Sandybridge.

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

i965: Remove outdated comment about CACHE_NEW_SURF_BIND dirty bit.

The comment states that brw_update_vs_constant_surface produces a
CACHE_NEW_SURF_BIND dirty bit, but it doesn't.   In fact, that bit
no longer even exists.

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

i965: Remove BRW_NEW_NR_VS_SURFACES dirty bit from brw_vs_surfaces.

brw_vs_surfaces _produces_ the BRW_NEW_NR_VS_SURFACES dirty bit, so it
makes no sense for it to subscribe to it.

Fixes an assertion failure in many piglit tests when INTEL_DEBUG is set:
  brw_state_upload.c:484: void brw_upload_state(struct brw_context *):
  Assertion `!check_state(&examined, &generated)' failed.

One such piglit test is vs-uniform-array-mat2-col-rd.shader_test.

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

i965: Add missing CACHE_NEW_WM_PROG dirty bit to WM pull constants.

Comparing brw_upload_vs_pull_constants and brw_upload_wm_pull_constants,
it became evident that something was amiss: the VS code had both
CACHE_NEW_VS_PROG and BRW_NEW_VERTEX_PROGRAM, while the WM code was
missing the CACHE_NEW_WM_PROG flag.

Not observed to fix anything, but likely necessary.

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

i965: Use new vtable entries for surface state updating functions.

Now that we have vtable entries in place, we should use them.  This
allows us to drop the cut and pasted Gen7 brw_tracked_state atoms as
they now do exactly the same thing as their brw_wm_surface_state
counterparts.

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

i965: Add new vtable entries for surface state updating functions.

Gen7+ SURFACE_STATE is different from Gen4-6, so we need separate
per-generation functions for creating and updating it.  However, the
usage is the same, and callers just want to utilize the appropriate
functions with minimal pain.  So, put them in the vtable.

Since these take a brw_context pointer and are only used on Gen4, just
add a forward declaration.  This is the simplest (if not cleanest)
solution.  It would be nicer to have a i965-specific vtable, but that's
a refactor for another day.

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

r600g: don't set the query result to 0 after a call to get_query_result

get_query_result doesn't reset the result. Only begin_query does.

r600g: the type of OCCLUSION_PREDICATE result should be boolean

mesa: silence uninitialized var warning

radeon: silence initializer warnings

draw/llvm: silence uninitialized variable warnings

radeon: silence unused var warnings

egl: silence unused var warning