gallivm: Add and use lp_build_lerp_3d.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
gallivm: Eliminate 8.8 fixed point intermediates from AoS sampling path.

This change was meant as a stepping stone to use PMADDUBSW SSSE3
instruction, but actually this refactoring by itself yields a 10%
speedup on texture intensive shaders (e.g, Google Earth's ocean water
w/o S3TC on a Ivy Bridge machine), while giving yielding exactly the
same results, whereas PMADDUBSW only gave an extra 5%, at the expense of
2bits of precision in the interpolation.

I belive that the speedup of this change comes from the reduced register
pressure (as 8.8 fixed point intermediates take twice the space of 8bit
unorm).

Also, not dealing with 8.8 simplifies lp_bld_sample_aos.c code
substantially -- it's no longer necessary to have code duplicated for
low and high register halfs.

Note about lp_build_sample_mipmap(): the path for num_quads > 1 is never
executed (as it is faster on AVX to split the 256bit wide texture
computation into two 128bit chunks, in order to leverage integer
opcodes).  This path might be useful in the future, so in order to
verify this change did not break that path I had to apply this change:

  @@ -1662,11 +1662,11 @@ lp_build_sample_soa(struct gallivm_state *gallivm,
         /*
          * we only try 8-wide sampling with soa as it appears to
          * be a loss with aos with AVX (but it should work).
          * (It should be faster if we'd support avx2)
          */
  -      if (num_quads == 1 || !use_aos) {
  +      if (/* num_quads == 1 || ! */ use_aos) {

            if (num_quads > 1) {
               if (mip_filter == PIPE_TEX_MIPFILTER_NONE) {
                  LLVMValueRef index0 = lp_build_const_int32(gallivm, 0);
                  /*

and then run texfilt mesademo:

  LP_NATIVE_VECTOR_WIDTH=256 ./texfilt

Ran whole piglit without regressions.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
mesa: Make gl_renderbuffers backed by EGL images use FinishRenderTexture.

This is the opportunity that radeon and intel drivers rely on for flushing
render targets that may get reused as textures.  Before EGL, that only
happened for GL_TEXTURE attachments.

Fixes piglits:
KHR_gl_renderbuffer_image/renderbuffer-texture
OES_EGL_image/renderbuffer-texture

NOTE: This is a candidate for the 9.1 branch.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
radeon: Remove dead radeon_wrap_texture().

I should have killed this in my previous cleanup.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa: Track the TexImage being rendered to in the gl_renderbuffer.

We keep having to pass the attachments around with our gl_renderbuffers
because that's the only way to find what the gl_renderbuffer actually
refers to.  This is a step toward removing that (though drivers still need
the Zoffset as well).

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
mesa: Make FinishRenderTexture just take the renderbuffer being finished.

Now that the rb has a reference to the teximage, we didn't need anything
else out of the attachment.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
st/mesa: fix weird UCMP opcode use for bool ubo load

I don't know what this code was trying to do but whatever it was it couldn't
have worked since negation of integer boolean inputs while not specified as
outright illegal (not yet at least) won't do anything since it doesn't affect
the result of comparison with zero at all. In fact it looks like the whole
instruction can just be omitted.

Reviewed-by: Marek Olšák <maraeo@gmail.com>
gallivm: handle z32s8x24 format for sampling

Since we can only sample either depth or stencil but not both only load
the required bits which makes things a bit easier (it requires special
handling since the format doesn't fit into 32bit).
The logic for deciding if depth or stencil should be sampled is a bit odd,
but seems to be what other drivers and statetrackers do: if it's a format with
both depth and stencil (or just with depth) then sample depth, for sampling
stencil a sampler view format with only stencil is required.
Also while here fix up stencil sampling for other formats as well, though
this isn't supported by mesa (ARB_stencil_texturing), and while blits would
use it they don't work neither since they'd also need stencil export.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
llvmpipe: fix bogus handling of first_layer when setting up texture sampling

The code avoided first_layer parameter in the sampler interface (and needing
to do another calculation at runtime) by fixing up the base texture pointer
instead. Unfortunately, this didn't actually work as we have mip-first
texture layout so fixing up the base ptr by a fixed amount is very wrong if
there are mipmaps present. The wrong offsets caused misrendering and crashes.
Fix this by just adjusting the individual mip level offsets instead.
Spotted by Jose.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
llvmpipe: get rid of unused tiled/linear logic

We do rendering to linear color buffers for quite some time, and since
switching to linear depth buffers all the tiled/linear logic was unused.
So get rid of (most) of it - there's still some LAYOUT_NONE things and
late allocation of resources which probably could be simplified.

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
llvmpipe: handle z32s8x24 depth/stencil format

We need to split up the depth and stencil values in this case, and there's
some new logic required to handle float depth and stencil simultaneously.
Also make sure we get the 64bit zs clear values and masks propagated
correctly.
llvmpipe: enable z32s8x24 format

Now that we can handle it both for sampling and as depth/stencil enable it.
Passes nearly all additional piglit tests which are now performed, with two
exceptions (one being a framebuffer blit which fails for all other formats
including stencil too as we don't support stencil blits, the other reporting
a unexpected GL error so doesn't look to be llvmpipe's fault).
intel: Create intel_miptree_get_region() to prepare for fast color clear.

With the advent of fast color clears, it will no longer be safe for
the driver to access the data stored in a miptree with impunity.  For
example, sometimes a resolve will need to be performed first (to
ensure that deferred writes due to a fast clear are performed before
the buffer is accessed).  Other times, fast clear will need to be
disabled for the miptree, so that its contents can be safely shared
with an entity that Mesa can't synchronize with easily.

To prepare for that, this patch renames intel_mipmap_tree::region to
intel_mipmap_tree::region_private, creates an accessor function,
intel_miptree_get_region().  At the moment, the accessor function
simply returns region_private.  Later in the patch series, this
function will be expanded to take appropriate actions to maintain the
proper fast color clear state.

As much as possible, I've tried to restrict the functions which
directly access region_private to low-level miptree functions
(e.g. miptree initialization functions), so that it will be easy to
verify that those functions access the miptree contents safely.
!UPSTREAM: i965/gen7+: Create an enum for keeping track of fast color clear state.

This patch includes code to update the fast color clear state
appropriately when rendering occurs.  The state will also need to be
updated when a fast clear or a resolve operation is performed; those
state updates will be added when the fast clear and resolve operations
are added.

TODO:

- Move de-constification to previous patch.
i965/gen7+: Set up MCS in SURFACE_STATE whenever MCS is present.

On Gen7+, MCS buffers are used both for compressed multisampled color
buffers and for "fast clear" of single-sampled color buffers.

Previous to this patch series, we didn't support fast clear, so we
only used MCS with multisampled bolor buffers.

As a first step to implementing fast clears, this patch modifies the
code that sets up SURFACE_STATE so that it configures the MCS buffer
whenever it is present, regardless of whether we are multisampling or
not.
i965/gen7+: Create helper functions for single-sample MCS buffers.
i965/gen7+: Implement fast color clear operation

Add field intel_mipmap_tree::fast_clear_color_value, which holds the most
recent fast color clear value, if any. Use it to set the SURFACE_STATE's
clear color for render targets.

The fast color clear operation is implemented in blorp.

[chadv] Write commit message.
i965/blorp: Expand clear class hierarchy to prepare for RT resolves.

The fragment shaders that to do color clears will be re-used to
perform so-called "render target resolves" (the resolves associated
with fast color clears).  To prepare for that, this patch expands the
class hierarchy for blorp params: brw_blorp_clear_params (which will
be used for both fast and slow color clears) derives from
brw_blorp_const_color_params (which will be used for all blorp
operations where the fragment shader outputs a constant color).

Some other data structures and functions were also renamed to use
"const_color" nomenclature where appropriate.
i965/blorp: Write blorp code to do render target resolves.

This patch implements the "render target resolve" blorp operation.
This will be needed when a buffer that has experienced a fast color
clear is later used for a purpose other than as a render target
(texturing, glReadPixels, or swapped to the screen).  It resolves any
remaining deferred clear operation that was not taken care of during
normal rendering.

Fortunately not much work is necessary; all we need to do is scale
down the size of the rectangle primitive being emitted, run the
fragment shader with the "Render Target Resolve Enable" bit set, and
ensure that the fragment shader writes to the render target using the
"replicated color" message.  We already have a fragment shader that
does that (the shader that we use for fast color clears), so for
simplicity we re-use it.
i965/gen7+: Ensure that front/back buffers are fast-clear resolved.

We already had code in intel_downsample_for_dri2_flush() for
downsampling front and back buffers when multisampling was in use.
This patch extends that function to perform fast color clear resolves
when necessary.

To account for the additional functionality, the function is renamed
to simply intel_resolve_for_dri2_flush().