1. 30 Sep, 2020 1 commit
  2. 02 Sep, 2020 2 commits
  3. 23 Aug, 2019 1 commit
  4. 20 Aug, 2019 3 commits
  5. 14 Aug, 2019 1 commit
  6. 23 Jul, 2019 1 commit
  7. 01 May, 2019 5 commits
  8. 09 Apr, 2019 1 commit
  9. 28 Mar, 2019 1 commit
  10. 21 Mar, 2019 3 commits
  11. 27 Dec, 2018 1 commit
  12. 18 Oct, 2018 1 commit
  13. 20 Jun, 2018 5 commits
  14. 16 Nov, 2017 1 commit
  15. 30 Sep, 2017 1 commit
  16. 29 Sep, 2017 2 commits
    • Nicolai Hähnle's avatar
    • Nicolai Hähnle's avatar
      tgsi: clarify the semantics of DFRACEXP · 3c78215a
      Nicolai Hähnle authored
      The status quo is quite the mess:
      
      1. tgsi_exec will do a per-channel computation, and store the dst[0]
         result (significand) correctly for each channel. The dst[1] result
         (exponent) will be written to the first bit set in the writemask.
         So per-component calculation only works partially.
      
      2. r600 will only do a single computation. It will replicate the
         exponent but not the significand.
      
      3. The docs pretend that there's per-component calculation, but even
         get dst[0] and dst[1] confused.
      
      4. Luckily, st_glsl_to_tgsi only ever emits single-component instructions,
         and kind-of assumes that everything is replicated, generating this for
         the dvec4 case:
      
           DFRACEXP TEMP[0].xy, TEMP[1].x, CONST[0][0].xyxy
           DFRACEXP TEMP[0].zw, TEMP[1].y, CONST[0][0].zwzw
           DFRACEXP TEMP[2].xy, TEMP[1].z, CONST[0][1].xyxy
           DFRACEXP TEMP[2].zw, TEMP[1].w, CONST[0][1].zwzw
      
      Settle on the simplest behavior, which is single-component calculation
      with replication, document it, and adjust tgsi_exec and r600.
      Reviewed-by: default avatarMarek Olšák <marek.olsak@amd.com>
      Tested-by: Dieter Nützel's avatarDieter Nützel <Dieter@nuetzel-hh.de>
      3c78215a
  17. 07 Sep, 2017 1 commit
  18. 22 Aug, 2017 6 commits
  19. 10 Jun, 2017 1 commit
    • Marius Gräfe's avatar
      gallium: fixed modulo zero crashes in tgsi interpreter (v2) · f3c0bbe1
      Marius Gräfe authored
      softpipe throws integer division by zero exceptions on windows
      when using % with integers in a geometry shader.
      
      v2: Made error results consistent with existing div/mod zero handling in
          tgsi. 64 bit signed integer division by zero returns zero like in
          micro_idiv, unsigned returns ~0u like in micro_udiv.
          Modulo operations always set all result bits to one (like in
          micro_umod).
      Reviewed-by: default avatarRoland Scheidegger <sroland@vmware.com>
      f3c0bbe1
  20. 31 Mar, 2017 1 commit
  21. 15 Mar, 2017 1 commit
    • Francisco Jerez's avatar
      gallium/tgsi: Treat UCMP sources as floats to match the GLSL-to-TGSI pass expectations. · e6469ec4
      Francisco Jerez authored
      Currently the GLSL-to-TGSI translation pass assumes it can use
      floating point source modifiers on the UCMP instruction.  See the bug
      report linked below for an example where an unrelated change in the
      GLSL built-in lowering code for atan2 (e9ffd128)
      caused the generation of floating-point ir_unop_neg instructions
      followed by ir_triop_csel, which is translated into UCMP with a negate
      modifier on back-ends with native integer support.
      
      Allowing floating-point source modifiers on an integer instruction
      seems like rather dubious design for a transport IR, since the same
      semantics could be represented as a sequence of MOV+UCMP instructions
      instead, but supposedly this matches the expectations of TGSI
      back-ends other than tgsi_exec, and the expectations of the DX10 API.
      I take no responsibility for future headaches caused by this
      inconsistency.
      
      Fixes a regression of piglit glsl-fs-tan-1 on softpipe introduced by
      the above-mentioned glsl front-end commit.  Even though the commit
      that triggered the regression doesn't seem to have made it to any
      stable branches yet, this might be worth back-porting since I don't
      see any reason why the bug couldn't have been reproduced before that
      point.
      Suggested-by: default avatarRoland Scheidegger <sroland@vmware.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99817Reviewed-by: default avatarRoland Scheidegger <sroland@vmware.com>
      e6469ec4