[Mesa-dev] [PATCH 00/15] GLSL memory allocation rework for faster compilation

[Tapani Pälli]

On 10/10/2016 02:52 PM, Marek Olšák wrote:
> I prefer some of my GLSL fixes in 1-4 over JP's changes, because they
> seem cleaner to me.

Agreed, I was considering following patches from JP:

https://patchwork.freedesktop.org/patch/93266/
https://patchwork.freedesktop.org/patch/93262/
https://patchwork.freedesktop.org/patch/93267/

these could be pushed separately and do not cause any functional change.


> Marek
>
>
> On Oct 10, 2016 1:38 PM, "Tapani Pälli" <tapani.palli at intel.com
> <mailto:tapani.palli at intel.com>> wrote:
>
>
>
>     On 10/10/2016 02:27 PM, Marek Olšák wrote:
>
>         On Mon, Oct 10, 2016 at 1:25 PM, Tapani Pälli
>         <tapani.palli at intel.com <mailto:tapani.palli at intel.com>> wrote:
>
>
>
>             On 10/10/2016 01:38 PM, Marek Olšák wrote:
>
>
>                 On Mon, Oct 10, 2016 at 12:33 PM, Marek Olšák
>                 <maraeo at gmail.com <mailto:maraeo at gmail.com>> wrote:
>
>
>                     On Mon, Oct 10, 2016 at 7:58 AM, Tapani Pälli
>                     <tapani.palli at intel.com <mailto:tapani.palli at intel.com>>
>                     wrote:
>
>
>
>
>                         On 10/08/2016 06:58 PM, Jason Ekstrand wrote:
>
>
>
>                             FYI, we use ralloc for a lot more than just
>                             the glsl compiler so the
>                             first few changes make me a bit nervous.
>                             There was someone working on
>                             making our driver more I
>                             undefined-memory-friendly but I don't know
>                             what
>                             happened to those patches.
>
>
>
>
>                         There's bunch of patches like that in this series:
>                         https://lists.freedesktop.org/archives/mesa-dev/2016-June/120445.html
>                         <https://lists.freedesktop.org/archives/mesa-dev/2016-June/120445.html>
>
>                         it looks like it just never landed as would have
>                         required more testing
>                         on
>                         misc drivers?
>
>
>
>                     We can land at least some of the patches from that
>                     series. We still
>                     have to replace all non-GLSL uses of
>                     DECLARE_RALLOC.. with
>                     DECLARE_RZALLOC.
>
>
>
>                 BTW, people can still give Rbs on all patches except 5.
>                 This rzalloc
>                 thing isn't an issue and can be dealt with in a separate
>                 series (it
>                 can be done after this series lands).
>
>
>
>             I agree these issues do not block review of the series. We
>             just need to make
>             sure it is absolutely safe before landing.
>
>             As concrete example I got following segfault when I applied
>             this series
>             which is directly related to rzalloc issues. This was with
>             'shader_freeze'
>             program, description in bug #94477 has link and build
>             instructions for this
>             if you want to try. When I applied JP's patches 4,5,6 (nir,
>             i965_vec4,
>             i965_fs changes) this segfault disappears.
>
>
>         I meant that this series is safe to land without patch 5. Did
>         you test
>         it without patch 5?
>
>
>     Ah sorry I managed to miss that. Now I did test and when reverting
>     patch 5 this test passes fine. Makes sense to do patch 5 as a
>     separate step when JP's changes land.
>
>     // Tapani
>