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>

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

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

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>

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>

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

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>

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

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

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

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

for 3d texture fallback, disable the texobj state.

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

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

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

This broke the meta bitmap code when it was enabled.

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

Fixes a bunch of conform regressions.

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

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>

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

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

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.

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.

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.

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>

Not strictly necessary, but seems like a good idea.

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

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>

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>

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>

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>

See similar code for 3DSTATE_WM.

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

See similar code in gen7_wm_state.c.

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

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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