nv30: U8_USCALED only works for size 4

See https://bugs.freedesktop.org/show_bug.cgi?id=61635 for a sample
program. Changing it to use a vec4 makes it work. Remove the unsupported
formats.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "9.2 and 9.1" <mesa-stable@lists.freedesktop.org>
nouveau: fix number of surfaces in video buffer, use defines

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nouveau: set buffer format of video buffer

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nv30: hook up PMPEG support via nouveau_video, enables XvMC to work

Force the format to be the reasonable format that doesn't require an
inverse z-scan.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nv50: allow forcing PMPEG use, for ease of testing

This also allows people who don't want to install the binary blobs
required for VP2 to still get MPEG decoding.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nvc0: refactor video buffer management logic into nouveau_vp3

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nvc0: standardize on using #if for NVC0_DEBUG_FENCE

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nvc0: move nvc0_decoder into nouveau, rename to nouveau_vp3_decoder

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nvc0: move bsp param-filling logic into nouveau

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nvc0: move vp param filling logic into nouveau

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nvc0: move some of the simpler decoder functions into nouveau

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nvc0: move firmware loading functions to nouveau

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
nvc0: move video param and format support functions to nouveau

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
st/mesa: use new float comparison opcodes if native integers are supported

Should get rid of some float-to-int conversions (with negation).
No piglit regressions (with llvmpipe).

v2: fix bogus formatting spotted by Brian.

Reviewed-by: Brian Paul <brianp@vmware.com>
llvmpipe: fix stencil bug if we have both stencil and depth tests

This is a very well hidden bug found by accident (only the fixed glean
tstencil2 test so far seems to hit it).
We must use new mask with combined s_pass values and orig_mask values
for zpass/zfail stencil ops, otherwise both the sfail op and one of
zpass/zfail op are applied (probably not hit in most tests because
some of the ops tend to be KEEP usually).

Note: this is a candidate for the 9.2 branch.

Reviewed-by: Zack Rusin <zackr@vmware.com>
radeonsi: Don't leave gaps between position exports from vertex shader

If the vertex shader exports clip distances but not point size, use
position exports 1/2 instead of 2/3 for the clip distances. Fixes
geometry corruption in that case.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66974

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
radeonsi: Don't export unused clip distance vectors from vertex shader

E.g. the Source engine seems to always write to gl_ClipVertex, but normally
doesn't enable any GL_CLIP_DISTANCEn states. This change removes some
irrelevant parts from the generated vertex shader code in such cases.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
radeonsi: TGSI_SEMANTIC_CLIPVERTEX doesn't use any parameters
radeonsi: Pixel shaders pre-load one more SGPR

Acked-by: Marek Olšák <maraeo@gmail.com>
gallivm: do per-sample depth comparison instead of doing it post-filter

Doing the comparisons pre-filter is highly recommended by OpenGL (and d3d9)
and definitely required by d3d10.
This actually doesn't do it pre-filter but more "in-filter" as otherwise
need to push the comparisons even further down into fetch code and this
also trivially allows using a somewhat cheaper lerp.
Doing it pre-filter would actually have some performance advantage for UNORM
formats (because the comparisons should be done in texture format, we'd only
need to convert the shadow ref coord to texture format once, but in turn would
save converting the per-sample texture values to floats) but this gets a bit
messy as this has implications for border color handling as well (which needs
to be done prior to depth comparisons, hence would also need to convert border
color to texture format too or use some other tricks like doing separate border
color / shadow ref comparison and simply using that result directly when doing
border replacement).
Should make no difference for nearest filtering, and performance for linear
filtering should be mostly the same too (essentially have one more comparison
instruction per sample, and replace the sub/mul/add lerp with a sub/and/and/add
special "lerp" which all in all shouldn't be much of a difference).

v2: get rid of old code completely

Reviewed-by: Zack Rusin <zackr@vmware.com>