draw: Fix vsplit regression when the ib can be used directly.

`ib` no longer is offseted by `istart`.

Trivial.
draw: More defensive coding in DRAW_GET_IDX.

Doesn't make a difference ATM, but just in case.
i965: Use the new XRGB UNORM formats.

This is a step on the way to removing some of our code for forcing alpha
to 1, but I want easy bisecting so I'll add groups of formats separately.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Use the Mesa surface formats for float RGB surfaces.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
intel: Add support for blitting 6 byte-per-pixel formats.

The next commit introduces what is apparently our first one, which tripped
over this in glReadPixels.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Use native RGB_FLOAT16 support when available.

Previously we would expand it to RGBA_FLOAT16.  This format now comes out
as framebuffer incomplete, but it seems worth the memory savings if that's
what people are asking for (and GL3 does list it under "texture-only"
color formats)

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Fill in brw_format_for_mesa_format for some non-rendering formats.

This should have no change on driver operation, but it means that when you
wonder why some format isn't supported natively, you can just look at the
table above, instead of wondering if maybe there's an appropriate entry in
the surface formats table that is already supported.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
r600g: rewrite FMASK allocation, fix FMASK texturing with 2 and 4 samples

This fixes and enables texturing with compressed MSAA colorbuffers
on Evergreen and Cayman. For the first time, multisample textures work
on Cayman.

This requires the libdrm flag RADEON_SURF_FMASK.

v2: require libdrm_radeon 2.4.45

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
r600g: cleanup MSAA texture support checking

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
st/mesa: handle texture_from_pixmap and other surface-based textures correctly

There were 2 issues with it:
1) The texture format which should be used for texturing was only set
   in gl_texture_image::TexFormat, which wasn't used for sampler views.
2) Textures are sometimes reallocated under some circumstances
   in st_finalize_texture, which is unacceptable if the texture comes
   from a window system.

The issues are resolved as follows:
1) If surface_based is true (texture_from_pixmap, etc.), store the format
   in a new variable st_texture_object::surface_format.
2) Don't reallocate a surface-based texture in st_finalize_texture.

Also don't use st_ChooseTextureFormat is st_context_teximage, because
the format is dictated by the caller.

This fixes the glx-tfp piglit test.

Reviewed-by: Adam Jackson <ajax@redhat.com>
winsys/intel: test for and expose address swizzling

Without knowing whether addresses are swizzled or not, we cannot manipulate a
tiled surface in CPU.
ilo: add support for stencil resources on GEN7+

For allocations, we need to support stencil-only and separate stencil
resources.  For mapping, we need to support software tiling and
packing/unpacking for separate stencil resources.
ilo: emit 3DSTATE_STENCIL_BUFFER on GEN7+

Whether HiZ is enalbed or not, separate stencil is supported and enforced on
GEN7+.  Now that we support separate stencil resources, we know how to emit
3DSTATE_STENCIL_BUFFER.
gallivm: Support pointers in lp_build_print_value().

Trivial.
llvmpipe: Temporary workaround to prevent segfault on array textures.
r600g: fixup for MSAA texture support checking

Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de>
intel: Do a depth resolve before copying images between miptrees.

When intel_finalize_mipmap_tree() calls intel_miptree_copy_teximage()
to reassemble a depth miptree that has been broken apart into pieces
(to deal with misalignment of levels/layers within the miptree), it
just copies the depth data, not the HiZ data.  This is reasonable,
since the alignment restrictions of HiZ are a large part of the reason
why the miptree had to be broken apart in the first place.  However,
in order for the depth copy to be sufficient, we need to do a depth
resolve first, to make sure any deferred depth writes that are in the
HiZ buffer get performed.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=64662 and
https://bugs.freedesktop.org/show_bug.cgi?id=64659.

NOTE: This is a candidate for stable release branches.

Reviewed-by: Chad Versace <chad.versace@linux.intel.com>
intel: Don't spam "intelReadPixels: fallback to swrast" in non-PBO case.

When an application is using PBOs, we attempt to use the BLT engine to
perform ReadPixels.  If that fails due to some restrictions, it's useful
to raise a performance warning.

In the non-PBO case, we always use a CPU mapping since getting the data
into client memory requires a CPU-side copy.  This is a very common case,
so raising a performance warning is annoying.  In particular, apitrace's
image dumping code hits this path, causing it to print hundreds of
thousands of performance warnings via ARB_debug_output.  This tends to
obscure actual errors or other important messages.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
radeon/llvm: Run standard optimization passes on conpute shader modules

The SROA and function inliner passes are espically important, because
they optimize away unsupported features: functions and indirect
private memory access.
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.