r600g: fix buffer copying on R600-R700

This fixes broken rendering in DOTA 2.

Cc: 10.0 10.1 mesa-stable@lists.freedesktop.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 0967970768c517c8c2f1a969e0a043982b4b1bf7)
r600g: fix for broken CULL_FRONT behavior on R6xx

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit ecc8a37ec5be7fca79205f08666fb76474ab5c0d)

Conflicts:
	src/gallium/drivers/r600/r600_pipe.h
r600g: fix for an MSAA hang on RV770

Cc: 10.0 10.1 mesa-stable@lists.freedesktop.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 3d0c4f3b01569f43318e648786ae79f7b6b4948e)
r600g: fix hang on RV740 by using DX_RASTERIZATION_KILL instead of SX_MISC

Changing SX_MISC hangs RV740. When we're at it, let's use DX_RASTERIZATION_KILL
on all R700 and later chipsets.

Cc: 10.0 10.1 mesa-stable@lists.freedesktop.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 3a3b1bf60e0ef233a8610684a7472e3600d0e65e)
gbm/dri: Fix out-of-memory error path in dri_device_create()

Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit aa91fe1c09e066751c5419adb7810745336bd051)
wayland: Fix the logic in disabling the prime capability

It looks like this bit of code is trying to disable the prime capability if
the driver doesn't support createImageFromFds. However the logic looks a bit
broken and what it would actually do is disable all other capabilities apart
from prime. This patch fixes it to actually disable prime.

Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 63d4661ab28c036ab000f94812a91d93d538a72a)
egl: Protect use of gbm_dri with ifdef HAVE_DRM_PLATFORM

Otherwise it fails to compile if the drm egl platform is disabled.

Cc: "10.0" "10.1" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 17860309f17de78e729f77e86101004f61f6bcf3)
st/mesa: Fix NULL pointer dereference for incomplete framebuffers

This can happen with glamor, which uses EGL_KHR_surfaceless_context and
only explicitly binds GL_READ_FRAMEBUFFER for glReadPixels.

Cc: mesa-stable@lists.freedesktop.org
Reviewed-by: Brian Paul <brianp@vmware.com>
(cherry picked from commit 136c437cea3ebc9541735bb40951128e1210f06b)
cherry-ignore: Ignore a patch causing a regression

This may be just a bogus test. I'm waiting to see what the bugzilla decides:

https://bugs.freedesktop.org/show_bug.cgi?id=77702
i965: Fix render-to-texture in non-FinishRenderTexture cases.

We've had several problems now with FinishRenderTexture not getting called
enough, and we're ready to just give up on it ever doing what we need.  In
particular, an upcoming Steam title had rendering bugs that could be fixed
by always_flush_cache=true.

Instead of hoping Mesa core can figure out when we need to flush our
caches, just track what BOs we've rendered to in a set, and when we render
from a BO in that set, emit a flush and clear the set.

There's some overhead to keeping this set, but most of that is just
hashing the pointer -- it turns out our set never even gets very large,
because cache flushes are so common (even on cairo-gl).

No statistically significant performance difference in cairo-gl (n=100),
despite spending ~.5% CPU in these set operations.

v1: (Original patch by Eric Anholt.)
v2: (Changes by Ken Graunke.)
  - Rebase forward from May 7th 2013 -> March 4th 2014.
  - Drop the FinishRenderTexture hook entirely; after rebasing the
    patch, the hook was just an empty function.
  - Move the brw_render_cache_set_clear() call from
    intel_batchbuffer_emit_flush() to brw_emit_pipe_control_flush().
    In theory, this could catch more cases where we've flushed.
  - Consider stencil as a possible texturing source.
v3: (changes by anholt):
  - Move set_clear() back to emit_mi_flush() -- it means we can drop
    more forced flushes from the code.  In the previous location, it
    wouldn't have been called when we wanted pre-gen6.
  - Move the set clear from batch init to reset -- it should be empty at
    the start of every batch, since the kernel handled any inter-batch
    flush for us.
v4: Drop the debug code in set.c that I accidentally committed.
v5: Back port to 10.1 stable branch (remove reference to stencil texture.)

Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Tested-by: Dylan Baker <baker.dylan.c@gmail.com> [v2]

Conflicts:
	src/mesa/drivers/dri/i965/brw_draw.c
	src/mesa/drivers/dri/i965/intel_fbo.h
i965: Don't enable reset notification support on Gen4-5.

arekm reported that using Chrome with GPU acceleration enabled on GM45
triggered the hw_ctx != NULL assertion in brw_get_graphics_reset_status.

We definitely do not want to advertise reset notification support on
Gen4-5 systems, since it needs hardware contexts, and we never even
request a hardware context on those systems.

Cc: "10.1" <mesa-stable@lists.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75723
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 0380ec467d78f40b5c8134158ca48b4c5378b282)
i965: Actually emit PIPELINE_SELECT and 3DSTATE_VF_STATISTICS.

For platforms using hardware contexts (currently Gen6+), we failed to
emit PIPELINE_SELECT and 3DSTATE_VF_STATISTICS, instead emitting MI_NOOP
for both.

During one of the context initialization reordering patches, we
accidentally moved brw_init_state before we set brw->CMD_PIPELINE_SELECT
and brw->CMD_VF_STATISTICS.  So, when brw_init_state uploaded initial
GPU state (brw_init_state -> brw_upload_initial_gpu_state ->
brw_upload_invariant_state), these would be 0 (MI_NOOP).

Storing the commands in the context is not worthwhile.  We have many
generation checks in our state upload code, and for platforms with
hardware contexts, this only gets called once per GL context anyway.
The cost is negligable, and it's easy to botch context creation
ordering.

This may fix hangs on Gen6+ when using the media pipeline.

Cc: "10.0 10.1" <mesa-stable@lists.freedesktop.org>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
(cherry picked from commit ac30e1adb49ec6947f740b47d90f8403fe416314)

Conflicts:
	src/mesa/drivers/dri/i965/brw_context.h
glsl: Allow overlapping locations for vertex input attributes

Currently overlapping locations of input variables are not allowed for all
the shader types in OpenGL and OpenGL ES.

From OpenGL ES 3.0 spec, page 56:
   "Binding more than one attribute name to the same location is referred
    to as aliasing, and is not permitted in OpenGL ES Shading Language
    3.00 vertex shaders. LinkProgram will fail when this condition exists.
    However, aliasing is possible in OpenGL ES Shading Language 1.00 vertex
    shaders."

Taking in to account what different versions of OpenGL and OpenGL ES specs
say about aliasing:
   - It is allowed only on vertex shader input attributes in OpenGL (2.0 and
     above) and OpenGL ES 2.0.
   - It is explictly disallowed in OpenGL ES 3.0.

Fixes Khronos CTS failing test:
explicit_attrib_location_vertex_input_aliased.test
See more details about this at below mentioned khronos bug.

V2: Fix the case where location exceeds the maximum allowed attribute
    location.
V3: Simplify the condition added in V2.

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: "9.2 10.0 10.1" <mesa-stable@lists.freedesktop.org>
Bugzilla: Khronos #9609
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 8c61b6a99b221439a8109c5a5cd03b7bf065d373)
mesa: Fix querying location of nth element of an array variable

This patch makes changes to the behavior of glGetAttribLocation(),
glGetFragDataLocation() and glGetFragDataIndex() functions.

Code changes handle a case described in following example:

shader program:
layout(location = 1)in vec4[4] a;
void main()
{
}

Currently, glGetAttribLocation("a") returns 1.
glGetAttribLocation("a[i]"), where i = {0, 1, 2, 3}, returns -1.
But the expected locations for array elements are: 1, 2, 3 and 4
respectively.

This clarification came up with the addition of
ARB_program_interface_query to OpenGL 4.3.

From Page 326 (page 347 of the PDF) of OpenGL 4.3 spec:
   "Otherwise, the command is equivalent to

    GetProgramResourceLocation(program, PROGRAM_INPUT, name);"

And, From Page 101 (page 122 of the PDF) of OpenGL 4.3 spec:

   "A string provided to GetProgramResourceLocation or
    GetProgramResourceLocationIndex is considered to match an active
    variable if

    • the string exactly matches the name of the active variable;
    • if the string identifies the base name of an active array, where
      the string would exactly match the name of the variable if the
      suffix "[0]" were appended to the string; or
    • if the string identifies an active element of the array, where
      the string ends with the concatenation of the "[" character, an
      integer (with no "+" sign, extra leading zeroes, or whitespace)
      identifying an array element, and the "]" character, the integer
      is less than the number of active elements of the array variable,
      and where the string would exactly match the enumerated name of
      the array if the decimal integer were replaced with zero."

V2: Simplify get_matching_index() function.
    Add relevant text from OpenGL spec in commit message.

Fixes failures in Khronos OpenGL CTS tests:
explicit_attrib_location_room
draw_instanced_max_vertex_attribs

Proprietary linux drivers of NVIDIA (331.49) matches the behavior
expected by OpenGL 4.3 spec.

Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit dc75479b7a7b9207d9d7c9487085ad14fa5d26cc)
mesa: Use location VERT_ATTRIB_GENERIC0 for vertex attribute 0

In OpenGL 3.1 attribute 0 becomes non-magic, just like in
OpenGL ES 2.0. Earlier versions of OpenGL used attribute 0
exclusively for vertex position.

V2: Add a utility function _mesa_attr_zero_aliases_vertex() in
    varray.h

Fixes 4 Khronos OpenGL CTS failures:
glGetVertexAttrib
depth24_basic
depth24_precision
rgb8_rgba8_rgb

Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 49c71050de1e0df451e29621558b4adfefb7e098)
glsl: Compile error if fs defines conflicting qualifiers for gl_FragCoord

GLSL 1.50 spec says:
   "If gl_FragCoord is redeclared in any fragment shader in a program,
    it must be redeclared in all the fragment shaders in that
    program that have a static use gl_FragCoord. All redeclarations of
    gl_FragCoord in all fragment shaders in a single program must
    have the same set of qualifiers."

This patch makes the glsl compiler to generate an error if we have a
fragment shader defined with conflicting layout qualifier declarations
for gl_FragCoord. For example:

layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord;
layout(pixel_center_integer) in vec4 gl_FragCoord;

void main()
{
}

V2: Some code refactoring for better readability.
    Add compiler error conditions for redeclarations like:

layout(origin_upper_left) in vec4 gl_FragCoord;
layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord;

and

in vec4 gl_FragCoord;
layout(origin_upper_left, pixel_center_integer) in vec4 gl_FragCoord;

V3: Simplify function is_conflicting_fragcoord_redeclaration()
V4: Check for null pointer before doing strcmp(var->name, "gl_FragCoord").

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 581e4acb0d68eb1063df3919e19e0ef9d86eebff)
glsl: Compile error if fs uses gl_FragCoord before first redeclaration

Section 4.3.8.1, page 39 of GLSL 1.50 spec says:
  "Within any shader, the first redeclarations of gl_FragCoord
   must appear before any use of gl_FragCoord."

GLSL compiler should generate an error in following case:

vec4 p = gl_FragCoord;
layout(origin_upper_left) in vec4 gl_FragCoord;

void main()
{
}

Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit a751adf07117ec4b3659fe60d0a833ebfcd4f840)
mesa: Add entry for extension ARB_texture_stencil8

V2: Alphabetize the new entry

Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 340658e44f87c98e840b98029c9b5a81d1bed837)
mesa: Add error condition for format=STENCIL_INDEX in glGetTexImage()

From OpenGL 4.0 spec, page 306:
   "Calling GetTexImage with a format of STENCIL_INDEX
    causes the error INVALID_ENUM."

Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit 5388fc157e2b78d67a05dc923b98857e6449cf1e)
i965: Fix crash in do_blit_readpixels()

Fixes a crash in Khronos CTS packed_pixels tests.

Cc: <mesa-stable@lists.freedesktop.org>
Signed-off-by: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
(cherry picked from commit d714b20eb4617f24b496a09028a90fdd8c19b5bd)