i965: Bump libdrm requirement

drm_intel_get_reset_stats is only available in libdrm-2.4.48, and
libdrm-2.4.49 contains an important bug fix in that function.

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit cb728bb028d782d5619e3da63afeeaf0b68507d0)
i965: Only enable __DRI2_ROBUSTNESS if kernel support is available

This is a squash of the following two cherry-picked patches:

    i965: Only enable __DRI2_ROBUSTNESS if kernel support is available

    Rather than always advertising the extension but failing to create a
    context with reset notifiction, just don't advertise it.  I don't know
    why it didn't occur to me to do it this way in the first place.

    NOTE: Kristian requested that I provide a follow-up for master that
    dynamically generates the list of DRI extensions instead of selected
    between two hardcoded lists.

    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Suggested-by: Kristian Høgsberg <krh@bitplanet.net>
    Reviewed-by: Matt Turner <mattst88@gmail.com>
    Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
    Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
    Cc: "10.0" <mesa-stable@lists.freedesktop.org>
    (cherry picked from commit 9b1c68638d8096304d3c4e0cceb97bb4dc61acc5)

and

    i965: Properly reject __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS when __DRI2_ROBUSTNESS is not enabled

    Only allow __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS in brwCreateContext if
    intelInitScreen2 also enabled __DRI2_ROBUSTNESS (thereby enabling
    GLX_ARB_create_context).

    This fixes a regression in the piglit test
    "glx/GLX_ARB_create_context/invalid flag"

    v2: Remove commented debug code.  Noticed by Jordan.

    Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
    Reported-by: Paul Berry <stereotype441@gmail.com>
    Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
    Reviewed-by: Matt Turner <mattst88@gmail.com>
    Cc: "10.0" <mesa-stable@lists.freedesktop.org>
    (cherry picked from commit 53a65e547c0bf769fff48b4ccb41d1477daa70de)
dri: Allow __DRI_CTX_FLAG_ROBUST_BUFFER_ACCESS in driCreateContextAttribs

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reported-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 73e9aa9e3f73d69ce4f0b68e74702d67842a230c)
i965: Always reserve binding table space for at least one render target.

In brw_update_renderbuffer_surfaces(), if there are no color draw
buffers, we always set up a null render target at surface index 0 so we
have something to use with the FB write marking the end of thread.

However, when we recently began computing surface indexes dynamically,
we failed to reserve space for it.  This meant that the first texture
would be assigned surface index 0, and our closing FB write would
clobber the texture.

Fixes Piglit's EXT_packed_depth_stencil/fbo-blit-d24s8 test on Gen4-5,
which regressed as of commit 4e5306453da6a1c076309e543ec92d999e02f67a
("i965/fs: Dynamically set up the WM binding table offsets.")

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70605
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Forbes <chrisf@ijw.co.nz>
Tested-by: lu hua <huax.lu@intel.com>
Cc: "10.0" mesa-stable@lists.freedesktop.org
(cherry picked from commit c4815f6cd6f659acd361f1b4cf63473a46ca7de9)
docs: Update release notes for 10.0

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
mesa: Bump version to 10.0 (final)

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
docs: Add 10.0 release md5sums

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
st/xa: Bump major version number to 2

For some reason this was left out when the version was changed...

Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
i965/gen6: Fix multisample resolve blits for luminance/intensity 32F formats.

On gen6, multisamble resolve blits use the SAMPLE message to blend
together the 4 samples for each texel.  For some reason, SAMPLE
doesn't blend together the proper samples when the source format is
L32_FLOAT or I32_FLOAT, resulting in blocky artifacts.

To work around this problem, sample from the source surface using
R32_FLOAT.  This shouldn't affect rendering correctness, because when
doing these resolve blits, the destination format is R32_FLOAT, so the
channel replication done by L32_FLOAT and I32_FLOAT is unnecessary.

Fixes piglit tests on Sandy Bridge:
- spec/ARB_texture_float/multisample-formats 2 GL_ARB_texture_float
- spec/ARB_texture_float/multisample-formats 4 GL_ARB_texture_float

No piglit regressions on Sandy Bridge.

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

Cc: Kenneth Graunke <kenneth@whitecape.org>
Cc: mesa-stable@lists.freedesktop.org

Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit c4cf487315f1f5375534f1677177983fa496d577)
i965/hsw: Apply non-msrt fast color clear w/a to all HSW GTs

Pre-patch, the workaround was applied to only HSW GT3. However, the
workaround also fixes render corruption on the HSW GT1 Chromebook,
codenamed Falco.

Also, update the BSpec quote that discusses the workaround to reflect
the latest BSpec.

The BSpec states that the workaround is required for Ivybridge and
Baytrail as well as Haswell. But, we apply the workaround to only
Haswell because (a) we suspect that is the only hardware where it is
actually required and (b) we haven't yet validated the workaround for
the other hardware.

CC: "9.2, 10.0" <mesa-stable@lists.freedesktop.org>
CC: Anuj Phogat <anuj.phogat@gmail.com>
OTC-Tracker: CHRMOS-812
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit 8b659cef3a244b1acdbbca0beb704a66b6bc2fbc)
i965: Add extra-alignment for non-msrt fast color clear for all hw (v2)

The BSpec states that the aligment for the non-msrt clear rectangle must
be doubled; the BSpec does not restricit the workaround to specific
hardware.

Commit 9a1a67b applied the workaround to Haswell GT3.  Commit 8b659ce
expanded the workaround to all Haswell variants. This commit expands it
to all hardware.

No Piglit regressions on Ivybridge 0x0166. No fixes either.

I know no Ivybridge nor Baytrail bug related to this workaround.
However, the BSpec says the extra alignment is required, so let's do it.

v2: Apply to all hardware, not just gen7.

CC: "9.2, 10.0" <mesa-stable@lists.freedesktop.org>
CC: Anuj Phogat <anuj.phogat@gmail.com>
Reviewed-by: Paul Berry <stereotype441@gmail.com>
Signed-off-by: Chad Versace <chad.versace@linux.intel.com>
(cherry picked from commit 998018d7be1380f055fb577b0782004657cc9509)
automake: include only one copy VERSION in tarball

The VERSION file is tracked by git (git ls-files), thus
adding it to EXTRA_FILES will result in a duplicate copy
within the final tarball.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72230
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
Reported-by: Patrick Steinhardt <ps@pks.im>
Tested-by: Patrick Steinhardt <ps@pks.im>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
(cherry picked from commit 507c2356e3caa3b7da98787ae2de96c7bca0089e)
mesa: don't leak performance monitors on context destroy

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Cc: "10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 267679be84de5bc9d2bd0fccb1712bc5cddb6be7)
Remove a057b83 from the pick list

Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
nv50: Fix GPU_READING/WRITING bit removal

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
CC: "9.1, 9.2, 10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit c45cf6199fc493538cef33125c8a97a892e2ca83)
nouveau: avoid leaking fences while waiting

This fixes a memory leak in some situations. Also avoids emitting an
extra fence if the kick handler does the call to nouveau_fence_next
itself.

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "9.2 10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit ce6dd69697ae62d9336bbd4f5808bc4d75cdcc04)
nv50: wait on the buf's fence before sticking it into pushbuf

This resolves some rendering issues in source games.
See https://bugs.freedesktop.org/show_bug.cgi?id=64323

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: "9.2 10.0" <mesa-stable@lists.freedesktop.org>
(cherry picked from commit 0e5bf8565106833e1a678ebdae81fdf1657391c9)