mesa/vbo: Fix scaling issue in 10-bit signed normalized packing.

For the 10-bit components, the divisor was incorrect.  A 10-bit signed
integer can represent -2^9 through 2^9 - 1, which leads to the following
ranges:

       (float)value.x          -> [ -512,  511]
2.0F * (float)value.x          -> [-1024, 1022]
2.0F * (float)value.x + 1.0F   -> [-1023, 1023]

So dividing by 511 would incorrectly scale it to approximately:
[-2.001956947, 2.001956947].  To correctly scale to [-1.0, 1.0], we need
to divide by 1023.

This correctly implements the desktop GL rules.  ES 3.0 has different
rules, but those will be implemented in a separate patch.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Marek Olšák <maraeo@gmail.com>
mesa/vbo: Fix scaling issue in 2-bit signed normalized packing.

Since a signed 2-bit integer can only represent -1, 0, or 1, it is
tempting to simply to convert it directly to a float.  This maps it
onto the correct range of [-1.0, 1.0].  However, it gives different
values compared to the usual equation:

(2.0 *  1.0 + 1.0) * (1.0 / 3.0) = +1.0           (same)
(2.0 *  0.0 + 1.0) * (1.0 / 3.0) = +0.33333333... (different)
(2.0 * -1.0 + 1.0) * (1.0 / 3.0) = -0.33333333... (different)

According to the GL_ARB_vertex_type_2_10_10_10_rev extension, signed
normalization is performed using equation 2.2 from the GL 3.2
specification, which is:

   f = (2c + 1)/(2^b - 1).                                (2.2)

Comments below that equation state: "In general, this representation is
used for signed normalized fixed-point parameters in GL commands, such
as vertex attribute values."  Which is what we're doing here.

The 3.2 specification goes on to declare an alternate formula:

   f = max{c/(2^(b-1) - 1), -1.0}                         (2.3)

which is closer to the existing code, and maps the end points to exactly
-1.0 and 1.0.  Comments below the equation state: "In general, this
representation is used for signed normalized fixed-point texture or
framebuffer values."  Which is *not* what we're doing here.

It then states: "Everywhere that signed normalized fixed-point
values are converted, the equation used is specified."  This is the real
clincher: the extension explicitly specifies that we must use equation
2.2, not 2.3.  So we need to do (2x + 1) / 3.

This matches the behavior expected by oglconform's packed-vertex test,
and is correct for desktop GL (pre-4.2).  It's not correct for ES 3.0,
but a future patch will correct that.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Marek Olšák <maraeo@gmail.com>
scons: Append x11 library path if linking x11 library.

Signed-off-by: Vinson Lee <vlee@freedesktop.org>
r600g: fix ARB_map_buffer_alignment with unaligned offsets and staging buffers
r600g: fix broken streamout if streamout_begin caused a context flush

This fixes graphics corruption in the case where the DISCARD_RANGE flag
is used to map a buffer.

NOTE: This is a candidate for the stable branches.
i965/gen4: Fix LOD bias texturing since my fixed reg classes change.

We have a special case where non-shadow comparison with LOD requires using a
SIMD16 vec4 in an 8-wide shader, which appears in the register allocator as a
size 8 vgrf.

Fixes assertions in various piglit tests and webgl conformance.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56521
i965/gen4: Fix memory leak each time compile_gs_prog() is called.

Commit 774fb90db3e83d5e7326b7a72e05ce805c306b24 introduced a ralloc context to
each user of struct brw_compile, but for this one a NULL context was used,
causing the later ralloc_free(mem_ctx) to not do anything.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55175
NOTE: This is a candidate for the stable branches.
i965: Fix hangs with FP KIL instructions pre-gen6.

We can't support IF statements in 16-wide on these.  To get back to 16-wide
for these shaders, we need to support predicate on discard instructions in the
backend IR, which is something we've sort of got on the list to do anyway.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55828
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
build: use git ls-files for adding all Makefile.in into the release tarball

Until we have proper 'make dist' this is an improvement of the current
situation, because each time some old Makefiles got converted to automake
we had to update the tarballs target.

NOTE: This is a candidate for the 9.0 branch.

Cc: Eric Anholt <eric@anholt.net>
Acked-by: Matt Turner <mattst88@gmail.com>
mesa: Use correct glGetTransformFeedbackVarying name in error msg

Reviewed-by: Brian Paul <brianp@vmware.com>
i965/vs: add support for emitting SHL, SHR, ASR

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: implement get_size for 2_10_10_10 formats

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: support 2_10_10_10 formats in get_surface_type.

Always use R10G10B10A2_UINT; Most of the other formats we'd like
don't actually work on the hardware. Will emit w/a for scaling,
sign recovery and BGRA swizzle in the VS.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Generalize GL_FIXED VS w/a support

Next few patches build on this to add other workarounds
for packed formats.

V2: rename BRW_ATTRIB_WA_COMPONENTS to BRW_ATTRIB_WA_COMPONENT_MASK;
V3 (Kayden): remove separate bit for ES3 signed normalization

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: set attribute w/a bits for packed formats

Flag the need for various workarounds to be applied by
the vertex shader.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: emit w/a for packed attribute formats in VS

Implements BGRA swizzle, sign recovery, and normalization
as required by ARB_vertex_type_10_10_10_2_rev.

V2: Ported to the new VS backend, since that's all that's left;
	fixed normalization.

V3: Moved fixups out of the GLSL-only path, so it works for FF/VP too.

V4 (Kayden): Rework ES3 normalization, don't heap allocate registers;
	tidy comments.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
i965: Enable ARB_vertex_type_2_10_10_10_rev on Gen4+.

v2 (Kayden): Move the enable into an existing intel->gen >= 4 block
(as suggested by Ian).

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
gallivm,llvmpipe: handle TXF (texelFetch) instruction, including offsets

This also adds some code to handle per-quad lods for more than 4-wide fetches,
because otherwise I'd have to integrate the texelFetch function into
the splitting stuff... (but it is not used yet outside texelFetch).
passes piglit fs-texelFetch-2D, fails fs-texelFetchOffset-2D due to I believe
a test error (results are undefined for out-of-bounds fetches, we return
whatever is at offset 0, whereas the test expects [0,0,0,1]).
Texel offsets are only handled by texelFetch for now, though the interface
can handle it for everything.

Reviewed-by: José Fonseca <jfonseca@vmware.com>
gallivm: use the new mip per quad handling in texture fetch path

No longer have to split fetching into quads dynamically if mip levels
are not the same for all quads (aos sampling still always splits due
to performance reasons).
Instead handle multiple mip levels further down, minification etc. takes
this into account.

Reviewed-by: José Fonseca <jfonseca@vmware.com>
i965/fs: Remove brw_wm_compile::computes_depth field.

Everybody determines this by checking if fp's OutputsWritten field
contains the FRAG_RESULT_DEPTH bit.  Rather than having payload setup
check this and set the computes_depth flag, we can just do the check in
the only place that actually used it: emit_fb_writes().

Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Paul Berry <stereotype441@gmail.com>