1. 29 Jul, 2019 33 commits
  2. 28 Jul, 2019 3 commits
    • Connor Abbott's avatar
      lima/gpir/sched: Handle more special ops in can_use_complex() · 6fc7384f
      Connor Abbott authored
      We were missing handling for a few other ops that rearrange their
      sources somehow in codegen, namely complex2 and select.
      This should fix spec@glsl-1.10@execution@built-in-functions@vs-asin-vec3
      and possibly other random regressions from the new scheduler which were
      supposed to be fixed in the commit right after.
      Fixes: 54434fe6
       ("lima/gpir: Rework the scheduler")
      Signed-off-by: Connor Abbott's avatarConnor Abbott <cwabbott0@gmail.com>
      Acked-by: Qiang Yu's avatarQiang Yu <yuq825@gmail.com>
    • Connor Abbott's avatar
      lima/gp: Clean up lima_program_optimize_vs_nir() a little · af95f80a
      Connor Abbott authored
      Remove an unnecessary nir_lower_regs_to_ssa as that should be done by
      the state tracker, and add a missing DCE pass after running copy
      propagation in order to remove the dead copies. This shouldn't fix
      anything but the second part will reduce shader sizes.
      Signed-off-by: Connor Abbott's avatarConnor Abbott <cwabbott0@gmail.com>
      Reviewed-by: Qiang Yu's avatarQiang Yu <yuq825@gmail.com>
    • Connor Abbott's avatar
      lima/gpir/sched: Don't try to spill when something else has succeeded · d26d8c56
      Connor Abbott authored
      In try_node(), we assume that the node we pick can still be scheduled
      successfully after speculatively trying all the other nodes. Normally we
      always undo every node after speculating it, so that when we finally
      schedule best_node the scheduler state is exactly the same and it
      succeeds. However, we also try to spill nodes, which can change the
      state and in a corner case that can make scheduling best_node fail. In
      particular, the following sequence of events happened with piglit
      shaders@glsl-vs-if-nested: a partially-ready node N was spilled and a
      register store node S, which is a use of N, was created and then later
      the other uses of N were scheduled, so that S is now ready and N is
      partially ready. First we try to schedule S and succeed, then we try to
      schedule another node M, which fails, so we try to spill the remaining
      uses of N. This succeeds, but scheduling M still fails so that best_node
      is still S. However since one of the uses of N is one cycle ago, and
      therefore we inserted a read dependent on S one cycle ago when spilling
      N, S can no longer be scheduled as read-after-write latency is three
      While we could ad-hoc try to catch cases like this, or (the best option
      but very complicated) treat the spill as speculative and roll it back if
      we decide not to schedule the node, a simpler solution is to just
      give up on spilling if we've already successfully speculatively
      scheduled another node. We'd give up a few cases where we discover that
      by spilling even harder we could schedule a more desirable node, but
      that seems like it would be pretty rare in practice. With this we
      guarantee that nothing has been touched after best_node was successfully
      scheduled. We also cut down on pointless spilling, since if we already
      scheduled a node it's unlikely that spilling harder will let us schedule
      an even better node, and hence any spilling at this point is probably
      While we're here, clean up the code around spilling by flattening the
      two if's and getting rid of the second unnecessary check for INT_MIN.
      Fixes: 54434fe6
       ("lima/gpir: Rework the scheduler")
      Acked-by: Qiang Yu's avatarQiang Yu <yuq825@gmail.com>
      Signed-off-by: Connor Abbott's avatarConnor Abbott <cwabbott0@gmail.com>
  3. 27 Jul, 2019 4 commits