1. 25 Sep, 2021 4 commits
  2. 24 Sep, 2021 1 commit
  3. 21 Sep, 2021 10 commits
  4. 20 Sep, 2021 1 commit
  5. 17 Sep, 2021 2 commits
    • Ian Romanick's avatar
      nir/edgeflags: Add a flag to indicate the edge flag input is needed · d7ba52cc
      Ian Romanick authored
      Most modern hardware needs the edge flag added as a hidden vertex input
      and needs code added to the vertex shader to copy the input to an
      output.  Intel hardware is a little different.  Gfx4 and Gfx5 hardware
      works in the previously described mannter.  Gfx6+ hardware needs the
      edge flag as a specific vertex shader input, and that input is magically
      processed by fixed-function hardware without need for extra shader code.
      This flag signals only that the vertex shader input is needed.  It would
      be nice if we could decouple adding the vertex shader input from
      generating the copy-to-output code, but that has proven to be
      challenging.  Not having that code causes other passes to want to
      eliminate that shader input.
      v2: Convert conditional to assertion.  This pass is only called for
      vertex shaders.  Suggested by Ken.
      Reviewed-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      Part-of: <!12858>
    • Rhys Perry's avatar
      nir/algebraic: distribute fmul(fadd(a, b), c) when b and c are constants · a1af9025
      Rhys Perry authored
      This allows for more MAD/FMA instructions to be created.
      fossil-db (Sienna Cichlid):
      Totals from 50134 (33.46% of 149839) affected shaders:
      VGPRs: 2436536 -> 2436000 (-0.02%); split: -0.05%, +0.03%
      SpillSGPRs: 13136 -> 13135 (-0.01%); split: -0.02%, +0.02%
      CodeSize: 206621424 -> 206278292 (-0.17%); split: -0.23%, +0.07%
      MaxWaves: 1116804 -> 1117448 (+0.06%); split: +0.07%, -0.01%
      Instrs: 38977460 -> 38862886 (-0.29%); split: -0.33%, +0.04%
      Latency: 832425389 -> 827432260 (-0.60%); split: -0.63%, +0.03%
      InvThroughput: 184193457 -> 183563350 (-0.34%); split: -0.37%, +0.03%
      Signed-off-by: Rhys Perry's avatarRhys Perry <pendingchaos02@gmail.com>
      Reviewed-by: Samuel Pitoiset's avatarSamuel Pitoiset <samuel.pitoiset@gmail.com>
      Reviewed-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      Part-of: <mesa/mesa!7458>
  6. 16 Sep, 2021 2 commits
    • Jason Ekstrand's avatar
      nir: Stop sweeping indirects · 6c7d23e6
      Jason Ekstrand authored
      They're no longer ralloc'd.
      Fixes: 879a5698
       "nir: Switch from ralloc to malloc for NIR instructions."
      Reviewed-by: Emma Anholt's avatarEmma Anholt <emma@anholt.net>
      Reviewed-by: default avatarIan Romanick <ian.d.romanick@intel.com>
      Part-of: <!12884>
    • Jason Ekstrand's avatar
      nir: Properly clean up nir_src/dest indirects · d1eae6f3
      Jason Ekstrand authored
      Now that they're no longer ralloc'd, we have to be much more careful
      about indirects.  We have to make sure every time a source or
      destination is overwritten, its indirect (if any) is freed.  We also
      have to choose a memory ownership convention for the rewrite functions.
      Assuming that they will be called with the source from some other
      instruction, we choose to always make a copy of the indirect (if any).
      It's the responsibility of the caller to ensure its copy of the indirect
      is freed.
      Unfortunately, all this extra logic is going to make
      nir_instr_rewrite/move_src/dest more expensive because they now have
      all the logic of nir_src/dest_copy instead of a simple struct
      assignment.  Fortunately, the vast majority of rewrite calls are done by
      nir_ssa_def_rewrite_uses which is an SSA-only fast-path.
      Fixes: 879a5698
       "nir: Switch from ralloc to malloc for NIR instructions."
      Reviewed-by: Emma Anholt's avatarEmma Anholt <emma@anholt.net>
      Part-of: <mesa/mesa!12884>
  7. 14 Sep, 2021 14 commits
  8. 13 Sep, 2021 1 commit
  9. 09 Sep, 2021 4 commits
  10. 08 Sep, 2021 1 commit