i965/blorp: Pass image formats seperately from the miptree

When a texture is wrapped in a texture view, we can't trust the format in
the miptree itself.  This patch allows us to pass the format seperately
through blorp so we can proprerly handled wrapped textures.

It's worth noting here that we can use the miptree format directly for
depth/stencil formats because they cannot be reinterpreted by a texture
view.

Signed-off-by: Jason Ekstrand <jason.ekstrand@intel.com>
CC: "10.3" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
(cherry picked from commit 7599886b26853163ef354476be70aa7fd9ae35c5)
nv50/ir/util: fix BitSet issues

BitSet::allocate() is being used with the expectation that it would
leave the bitfield untouched if its size hasn't changed, however,
the function always zeroed the last word, which led to obscure bugs
with live set computation.

This also fixes BitSet::resize(), which was broken, but luckily not
being used.

Cc: "10.2 10.3" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
(cherry picked from commit b9f9e3ce03dbd8d044a72a00e1e8856a500b5f72)
nvc0/ir: clarify recursion fix to finding first tex uses

This is a simple shader for reproducing the case mentioned:

FRAG
DCL IN[0], GENERIC[0], PERSPECTIVE
DCL OUT[0], COLOR
DCL SAMP[0]
DCL CONST[0]
DCL TEMP[0..1], LOCAL
IMM[0] FLT32 {    0.0000,    -1.0000,     1.0000,     0.0000}
  0: MOV TEMP[0].x, CONST[0].wwww
  1: MOV TEMP[1].x, CONST[0].wwww
  2: BGNLOOP
  3:   IF TEMP[0].xxxx
  4:     BRK
  5:   ENDIF
  6:   ADD TEMP[0].x, TEMP[0], IMM[0].zzzz
  7:   IF CONST[0].xxxx
  8:     TEX TEMP[1].x, CONST[0], SAMP[0], 2D
  9:   ENDIF
 10:   IF CONST[0].zzzz
 11:     MOV TEMP[1].x, CONST[0].zzzz
 12:   ENDIF
 13: ENDLOOP
 14: MOV OUT[0], TEMP[1].xxxx
 15: END

Cc: "10.2 10.3" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
(cherry picked from commit ca9ab05d45ebf407485af2daa3742b897ff99162)
i965: Adjust fast-clear resolve rect for BDW

The scale factors for the resolve rectangle change for BDW and we have
to look at brw->gen now to figure out how big it should be.

Fixes: https://bugs.freedesktop.org/attachment.cgi?id=105777
Cc: "10.3" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 2d6d3461d307636b61d0f483677aaad11d1fd42a)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83046
mesa/st: don't advertise NV_vdpau_interop if it doesn't work.

As long as we don't have a workaround for frame based
decoding in VDPAU we should not advertise NV_vdpau_interop.

v2: fix commit message, check if get_video_param is present

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: mesa-stable@lists.freedesktop.org
(cherry picked from commit 12fb74fe895fe9954df127ca0ec6e4422fffb156)
gallivm: Fix Altivec pack intrinsics for little-endian

This patch fixes use of Altivec pack intrinsics on little-endian PowerPC
systems.  Since little-endian operation only affects the load and store
instructions, the semantics of pack (and other) instructions that take
two input vectors implicitly change: the pack instructions still fill
a register placing values from the first operand into the "high" parts
of the register, and values from the second operand into the "low" parts
of the register, but since vector loads and stores perform an endian swap,
the high parts end up at high memory addresses.

To still achieve the desired effect, we have to swap the two inputs to
the pack instruction on little-endian systems.  This is done automatically
by the back-end for instructions generated by LLVM, but needs to be done
manually when emitting intrisincs (which still result in that instruction
being emitted directly).

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Signed-off-by: Maarten Lankhorst <dev@mblankhorst.nl>
(cherry picked from commit 0feb977bbfb0d6bb2c8d3178246acb035a739f37)
Nominated-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>