| Summary: | [SNB] ES3-CTS.functional.shaders.precision | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Mark Janes <mark.a.janes> |
| Component: | Drivers/DRI/i965 | Assignee: | Jason Ekstrand <jason> |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | normal | ||
| Priority: | medium | ||
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 104757 | ||
Jason has posted a patch for this a while back https://patchwork.freedesktop.org/patch/193639/ This is fixed in the following commit: commit db682b8f0eafd3b9d58e736e9e2f520943a89942 Author: Jason Ekstrand <jason.ekstrand@intel.com> Date: Thu Dec 14 22:10:10 2017 -0800 i965/fs: Reset the register file to VGRF in lower_integer_multiplication 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. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103626 Fixes: 18fde36ced4279f2577097a1a7d31b55f2f5f141 Cc: "17.3" <mesa-stable@lists.freedesktop.org> Reviewed-by: Matt Turner <mattst88@gmail.com> |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Regressions: 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 src/intel/compiler/brw_fs.cpp:838: unsigned int fs_inst::size_read(int) const: Assertion `!"MRF registers are not allowed as sources"' failed. Bisected to: 18fde36ced4279f2577097a1a7d31b55f2f5f141 Author: Jason Ekstrand <jason@jlekstrand.net> intel/fs: Use the original destination region for int MUL lowering Some hardware (CHV, BXT) have special restrictions on register regions when doing integer multiplication. We want to respect those when we lower to DxW multiplication. Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Cc: mesa-stable@lists.freedesktop.org