Skip to content
  1. Dec 01, 2019
  3. Nov 24, 2019
    • Connor Abbott's avatar
      fix · 116b8360
      Connor Abbott authored
      116b8360
    • Connor Abbott's avatar
      lima/gpir: Prevent infinite spill/unspill loops · 1618dada
      Connor Abbott authored 
      While it's guaranteed that we can always eventually schedule any node,
there were some rare cases where we keep unspilling other nodes so that
we never actually get anything done. Particularly in a scenario like
this:

1. The only fully-ready node would increase value register pressure by 2,
   but there are 11 live value registers (the other 10 are partially
   ready).
2. We try to speculatively schedule the fully-ready node, but we can only
   spill one other node so it fails.
3. Because there's now one slot free, we schedule a register store.
4. Now we're back to 2.

Fix this by disallowing any register stores from when spilling fails
until the next node is scheduled.
      1618dada
  5. Nov 23, 2019
    • Connor Abbott's avatar
      lima/gpir: Rewrite register allocation for value registers · 481e219c
      Connor Abbott authored 
      The usual linear-scan register allocation algorithm can't handle
preallocated registers, since we might be forced to choose a color for
a non-preallocated variable that overlaps with a pre-allocated variable.
But in such cases we can simply split the live range of the offending
variable when we reach the beginning of the pre-allocated variable's
live range. This is still optimal in the sense that it always finds a
coloring whenever one is possible, but we may not insert the smallest
possible number of moves. However, since it's actually the scheduler
which splits live ranges afterwards, we can simply fold in the move
while keeping its fake dependencies, and then everything still works! In
other words, inserting a live range split for a value register during
register allocation is pretty much free.

This means that we can split register allocation in two. First globally
allocate the cross-block registers accessed through load_reg and
store_reg instructions, which is still done via graph coloring, and then
run a linear scan algorithm over each block, treating the load_reg and
store_reg nodes as referring to pre-allocated registers. This makes the
existing RA more complicated, but it has two benefits: first, using
round-robin with the linear scan allocator results in much fewer fake
dependencies, resulting in around 15 less instructions in the glmark2
jellyfish shader and fixing a regression in instruction count since
branching support went in. Second, it will simplify handling spilling.
With just graph coloring for everything, every time we spill a node, we
have to create new value registers which become new nodes in the graph
and re-run RA. This is worsened by the fact that when writing a value to
a temporary, we need to have an extra register available to load the
write address with a load_const node. With the new scheme, we can ignore
this entirely in the first part and then in the second part we can just
reserve an extra register in sections where we know we have to spill. So
no re-running RA many times, and we can get a good result quickly.

The current implementation does linear scan backwards, so that we can
insert the fake dependencies while allocating and avoid creating any
move nodes at all when we have to split a live range. However, it turns
out that this makes handling schedule_first nodes a bit more
complicated, so it's not clear if that was worth it.
      481e219c
    • Connor Abbott's avatar
      lima: Add a NIR load duplicating pass · cae50b8d
      Connor Abbott authored 
      and use it with vertex shaders.
      cae50b8d
    • Connor Abbott's avatar
      lima/gpir: Optimize nots created from branch lowering · 21b3e0c9
      Connor Abbott authored 
      We also add a DCE pass to cleanup the result of this pass, which turns
out to also be necessary to cleanup the result of nir->gpir in some
cases that we didn't hit until the next commit.
      21b3e0c9
  7. Nov 03, 2019
  9. Oct 13, 2019
    • Connor Abbott's avatar
      lima/gpir: Make lima_gpir_node_insert_child() useful · 1a629b94
      Connor Abbott authored 
      We weren't using this function before. The name is confusing, but it
changes the child while also fixing up the dependence link, if you don't
have access to it already. Or at least, I think that's what the
intention is, and what we'll need to change the branch condition in the
next commit. Adding a dependency between the new and old source doesn't
make any sense for this, and we also need to change the actual source.
      1a629b94
  11. Oct 09, 2019
  13. Oct 08, 2019