[Mesa-dev] Mesa 17.0.1 release candidate

Emil Velikov emil.l.velikov at gmail.com
Thu Mar 2 17:28:07 UTC 2017


On 2 March 2017 at 16:39, Jason Ekstrand <jason at jlekstrand.net> wrote:
> On Mar 2, 2017 3:38 AM, "Emil Velikov" <emil.l.velikov at gmail.com> wrote:
>
> On 1 March 2017 at 20:06, Jason Ekstrand <jason at jlekstrand.net> wrote:
>> On Wed, Mar 1, 2017 at 10:35 AM, 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.
>>
>>
>> I don't see the remove patch on the queue below.
>>
> As always, fixes are squashed with the regressing commit.
>
> In this case "i965/fs: Remove the inline pack_double_2x32
> optimization" is folded with "i965/fs: Fix the inline
> nir_op_pack_double optimization".
> Admittedly I should have dropped the regressing commit in the first place.
>
>
> No, it was a bugfix it just didn't fix enough of it.
>
> How does the following [kind of] note look ? I don't mind adding it
> for future instances.
>
> ...
>        i965/fs: Fix the inline nir_op_pack_double optimization
> * Squashed with:
>        i965/fs: Remove the inline pack_double_2x32 optimization
> ...
>
>
> In this particular case, I wouldn't even mention the "fix" commit.  The
> correct fix was to just drop the optimization altogether.
That's precisely what I said above - should have dropped "Fix the
inline..." in the first place ;-)

Looking for the more generic case - are you for/against like the proposed idea ?
It provides a quick and easy feedback which I think you/others will appreciate.

-Emil
P.S. Can I interest you in using plain/text emails ? Formatting is all
over the place :-\


More information about the mesa-dev mailing list