[Mesa-dev] [Mesa-announce] Mesa 17.0.1 release candidate

[Marek Olšák]

On Wed, Mar 1, 2017 at 7:35 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> Hello list,
>
> The candidate for the Mesa 17.0.1 is now available. Currently we have:
>  - 60 queued
>  - 9 nominated (outstanding)
>  - and 0 rejected patch(es)
>
>
> The current queue consists of:
>
> On the GLX/EGL front we have a GLVND fix for "The Binding of Isaac: Rebirth"
> and other games, eglQuerySurface now returns correct geometry when running
> under X11/DRI3.
>
> There's a number of crash fixes affecting all Gallium drivers. An old
> regression fix for r300 on BE hardware been fixed. The radeonsi driver has
> fixes for Tessellation shaders on Carrizo and Stoney hardware.
>
> While on the nouveau side, compute shader have been improved on some
> nvc0 devices.
>
> The vc4 and etnaviv drivers have also seen a couple of small fixe.
>
> For the Intel drivers (both GL and Vulkan) we have a diverse bunch of patches -
> from CTS fixes for Sandy Bridge, to improved swizzle clears and improved
> handling of GPUs without (Last Level Cache) LLC.
>
> On integration side - we had some Android build fixes and a new script to
> parse and look for bug fixes.
>
>
> And for those of you wondering - the delay was caused by a buggy optimisation
> pass, that has since been removed.
>
>
> Take a look at section "Mesa stable queue" for more information.
>
>
> Testing reports/general approval
> --------------------------------
> Any testing reports (or general approval of the state of the branch) will be
> greatly appreciated.
>
> The plan is to have 17.0.1 this Friday (3th of March), around or shortly
> after 19:00 GMT.
>
> If you have any questions or suggestions - be that about the current patch
> queue or otherwise, please go ahead.
>
>
> Trivial merge conflicts
> -----------------------
> commit 9c80a8133f8e75d95bad54bae92402fa7a7252e0
> Author: Marek Olšák <marek.olsak at amd.com>
>
>     radeonsi: fix UNSIGNED_BYTE index buffer fallback with non-zero start (v2)
>
>     (cherry picked from commit a264fee6245856340fab9024e1a428626e966335)
>
>
> Marek, the above commit seems to imply 791e8ce04a7e9970f437858bdff0a1f8b47626ba.
> Can you please let me know if we should pick the latter as well ?

No, it's not necessary and it wouldn't compile, because that depends
on yet another patch.

Marek