For instruction sequences that change the address register with every load the current limit to bail out of the scheduler and reject the optimisation was too tight, i.e. it was expected that at least one pending instruction would be scheduled each time.
Give the scheduler more margin to sort out these load sequences by allowing a number of rounds where no instruction is scheduled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106163 Signed-off-by: Gert Wollny <gw.foss...@gmail.com> --- src/gallium/drivers/r600/sb/sb_sched.cpp | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/src/gallium/drivers/r600/sb/sb_sched.cpp b/src/gallium/drivers/r600/sb/sb_sched.cpp index ffc66018b1..d37db99a55 100644 --- a/src/gallium/drivers/r600/sb/sb_sched.cpp +++ b/src/gallium/drivers/r600/sb/sb_sched.cpp @@ -1154,14 +1154,21 @@ bool post_scheduler::schedule_alu(container_node *c) { assert(!ready.empty() || !ready_copies.empty()); - bool improving = true; + /* This number is rather arbitrary, important is that the scheduler has + * more than one try to create an instruction group + */ + int improving = 10; int last_pending = pending.count(); - while (improving) { + while (improving > 0) { prev_regmap = regmap; if (!prepare_alu_group()) { int new_pending = pending.count(); - improving = (new_pending < last_pending) || (last_pending == 0); + if ((new_pending < last_pending) || (last_pending == 0)) + improving = 10; + else + --improving; + last_pending = new_pending; if (alu.current_idx[0] || alu.current_idx[1]) { -- 2.16.1 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev