intel: Keep region name in intel_miptree_create_for_dri2_buffer().

When processing a buffer received from the X server,
intel_process_dri2_buffer() examines intel_region::name to determine
whether it's received a brand new buffer, or the same buffer it
received from the X server the last time it made a request.

However, this didn't work properly, because in the call to
intel_miptree_create_for_dri2_buffer(), we create a fresh intel_region
object to represent the buffer, and this was causing us to forget the
buffer's previous name.

This patch fixes things by copying over the region name when creating
the fresh intel_region object.

At the moment, this is just a minor performance optimization.
However, when fast color clears are added, it will be necessary to
ensure that the fast color clear state for a buffer doesn't get
discarded the next time we receive that buffer from the X server.

Reviewed-by: Eric Anholt <eric@anholt.net>
intel: Conditionally compile mcs-related code for i965 only.

This patch ifdefs out intel_mipmap_tree::mcs_mt when building the i915
(pre-Gen4) driver (MCS buffers aren't supported until Gen7, so there
is no need for this field in the i915 driver).  This should make it a
bit easier to implement fast color clears without undue risk to i915.

Reviewed-by: Eric Anholt <eric@anholt.net>
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.

v2: Create a new function, intel_miptree_used_for_rendering() to
handle updating the fast color clear state when rendering occurs.

Reviewed-by: Eric Anholt <eric@anholt.net>
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.

Reviewed-by: Eric Anholt <eric@anholt.net>
i965/gen7+: Create helper functions for single-sample MCS buffers.

Reviewed-by: Eric Anholt <eric@anholt.net>
i965/gen7+: Implement fast color clear operation in BLORP.

Since we defer allocation of the MCS miptree until the time of the
fast clear operation, this patch also implements creation of the MCS
miptree.

In addition, this patch adds the field
intel_mipmap_tree::fast_clear_color_value, which holds the most recent
fast color clear value, if any. We use it to set the SURFACE_STATE's
clear color for render targets.

v2: Flag BRW_NEW_SURFACES when allocating the MCS miptree.  Generate a
perf_debug message if clearing to a color that isn't compatible with
fast color clear.  Fix "control reaches end of non-void function"
build warning.

Reviewed-by: Eric Anholt <eric@anholt.net>
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 by adding
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.

Reviewed-by: Eric Anholt <eric@anholt.net>
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.

Reviewed-by: Eric Anholt <eric@anholt.net>
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().

Reviewed-by: Eric Anholt <eric@anholt.net>
i965/gen7+: Resolve color buffers when necessary.

Resolve color buffers that have been fast-color cleared:
    1. before texturing from the buffer (brw_predraw_resolve_buffers())
    2. before using the buffer as the source in a blorp blit
       (brw_blorp_blit_miptrees())
    3. before mapping the buffer's miptree (intel_miptree_map_raw(),
       intel_texsubimage_tiled_memcpy())
    4. before accessing the buffer using the hardware blitter
       (intel_miptree_blit(), do_blit_bitmap())

v2: Rework based on the fact that we have decided not to use an
accessor function to protect access to the region.

Reviewed-by: Eric Anholt <eric@anholt.net>
i965/gen7+: Disable fast color clears on shared regions.

In certain circumstances the memory region underlying a miptree is
shared with other miptrees, or with other code outside Mesa's control.
This happens, for instance, when an extension like GL_OES_EGL_image or
GLX_EXT_texture_from_pixmap extension is used to associate a miptree
with an image existing outside of Mesa.

When this happens, we need to disable fast color clears on the miptree
in question, since there's no good synchronization mechanism to ensure
that deferred clear writes get performed by the time the buffer is
examined from the other miptree, or from outside of Mesa.

Fortunately, this should not be a performance hit for most
applications, since most applications that use these extensions use
them for importing textures into Mesa, rather than for exporting
rendered images out of Mesa.  So most of the time the miptrees
involved will never experience a clear.

v2: Rework based on the fact that we have decided not to use an
accessor function to protect access to the region.

Reviewed-by: Eric Anholt <eric@anholt.net>
i965/gen7: Enable support for fast color clears.

This patch adds code to place mcs_state into INTEL_MCS_STATE_RESOLVED
for miptrees that are capable of supporting fast color clears.  This
will have no effect on buffers that don't undergo a fast color clear;
however, for buffers that do undergo a fast color clear, an MCS
miptree will be allocated (at the time of the first fast clear), and
will be used thereafter.

Reviewed-by: Eric Anholt <eric@anholt.net>
gallivm: (trivial) remove duplicated code block (including comment)
util: new util_fill_box helper

Use new util_fill_box helper for util_clear_render_target.
(Also fix off-by-one map error.)

v2: handle non-zero z correctly in new helper

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
glsl: Add a gl_shader_program parameter to _mesa_uniform_{merge,split}_location_offset

This will be used in the next commit.

NOTE: This is a candidate for stable release branches.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-and-tested-by: Chad Versace <chad.versace@linux.intel.com>
glsl: Add gl_shader_program::UniformLocationBaseScale

This is used by _mesa_uniform_merge_location_offset and
_mesa_uniform_split_location_offset to determine how the base and offset
are packed.  Previously, this value was hard coded as (1U<<16) in those
functions via the shift and mask contained therein.  The value is still
(1U<<16), but it can be changed in the future.

The next patch dynamically generates this value.

NOTE: This is a candidate for stable release branches.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-and-tested-by: Chad Versace <chad.versace@linux.intel.com>
glsl: Generate smaller values for uniform locations

Previously we would generate uniform locations as (slot << 16) +
array_index.  We do this to handle applications that assume the location
of a[2] will be +1 from the location of a[1].  This resulted in every
uniform location being at least 0x10000.  The OpenGL 4.3 spec was
amended to require this behavior, but previous versions did not require
locations of array (or structure) members be sequential.

We've now encountered two applications that assume uniform values will
be "small."  As far as we can tell, these applications store the GLint
returned by glGetUniformLocation in a int16_t or possibly an int8_t.

THIS BEHAVIOR IS NOT GUARANTEED OR IMPLIED BY ANY VERSION OF OpenGL.

Other implementations happen to have both these behaviors (sequential
array elements and small values) since OpenGL 2.0, so let's just match
their behavior.

Fixes "3D Bowling" on Android.

NOTE: This is a candidate for stable release branches.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-and-tested-by: Chad Versace <chad.versace@linux.intel.com>
mesa: fix OES_EGL_image_external being partially allowed in the core profile

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
gallium/util: make WRITES_ALL_CBUFS optional in the passthrough fragment shader

Reviewed-by: Brian Paul <brianp@vmware.com>
gallium/u_blitter: make clearing independent of the number of bound colorbuffers

We can use the fragment shader TGSI property WRITES_ALL_CBUFS.

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