r600g/sb: fix stack size computation on evergreen

On evergreen we have to reserve 1 stack element in some additional cases
besides the ones mentioned in the docs, but stack size computation was
recently reimplemented exactly as described in the docs by the patch that
added workarounds for stack issues on EG/CM, resulting in regressions
with some apps (Serious Sam 3).

This patch fixes it by restoring previous behavior.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=72369

Signed-off-by: Vadim Girlin <vadimgirlin@gmail.com>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Tested-by: Andre Heider <a.heider@gmail.com>
(cherry picked from commit 00faf82832f3e6ef886abad246b50cc47b901c1f)
mesa: fix interpretation of glClearBuffer(drawbuffer)

This corresponding piglit tests supported this incorrect behavior instead of
pointing at it.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: 10.0 9.2 9.1 <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 03d848ea1003abefd8fe51a5b4a780527cd852af)
dri_util: Don't assume __DRIcontext->driverPrivate is a gl_context

The driverPrivate pointer is opaque to the driver and we can't assume
it's a struct gl_context in dri_util.c.  Instead provide a helper function
to set the struct gl_context flags from the incoming DRI context flags.

v2 (idr): Modify the other classic drivers to also use
driContextSetFlags.  I ran all the piglit GLX_ARB_create_context tests
with i965 and classic swrast without regressions.

Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com> [v1]
Reviewed-by: Eric Anholt <eric@anholt.net>
Tested-by: Ilia Mirkin <imirkin@alum.mit.edu> [v1 on Gallium nouveau]
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 38366c0c6e715314367b15680702e382d5c46a4a)
mesa: Fix error code generation in glBeginConditionalRender()

This patch changes the error condition to satisfy below statement
from OpenGL 4.3 core specification:
"An INVALID_OPERATION error is generated if id is the name of a query
object with a target other SAMPLES_PASSED, ANY_SAMPLES_PASSED, or
ANY_SAMPLES_PASSED_CONSERVATIVE, or if id is the name of a query
currently in progress."

Cc: mesa-stable@lists.freedesktop.org
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 7a73c6acb0a4f5f049795f73a54a08a6dbe166ed)
Use line number information from entire function expression

This patch changes the error reporting behavior for incorrect function
invocation (triggered by match_function_by_name() unable to find a
matching function call) from using the line number information
associated to the function name term to using the line number
information of the entire function expression. Fixes bug #72264.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72264
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 23d294bb60be41e3876179e7b763a275902d1efd)
i965: Fix 3DSTATE_PUSH_CONSTANT_ALLOC_PS packet creation.

When adding geometry shader support, we accidentally reversed the size
and offset parameters.

Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 51c9cfc296318760aab421a79da727acd0e36311)
i915: Add support for gl_FragData[0] reads.

Similar to 556a47a2621073185be83a0a721a8ba93392bedb, without this reading from
gl_FragData[0] would cause a software fallback.

Bugzilla: https://bugs.winehq.org/show_bug.cgi?id=33964
Signed-off-by: Henri Verbeet <hverbeet@gmail.com>
Cc: 10.0 9.2 9.1 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
(cherry picked from commit b094b3b9f4c7b40056c31e3480ab7dc530da56e7)
st/mesa: use pipe_sampler_view_release()

This fixes a crash where old_view->context was already freed in the
pipe_sampler_view_reference function contained in
src/gallium/auxiliary/utils/u_inlines.h. As a result, the
sampler_view_destroy function pointer contained 0xfeeefeee indicating
freed heap memory.

Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jonathan Liu <net147@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 670be71bd801fea876f7512865ed5f54340da9be)
llvmpipe: use pipe_sampler_view_release() to avoid segfault

This fixes another case of faulting when freeing a pipe_sampler_view
that belongs to a previously destroyed context.

Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Jonathan Liu <net147@gmail.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 7990ab58fa01cbebcefd63dd25af5fd6fdddf019)
clover: Remove unused variable

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

CC: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 862f55c29c50798942e58ea75c5294921c0489f8)
pipe_loader/sw: close dev->lib when initialization fails

Prevents a memory leak.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

CC: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit a7653c19a3b1adae162864587a7ab1c17ab256e6)
radeon/compute: Stop leaking LLVMContexts in radeon_llvm_parse_bitcode

Previously we were creating a new LLVMContext every time that we called
radeon_llvm_parse_bitcode, which caused us to leak the context every time
that we compiled a CL program.

Sadly, we can't dispose of the LLVMContext at the point that it was being
created because evergreen_launch_grid (and possibly the SI equivalent) was
assuming that the context used to compile the kernels was still available.

Now, we'll create a new LLVMContext when creating EG/SI compute state, store
it there, and pass it to all of the places that need it.

The LLVM Context gets destroyed when we delete the EG/SI compute state.

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

CC: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 8c9a9205d96b5ac0718218bfa952a5b4b6ad939c)
r600/compute: Free compiled kernels when deleting compute state

v2: Remove unnecessary null pointer check

CC: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit e19717d075bd26c16e12564ed578ff519a5ce57a)
r600/compute: Use the correct FREE macro when deleting compute state

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

CC: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 0bd858d7ff4a16228164e3157aca846edeb6c228)
radeon/llvm: Free target data at end of optimization

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

CC: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 767b0f82c37f0370c05335120e50f0a534549109)
st/vdpau: Destroy context when initialization fails

Prevents a potential memory leak found when tracking down something else.

Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

CC: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 20446d0e535c0735489c8944e8d767e0fc74fc6e)
r600/pipe: Stop leaking context->start_compute_cs_cmd.buf on EG/CM

Found while tracking down memory leaks in VDPAU playback

Reviewed-by: Tom Stellard <thomas.stellard@amd.com>

CC: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 3ddabe0d523416693f28e293d8d3d918bdb612ca)
r600g: fix SUMO2 pci id

0x9649 is sumo2, not sumo.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
CC: "9.2" "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit e2d53fac1c5b18f5c9e95d39d4e2be4703b0b363)
Revert "mesa: Remove GLXContextID typedef from glx.h."

This reverts commit 136a12ac98868d82c2ae9fcc80d11044a7ec56d1.

According to belak51 on IRC, this commit broke Allegro, which would no
longer compile.  Applications apparently expect the GLXContextID typedef
to exist in glx.h; removing it breaks them.  A bit of searching around
the internet revealed other complaints since upgrading to Mesa 10.

Cc: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit f425d56ba41382be04366d011536ee78a03a2f33)
glcpp: error on multiple #else/#elif directives

The preprocessor currently accepts multiple else/elif-groups
per if-section. The GLSL-preprocessor is defined by the C++
specification, which defines the following parse-rule:

if-section:
	if-group elif-groups(opt) else-group(opt) endif-line

This clearly only allows a single else-group, that has to come
after any elif-groups.

So let's modify the code to follow the specification. Add test
to prevent regressions.

Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Carl Worth <cworth@cworth.org>

Cc: 10.0 <mesa-stable@lists.freedesktop.org>
(cherry picked from commit eb212c5a302f0122a13b36dfdf07e91f951ae2e7)