gallium/docs: clarify definition of PIPE_CAP_USER_CONSTANT_BUFFERS, etc

The cap means _can_ accept user-space constant buffers; it doesn't
mean _only_ accepts user-space constant buffers.

v2: also update the PIPE_CAP_USER_VERTEX_BUFFERS and
PIPE_CAP_USER_INDEX_BUFFERS descriptions as well.  Per Jose.

Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
softpipe: don't ignore pipe_constant_buffer::buffer_offset

This was never a problem since the Mesa state tracker always gives
us a user-space constant buffer with buffer_offset=0.  But if another
state tracker ever gave us a "HW" constant buffer with non-zero
buffer_offset we'd mis-render.

Also, use the correct buffer size.  And move an assertion to the
top of the function.

Reviewed-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
softpipe: use new softpipe_resource_data() accessor

We should probably be using map()/unmap() when accessing resource
data, but this is a little better.

v2: assert that the resource is not a display target, per Jose.

Reviewed-by: José Fonseca <jfonseca@vmware.com>
gallium/util: comments, var renaming in u_inlines.h

The variable 'usage' was being used for two different things.
Sometimes for PIPE_USAGE_x and other times for PIPE_TRANSFER_x.
This renames usage to access when we're talking about PIPE_TRANSFER_x
flags.  Plus, add a bunch of comments to remind us what's going on.

Also, use unsigned for PIPE_TRANSFER_x bitmask to be consistent with
other places.  And add a missing const qualifier.

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
gallium/util: reformat, comment util_get_offset()

Reviewed-by: Roland Scheidegger <sroland@vmware.com>
mesa: improve free() cleanup in generate_mipmap_compressed()

Free all our temporary buffers in one place at the end of the
function.  Fixes memory leak detected by Coverity.

Note: This is a candidate for the 9.x branches
Cc: mesa-stable@lists.freedesktop.org

Reviewed-by: José Fonseca <jfonseca@vmware.com>
mesa: fix number of mipmaps calculation for proxy textures

The function _mesa_get_tex_max_num_levels() is supposed to calculate
the number of mipmap levels but it was not written to handle proxy
textures, at best returning a maximum of 1 mipmap level. Because of
this, at least glTexStorage*() calls would incorrectly fail when used
with proxy textures with more than one mipmap level.

Reviewed-by: Brian Paul <brianp@vmware.com>

Cc: mesa-stable@lists.freedesktop.org
mesa: fix proxy textures not working with default texture binding

When working with the glTexStorage*() functions, the error checking
checks that a non-default (i.e., non-zero) texture is currently bound.
However, this check made glTexStorage*() functions fail with proxy
textures when the default texture is bound. Proxy textures do not care
about the current texture bindings so for them this check should not
be done.

Reviewed-by: Brian Paul <brianp@vmware.com>

Cc: mesa-stable@lists.freedesktop.org
mesa: fix proxy textures becoming immutable and unusable

glTexStorage*() functions make textures immutable.  This carries on to
proxy textures.  Error checking in texture storage functions prevents
proxy textures from working after first time because internally, they
became immutable.

This commit makes the error checking ignore the immutability flag when
working with proxy textures.

Reviewed-by: Brian Paul <brianp@vmware.com>

Cc: mesa-stable@lists.freedesktop.org
mesa: fix multisampling proxy textures not being queryable

The code that checks if some texture target is valid for
glGetTexLevelParameter*() was not programmed to check for multisampling
proxy textures.  This made it impossible(?) to use the proxy textures
for their intended purpose as glGetTexLevelParameter*() would just fail
on you.

Reviewed-by: Brian Paul <brianp@vmware.com>

Cc: mesa-stable@lists.freedesktop.org
gallivm: use nearest rounding for float->unorm24 conversion

Previously we were using truncation, which gives the correct result
only for numbers in [0.5-1.0] range (because there's no mantissa bits
to do any rounding there).
This is frequently hit (and probably only used there) when converting
fragment depth to depth format (d24s8 etc.) or otherwise dealing with
depth format.

v2: as spotted by Jose, get rid of extra type (src_type is already unsigned).

Reviewed-by: Jose Fonseca <jfonseca@vmware.com>
egl: Restore "bogus" DRI2 invalidate event code.

I had removed it in commit 1e7776ca2bc59a6978d9b933d23852d47078dfa8
because it was obviously wrong -- why do we care whether the server is a
version that emits events, if we're not watching for the server's events,
anyway?  And why would you only invalidate on a server that emits
invalidate events, when the comment said to emit invalidates if the server
*doesn't*?  Only, I missed that we otherwise don't flag that our buffers
might have changed at swap time at all, so the driver was only checking
for new buffers when triggered by the Viewport hack.  Of course you don't
expect Viewport to be called after a swap.

So, this is effectively a revert of the previous commit, except that I
dropped the check for only emitting invalidates on a new server -- we
*always* need to invalidate if we're doing a SwapBuffers.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63435
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "9.1 and 9.2" <mesa-stable@lists.freedesktop.org>
glsl: Change the lexer's namespace.

Bison 3.0 removes the YYLEX_PARAM macro.  In preparation for handling
this using %lex-param, the parser needs a wrapper function for the
actual Flex lex() function.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67354
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Tested-by: Laurent Carlier <lordheavym@gmail.com>
Cc: "9.2" mesa-stable@lists.freedesktop.org
glsl: Switch from the deprecated YYLEX_PARAM to %lex-param.

YYLEX_PARAM is no longer supported as of Bison 3.0.  Instead, the Bison
developers recommend using %lex-param.

%lex-param takes a type and variable name, similar to %parse-param,
so you can't pass an arbitrary expression like state->scanner.  But Flex
insists on passing the actual scanner object, not an arbitrary object
like state.

To solve this, the parser defines a wrapper lex() function which accepts
"state," and calls Flex's lex() function with state->scanner.

Fixes the build with Bison 3.0.  Also works with Bison 2.7.1.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67354
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Tested-by: Laurent Carlier <lordheavym@gmail.com>
Cc: "9.2" mesa-stable@lists.freedesktop.org
mesa/program: Change the program parser's namespace.

Bison 3.0 removes the YYLEX_PARAM macro.  In preparation for handling
this using %lex-param, the parser needs a wrapper function for the
actual Flex lex() function.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67354
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Tested-by: Laurent Carlier <lordheavym@gmail.com>
Cc: "9.2" mesa-stable@lists.freedesktop.org
mesa/program: Switch from the deprecated YYLEX_PARAM to %lex-param.

YYLEX_PARAM is no longer supported as of Bison 3.0.  Instead, the Bison
developers recommend using %lex-param.

%lex-param takes a type and variable name, similar to %parse-param,
so you can't pass an arbitrary expression like state->scanner.  But Flex
insists on passing the actual scanner object, not an arbitrary object
like state.

To solve this, the parser defines a wrapper lex() function which accepts
"state," and calls Flex's lex() function with state->scanner.

Fixes the build with Bison 3.0.  Also works with Bison 2.7.1.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67354
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Tested-by: Laurent Carlier <lordheavym@gmail.com>
Cc: "9.2" mesa-stable@lists.freedesktop.org
mesa/program: remove useless YYID

This fixes the build with Bison 3.0. Also works with Bison 2.7.1.

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
nvc0: properly align NVE4_COMPUTE_MP_TEMP_SIZE

MP_TEMP_SIZE must be aligned to 0x8000, while TEMP_SIZE on NVE4_3D
must be aligned to 0x20000, so perform both alignments to be sure
we allocate enough space (actually the bo will most likely use 128
KiB pages and not aligning to that would be a waste anyway).

Cc: "9.2" mesa-stable@lists.freedesktop.org
get-pick-list: Allow for non-whitespace between "CC:" and "mesa-stable"

We recently proposed a new syntax for stable-patch nominations such as:

	CC: "9.2 and 9.1" <mesa-stable@lists.freedesktop.org>

and this has already appeared in the wild.

So we extend the regular expression to pick this up as well.
i965 Gen4/5: Introduce 'interpolation map' alongside the VUE map

The interpolation map (in brw->interpolation_mode) is a new auxiliary
structure alongside the post-GS VUE map, which describes the
interpolation modes for each VUE slot, for use by the clip and SF
stages.

This patch introduces a new state atom to compute the interpolation map,
and adjusts the program keys for the clip and SF stages, but it is not
actually used yet.

[V1-2]: Signed-off-by: Olivier Galibert <galibert at pobox.com>

V3: Updated for vue_map changes, intel -> brw merge, etc. (Chris Forbes)
V4: Compute interpolation map as a new state atom rather than tacking it
on the front of the clip setup
V5: Rework commit message, make interpolation_mode_map a struct.

Signed-off-by: Chris Forbes <chrisf@ijw.co.nz>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>