<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 17, 2016 at 10:21 AM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This little series prepares the backend compiler for invariant and precise<br>
by removing any potentially unsafe optimizations.  The easiest<br>
implementation for invariant and precise seems to be the same: Don't change<br>
the semantics of invariant or precise values.  This means that we need to<br>
track what values are invariant or precise and be very careful how we<br>
optimize them.  In the backend, it's easier to just not do those<br>
optimizations than to try and plumb that information through accurately.<br>
Fortunately, NIR is doing a good enough job that this can be done with a<br>
minimum of shader-db damage.<br></blockquote><div><br></div><div>There has been some discussion on patches on the ML and in the cube as to how much we want to delete.  According to my (admittedly a bit dated) shader-db, we can delete quite a lot without really hurting much.  However, not everyone seems comfortable with this.  I don't much care about deleting everything I just decided to try it and see what happens.  Here are the things I think we do need to do:<br><br></div><div> 1) Get rid of RCP+RSQ<br></div><div> 2) Stop constant-folding RCP<br></div><div> 3) Make opt_vector_float correct regardless of opt_algebraic handling mov.sat of immediates.<br><br></div><div>I think (1) and (2) are enough for getting "invariant" and "precise" correct.  The bugs in opt_vector_float I think are real, but my patches to fix them are equally bogus.<br><br>The rest of the series is just deleting potentially dead code.  I don't care too much either way on that.  To summarize, the other potentially deletable things are:<br><br></div><div> 1) the MAD optimization in fs_opt_algebraic<br></div><div> 2) the SEL.sat optimization (both fs and vec4)<br></div><div> 3) the trivial floating-point algebraic optimizations (most of these are probably precise-safe but they aren't doing anything)<br></div><div> 4) MOV.sat on immediates<br><br></div><div>Opinions?<br></div><div>--Jason<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jason Ekstrand (9):<br>
  i965/fs: Remove the RCP+RSQ peephole<br>
  nir/algebraic: Add two more fsat optimizations<br>
  i965/fs: Get rid of the sel.sat peephole<br>
  i965/fs: Get rid of all remaining algebraic optimizations for floats<br>
  i965/fs: Don't constant-fold RCP<br>
  i965/vec4: Don't constant propagate saturated values<br>
  i965/vec4: Don't allow type conversion in opt_vector_float<br>
  i965/vec4: Handle saturated constants in opt_vector_float<br>
  i965/vec4: Disable algebraic optimizations on floats<br>
<br>
 src/compiler/nir/nir_opt_algebraic.py              |   2 +<br>
 src/mesa/drivers/dri/i965/brw_fs.cpp               | 119 ++++-----------------<br>
 .../drivers/dri/i965/brw_fs_copy_propagation.cpp   |  15 ---<br>
 src/mesa/drivers/dri/i965/brw_vec4.cpp             |  49 ++++-----<br>
 .../drivers/dri/i965/brw_vec4_copy_propagation.cpp |   3 +<br>
 5 files changed, 41 insertions(+), 147 deletions(-)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
2.5.0.400.gff86faf<br>
<br>
</font></span></blockquote></div><br></div></div>