1. 29 May, 2019 1 commit
    • Caio Oliveira's avatar
      nir: Allow derefs to be used as phi sources · 8bdf5a00
      Caio Oliveira authored
      
      
      It is possible and valid for a pointer to be selected based on a
      conditional before used, and depending on the mode, those cases will
      result in a phi with derefs as sources.
      
      To achieve this, we don't rematerialize derefs that are used by phis.
      As a consequence, when converting from SSA to regs, we may have phis
      that come from different blocks and are used by phis.  We now convert
      those to regs too.
      
      Validation was added to ensure only derefs of certain modes can be
      used as phi sources.  No extra validation is needed for the presence
      of cast, any instruction that uses derefs will validate the
      deref-chain is complete (ending in a cast or a var).
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      8bdf5a00
  2. 24 May, 2019 2 commits
  3. 20 May, 2019 1 commit
  4. 13 May, 2019 2 commits
    • Jason Ekstrand's avatar
      nir/validate: Use a single set for SSA def validation · 712f9993
      Jason Ekstrand authored
      
      
      The current SSA def validation we do in nir_validate validates three
      things:
      
       1. That each SSA def is only ever used in the function in which it is
          defined.
      
       2. That an nir_src exists in an SSA def's use list if and only if it
          points to that SSA def.
      
       3. That each nir_src is in the correct use list (uses or if_uses) based
          on whether it's an if condition or not.
      
      The way we were doing this before was that we had a hash table which
      provided a map from SSA def to a small ssa_def_validate_state data
      structure which contained a pointer to the nir_function_impl and two
      hash sets, one for each use list.  This meant piles of allocation and
      creating of little hash sets.  It also meant one hash lookup for each
      SSA def plus one per use as well as two per src (because we have to look
      up the ssa_def_validate_state and then look up the use.)  It also
      involved a second walk over the instructions as a post-validate step.
      
      This commit changes us to use a single low-collision hash set of SSA
      sources for all of this by being a bit more clever.  We accomplish the
      objectives above as follows:
      
       1. The list is clear when we start validating a function.  If the
          nir_src references an SSA def which is defined in a different
          function, it simply won't be in the set.
      
       2. When validating the SSA defs, we walk the uses and verify that they
          have is_ssa set and that the SSA def points to the SSA def we're
          validating.  This catches the case of a nir_src being in the wrong
          list.  We then put the nir_src in the set and, when we validate the
          nir_src, we assert that it's in the set.  This takes care of any
          cases where a nir_src isn't in the use list.  After checking that
          the nir_src is in the set, we remove it from the set and, at the end
          of nir_function_impl validation, we assert that the set is empty.
          This takes care of any cases where a nir_src is in a use list but
          the instruction is no longer in the shader.
      
       3. When we put a nir_src in the set, we set the bottom bit of the
          pointer to 1 if it's the condition of an if.  This lets us detect
          whether or not a nir_src is in the right list.
      
      When running shader-db with an optimized debug build of mesa on my
      laptop, I get the following shader-db CPU times:
      
         With NIR_VALIDATE=0       3033.34 seconds
         Before this commit       20224.83 seconds
         After this commit         6255.50 seconds
      
      Assuming shader-db is a representative sampling of GLSL shaders, this
      means that making this change yields an 81% reduction in the time spent
      in nir_validate.  It still isn't cheap but enabling validation now only
      increases compile times by 2x instead of 6.6x.
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Thomas Helland's avatarThomas Helland <thomashelland90@gmail.com>
      712f9993
    • Jason Ekstrand's avatar
      nir/validate: Use a ralloc context for our temporary data · 460567ea
      Jason Ekstrand authored
      
      
      All of our hash tables and sets are already using ralloc.  There's
      really no good reason why we don't just make a ralloc context rather
      than try to remember to clean everything up manually.
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
      Reviewed-by: Thomas Helland's avatarThomas Helland <thomashelland90@gmail.com>
      460567ea
  5. 14 Apr, 2019 1 commit
  6. 09 Apr, 2019 2 commits
  7. 30 Mar, 2019 1 commit
  8. 29 Mar, 2019 1 commit
  9. 21 Mar, 2019 1 commit
    • Karol Herbst's avatar
      nir: add support for gather offsets · 71c66c25
      Karol Herbst authored and Karol Herbst's avatar Karol Herbst committed
      
      
      Values inside the offsets parameter of textureGatherOffsets are required to be
      constants in the range of [GL_MIN_PROGRAM_TEXTURE_GATHER_OFFSET,
      GL_MAX_PROGRAM_TEXTURE_GATHER_OFFSET].
      
      As this range is never outside [-32, 31] for all existing drivers inside mesa,
      we can simply store the offsets as a int8_t[4][2] array inside nir_tex_instr.
      
      Right now only Nvidia hardware supports this in hardware, so we can turn this
      on inside Nouveau for the NIR path as it is already enabled with the TGSI one.
      
      v2: use memcpy instead of for loops
          add missing bits to nir_instr_set
          don't show offsets if they are all 0
      v3: default offsets aren't all 0
      v4: rename offsets -> tg4_offsets
          rename nir_tex_instr_has_explicit_offsets -> nir_tex_instr_has_explicit_tg4_offsets
      Signed-off-by: Karol Herbst's avatarKarol Herbst <kherbst@redhat.com>
      71c66c25
  10. 15 Mar, 2019 2 commits
  11. 06 Mar, 2019 1 commit
  12. 26 Jan, 2019 1 commit
  13. 20 Jan, 2019 2 commits
  14. 19 Jan, 2019 4 commits
  15. 14 Jan, 2019 1 commit
  16. 08 Jan, 2019 7 commits
  17. 16 Dec, 2018 1 commit
  18. 26 Oct, 2018 1 commit
  19. 25 Oct, 2018 1 commit
  20. 19 Sep, 2018 1 commit
  21. 17 Jul, 2018 1 commit
  22. 23 Jun, 2018 5 commits