[Mesa-dev] [PATCH 0/8] Fence and ddebug fixes, and a minor threading improvement
Nicolai Hähnle
nhaehnle at gmail.com
Mon Nov 13 14:03:28 UTC 2017
Hi all,
a bunch of fixes for things that I observed while trying to run the CTS
with hang debugging enabled:
- after the rebase, futex-based fences weren't actually getting enabled
- fixes to timeout handling and calculations
- an unrelated ddebug use-after-free bug
- finally, avoid even more driver thread syncs from si_fence_finish
By the way, running the CTS with hang debugging requires setting the
timeout very high (on the order of minutes). This is simply down to the
combination of asynchrony with some very CPU-intensive tests that rarely
trigger flushes. ddebug will start waiting for a fence as soon as a draw
call has been issued in the API thread. If the threading wrapper only
flushes batches every couple of seconds, and the driver flushes IBs only
every couple of minutes, this will lead to spurious hang reports unless
the timeout is set very high. The reason for waiting on fences from the
point the draw call was sent via the API is that we want to see hangs
that are internal to the driver. We could try to be smarter about that,
but it doesn't seem worth it.
Cheers,
Nicolai
--
.../auxiliary/util/u_threaded_context.c | 19 ++--
.../auxiliary/util/u_threaded_context.h | 11 ++-
src/gallium/drivers/ddebug/dd_draw.c | 6 +-
src/gallium/drivers/radeonsi/si_fence.c | 83 ++++++++++--------
src/gallium/drivers/radeonsi/si_hw_context.c | 3 +
src/util/u_queue.c | 2 +-
src/util/u_queue.h | 2 +-
7 files changed, 77 insertions(+), 49 deletions(-)
More information about the mesa-dev
mailing list