If we accidentally create a message long enough that base_mrf + mlen > BRW_MAX_MRF, instruction scheduling would access past the end of the last_mrf_write array.
Add assertions to catch cases where we would do that. Use the Elements macro rather than using BRW_MAX_MRF directly since we may rework that someday (as it's platform specific). Note that we currently -do- create bogus messages, so this failure will cause assertion failures in some cases (such as gzdoom). That said, it would previously crash, so it's not really a regression. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48218 Signed-off-by: Kenneth Graunke <[email protected]> --- .../dri/i965/brw_fs_schedule_instructions.cpp | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp b/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp index 910f329..b5a8acb 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_schedule_instructions.cpp @@ -290,6 +290,8 @@ instruction_scheduler::calculate_deps() } } + assert(inst->base_mrf + inst->mlen < int(Elements(last_mrf_write))); + for (int i = 0; i < inst->mlen; i++) { /* It looks like the MRF regs are released in the send * instruction once it's sent, not when the result comes @@ -370,6 +372,8 @@ instruction_scheduler::calculate_deps() } } + assert(inst->base_mrf + inst->mlen < int(Elements(last_mrf_write))); + for (int i = 0; i < inst->mlen; i++) { /* It looks like the MRF regs are released in the send * instruction once it's sent, not when the result comes -- 1.7.9.5 _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
