On 16 December 2017 at 01:12, Jason Ekstrand <ja...@jlekstrand.net> wrote: > 18fde36ced4279f2577097a1a7d31b55f2f5f141 changed the way temporary > registers were allocated in lower_integer_multiplication so that we > allocate regs_written(inst) space and keep the stride of the original > destination register. This was to ensure that any MUL which originally > followed the CHV/BXT integer multiply regioning restrictions would > continue to follow those restrictions even after lowering. This works > fine except that I forgot to reset the register file to VGRF so, even > though they were assigned a number from alloc.allocate(), they had the > wrong register file. This caused some GLES 3.0 CTS tests to start > failing on Sandy Bridge due to attempted reads from the MRF: > > ES3-CTS.functional.shaders.precision.int.highp_mul_fragment.snbm64 > ES3-CTS.functional.shaders.precision.int.mediump_mul_fragment.snbm64 > ES3-CTS.functional.shaders.precision.int.lowp_mul_fragment.snbm64 > ES3-CTS.functional.shaders.precision.uint.highp_mul_fragment.snbm64 > ES3-CTS.functional.shaders.precision.uint.mediump_mul_fragment.snbm64 > ES3-CTS.functional.shaders.precision.uint.lowp_mul_fragment.snbm64 > > This commit remedies this problem by, instead of copying inst->dst and > overwriting nr, just make a new register and set the region to match > inst->dst. > > Cc: Matt Turner <matts...@gmail.com> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103626 > Fixes: 18fde36ced4279f2577097a1a7d31b55f2f5f141 > Cc: "17.3" <mesa-sta...@lists.freedesktop.org> > --- It seems like this has fallen through the cracks. Can anyone lend a hand?
Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
