1. 18 Nov, 2020 1 commit
  2. 29 Apr, 2020 1 commit
  3. 14 Nov, 2019 1 commit
  4. 28 Oct, 2019 1 commit
  5. 15 Aug, 2019 1 commit
  6. 23 Jul, 2019 1 commit
  7. 19 Jul, 2019 1 commit
  8. 25 Apr, 2019 4 commits
  9. 19 Dec, 2018 2 commits
  10. 14 Apr, 2018 1 commit
  11. 13 Apr, 2018 1 commit
  12. 20 Nov, 2017 2 commits
  13. 09 Nov, 2017 5 commits
    • Nicolai Hähnle's avatar
      ddebug: optionally handle transfer commands like draws · b07569ad
      Nicolai Hähnle authored
      Transfer commands can have associated GPU operations.
      
      Enabled by passing GALLIUM_DDEBUG=transfers.
      Reviewed-by: default avatarMarek Olšák <marek.olsak@amd.com>
      b07569ad
    • Nicolai Hähnle's avatar
    • Nicolai Hähnle's avatar
    • Nicolai Hähnle's avatar
      ddebug: rewrite to always use a threaded approach · c9fefa06
      Nicolai Hähnle authored
      This patch has multiple goals:
      
      1. Off-load the writing of records in 'always' mode to another thread
         for performance.
      
      2. Allow using ddebug with threaded contexts. This really forces us to
         move some of the "after_draw" handling into another thread.
      
      3. Simplify the different modes of ddebug, both in the code and in
         the user interface, i.e. GALLIUM_DDEBUG. In particular, there's
         no 'pipelined' anymore, since we're always pipelined; and 'noflush'
         is replaced by 'flush', since we no longer flush by default.
      
      4. Fix the fences in pipelining mode. They previously relied on writes
         via pipe_context::clear_buffer. However, on radeonsi, those could
         (quite reasonably) end up in the SDMA buffer. So we use the newly
         added PIPE_FLUSH_{TOP,BOTTOM}_OF_PIPE fences instead.
      
      5. Improve pipelined mode overall, using the finer grained information
         provided by the new fences.
      
      Overall, the result is that pipelined mode should be more useful, and
      using ddebug in default mode is much less invasive, in the sense that
      it changes the overall driver behavior less (which is kind of crucial
      for a driver debugging tool).
      
      An example of the new hang debug output:
      
        Gallium debugger active.
        Hang detection timeout is 1000ms.
        GPU hang detected, collecting information...
      
        Draw #   driver  prev BOP  TOP  BOP  dump file
        -------------------------------------------------------------
        2          YES      YES    YES  NO   /home/nha/ddebug_dumps/shader_runner_19919_00000000
        3          YES      NO     YES  NO   /home/nha/ddebug_dumps/shader_runner_19919_00000001
        4          YES      NO     YES  NO   /home/nha/ddebug_dumps/shader_runner_19919_00000002
        5          YES      NO     YES  NO   /home/nha/ddebug_dumps/shader_runner_19919_00000003
      
        Done.
      
      We can see that there were almost certainly 4 draws in flight when
      the hang happened: the top-of-pipe fence was signaled for all 4 draws,
      the bottom-of-pipe fence for none of them. In virtually all cases,
      we'd expect the first draw in the list to be at fault, but due to the
      GPU parallelism, it's possible (though highly unlikely) that one of
      the later draws causes a component to get stuck in a way that prevents
      the earlier draws from making progress as well.
      
      (In the above example, there were actually only 3 draws truly in flight:
      the last draw is a blit that waits for the earlier draws; however, its
      top-of-pipe fence is emitted before the cache flush and wait, and so
      the fact that the draw hasn't truly started yet can only be seen from a
      closer inspection of GPU state.)
      Acked-by: default avatarMarek Olšák <marek.olsak@amd.com>
      c9fefa06
    • Nicolai Hähnle's avatar
      222a2fb9
  14. 13 Sep, 2017 1 commit
  15. 22 Aug, 2017 3 commits
  16. 02 Aug, 2017 3 commits
  17. 05 Jul, 2017 1 commit
    • Nicolai Hähnle's avatar
      ddebug: handle some cases of non-TGSI shaders · d91f97f9
      Nicolai Hähnle authored
      NIR shaders are not captured properly in pipelined mode currently. This
      would require shader cloning, which requires linking all the Gallium
      drivers against NIR. We can always do that later.
      
      v2: avoid immediate crashes in pipelined mode
      
      Reviewed-by: Marek Olšák <marek.olsak@amd.com> (v1)
      d91f97f9
  18. 10 May, 2017 5 commits
  19. 14 Apr, 2017 1 commit
  20. 30 Mar, 2017 1 commit
  21. 06 Mar, 2017 3 commits