st/mesa: set stObj->lastLevel in guess_and_alloc_texture

Fixes lockups/asserts with depthstencil-render-miplevels tests and r600g.
Should also fix https://bugs.freedesktop.org/show_bug.cgi?id=50033

NOTE: This is a candidate for the 8.0 branch.

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
intel: Fork the intel_clear.c file between i915 and i965.

This logic is wasted on i965 when we want to just always do GLSL tri
clears.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i915: Drop gen4+ code from the forked clear code.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: We always have GLSL, so always use it for tri clears.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Remove dead logic for non-tri depth/stencil clears.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Switch blit color clears to tri clears on gen4/5.

Our understanding is that the 3D engine is supposed to be faster
anyway.  We used to have more overhead in our tri clear path than we
do today, which would have led to this choice.  But given that we
almost always see a depth clear along with a color clear, the path was
hardly exercised anyway.

Also, the color mask logic was broken in the presence of
GL_EXT_draw_buffers2's per-buffer colormask.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Simplify the remaining clear logic by relying on the meta clear.

The GLSL clear path doesn't need any buffer presence checks, since
those are already handled in the normal drawing path code.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Rename the clear function for this driver.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Add an interface for doing hiz ops from C code.

This required moving gen6_hiz_op, and I put it in intel_resolve_map.h
for the next commit.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Replace intel_need_resolve with the hiz ops it maps to.

Having this enum separate caused us to need a bunch of helper
functions to translate to the op to be executed.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965: Drop a layer of indirection in doing HiZ resolves.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/gen7: Add CC viewport setup to blorp code.

When doing fast clears, a fulsim warning said that the batch was being
emitted without the viewport set up.  While the fast clear pass I was
looking at doesn't use the clear value, the later resolves which also
didn't set up the vieport would trigger the same.  It's not obvious
from the error message whether it meant "fast clear value gets clamped
to something you haven't defined" or "fast clear value doesn't get
clamped, and I saw it was out of the current (uninitialized) range,
and you probably wanted it clamped to that (uninitialized) range".  Be
paranoid and assume the first case.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
i965/gen6: Add CC viewport state setup to blorp code.

While it doesn't have the same warning in the simulator as in gen7,
let's emit it out of paranoia.  We wouldn't want our resolves of some
previous clear to get clamped to some current clamping value.

Suggested-by: pretty much everyone
i965/gen6+: Add support for fast depth clears.

Improves citybench high-res performance 3.0% +- 0.4%, n=10.  Improves
Lightsmark 1024x768 performance 0.74% +/- 0.20% (n=78).  No
significant difference on openarena (n=5, didn't fast clear) or nexuiz
(n=3).

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
mesa: Keep a computed value for dual source blend func with each buffer.

The i965 driver needed this as well for hardware setup, so instead of
duplicating the logic, just save it off.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
i965/gen6+: Add support for GL_ARB_blend_func_extended.

v2: Add support for gen6, and don't turn it on if blending is
    disabled. (fixes GPU hang), and note it in docs/GL3.txt

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Set initial values for uniforms in the linker

v2: Fix handling of arrays-of-structure.  Thanks to Eric Anholt for
pointing this out.

v3: Minor comment change based on feedback from Ken.

Fixes piglit glsl-1.20/execution/uniform-initializer/fs-structure-array
and glsl-1.20/execution/uniform-initializer/vs-structure-array.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
glsl: Initialize samplers to 0, propagate sampler values to the gl_program

The spec requires that samplers be initialized to 0.  Since this
differs from the 1-to-1 mapping of samplers to texture units assumed
by ARB assembly shaders (and the gl_program structure), be sure to
propagate this date from the gl_shader_program to the gl_program.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
CC: Vadim Girlin <vadimgirlin@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49088
glsl: Propagate sampler uniform initializers to gl_shader_program::SamplerUnits

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
ir_to_mesa: Propagate initial values in _mesa_associate_uniform_storage

The linker may have set initial values for uniforms.  Propagate these
values to the driver's backing storage when it is first associated.

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