mesa: Add a _mesa_fls() function to find the last bit set in a word.

ffs() finds the least significant bit set; _mesa_fls() finds the /most/
significant bit.

v2: Make it an inline function in imports.h, per Brian's suggestion.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
i965: Fix out-of-order sampler unit usage in ARB fragment programs.

ARB fragment programs use texture unit numbers directly, unlike GLSL
which has an extra indirection.  If a fragment program only uses one
texture assigned to GL_TEXTURE1, SamplersUsed will only contain a single
bit, which would make us only upload a single surface/sampler state
entry.  However, it needs to be the second entry.

Using _mesa_fls() instead of _mesa_bitcount() solves this.  For ARB
programs, this makes num_samplers the ID of the highest texture unit
used.  Since GLSL uses consecutive integers assigned by the linker,
_mesa_fls() should give the same result as _mesa_bitcount()..

Fixes a regression since 85e8e9e000732908b259a7e2cbc1724a1be2d447,
which caused GPU hangs in ETQW (and probably others), as well as
breaking piglit test fp-fragment-position.

v2: Add a comment, as suggested by Matt.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54098
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54179
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Tested-by: meng <mengmeng.meng@intel.com>
i965/blorp: Increase Y alignment for multisampled stencil blits.

This patch is a band-aid fix for a bug in commit 5fd67fa (i965/blorp:
Reduce alignment restrictions for stencil blits), which causes
multisampled stencil blits to work incorrectly on Sandy Bridge.

When blitting to or from a normal stencil buffer, we have to use a
coordinate transformation that swizzles coordinates to account for the
fact that stencil buffers use W tiling, but the most similar tiling
format available for textures and render targets is Y tiling.  The
differences between W and Y tiling cause pixels to be scrambled within
a block of size 8x4 (width x height) as measured relative to a W tile,
or 16x2 as measured relative to a Y tile.  So in order to make sure
that pixels at the edges of the blit aren't lost, we need to align the
rendering rectangle (and the buffer sizes) to multiples of the 8x4
block size.  This alignment happens in the brw_blorp_blit_params
constructor, whereas the determination of how to swizzle the
coordinates happens during code generation, in the
brw_blorp_blit_program class.

When blitting to or from a multisampled stencil buffer, the coordinate
swizzling is more complex, because it has to account for the
interleaving pattern of samples, which uses 4x4 blocks for 4x MSAA and
8x4 blocks for 8x MSAA.  The end result is that if multisampling is in
use, the 16x2 block size (relative so a Y tile) needs to be expanded
to 16x4, and the corresponding size relative to a W tile expands to
8x8.

The problem doesn't affect Ivy Bridge severely enough to crop up in
Piglit tests because on Ivy Bridge we have to disable multisampling
when blitting *to* a multisampled stencil buffer (the blorp compiler
generates code to compensate for the fact that multisampling is
disabled).  However I suspect a bug is still present because we don't
disable multisampling when blitting *from* a multisampled stencil
buffer.

This patch fixes the problem by doubling the vertical alignment
requirement when blitting to or from a multisampled stencil buffer,
and multisampling has not been disabled.

In the long run I would like to rework the brw_blorp_blit_params
constructor--it's difficult to follow and has had several subtle bugs
like this one.  However this band-aid fix should be suitable for
cherry-picking to release branches.

Fixes Piglit tests "unaligned-blit {2,4} stencil {msaa,upsample}" on
Sandy Bridge.

NOTE: This is a candidate for stable release branches.
i965/blorp: Fix narrowing warnings.

Blorp has to convert rectangle coordinates from integers to floats in
order to send them down the GPU pipeline.  Recent versions of GCC
issue a warning for this, since a float is not capable of precisely
representing all possible 32-bit integer values.  Suppress the warning
with an explicit type cast in the case of blorp, since rectangle
coordinates will never be large enough to cause a loss of precision.
HACK: show offsets
HACK: disable HW blitter for better testing of blorp
HACK: handle non-hiz depth/stencil formats in blorp
Experiment: disable brw_blorp_exec call in brw_blorp_blit_miptrees
Experiment: disable call to _mesa_DrawArrays in _mesa_meta_BlitFramebuffer
Revert "Experiment: disable call to _mesa_DrawArrays in _mesa_meta_BlitFramebuffer"

This reverts commit 9aead09d63e7fbec367261a78757d82796338e70.
Experiment: disable depth settings in depth blit
Re-enable color mask
Re-enable depth test
Experiment: disable depth writes
Experiment: set depth func to never
Experiment: disable computed depth
Revert "Experiment: disable computed depth"

This reverts commit 4eb99070b78b03aceed76696d60db14e16b998e6.
Disable 16-wide