I prefer some of my GLSL fixes in 1-4 over JP's changes, because they seem cleaner to me.
Marek On Oct 10, 2016 1:38 PM, "Tapani Pälli" <tapani.pa...@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.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? >> >> > 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 >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev