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(-) _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev