On Mon, Oct 10, 2016 at 1:25 PM, Tapani Pälli <tapani.pa...@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 <mar...@gmail.com> wrote: >>> >>> On Mon, Oct 10, 2016 at 7:58 AM, Tapani Pälli <tapani.pa...@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 >>>> >>>> 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? Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
