From 5e92480d1f57e82c9367e45d3ad5e61c3cd6a1ef Mon Sep 17 00:00:00 2001 From: Nicolai Hähnle Date: Sun, 22 Oct 2017 17:38:53 +0200 Subject: radeonsi: document some subtle details of fence_finish & fence_server_sync MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit v2: remove the change to si_fence_server_sync, we'll handle that more robustly Reviewed-by: Marek Olšák (v1) --- src/gallium/drivers/radeonsi/si_fence.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/src/gallium/drivers/radeonsi/si_fence.c b/src/gallium/drivers/radeonsi/si_fence.c index 701e8df9cf..8100719299 100644 --- a/src/gallium/drivers/radeonsi/si_fence.c +++ b/src/gallium/drivers/radeonsi/si_fence.c @@ -175,6 +175,28 @@ static boolean si_fence_finish(struct pipe_screen *screen, if (rctx && rfence->gfx_unflushed.ctx == rctx && rfence->gfx_unflushed.ib_index == rctx->num_gfx_cs_flushes) { + /* Section 4.1.2 (Signaling) of the OpenGL 4.6 (Core profile) + * spec says: + * + * "If the sync object being blocked upon will not be + * signaled in finite time (for example, by an associated + * fence command issued previously, but not yet flushed to + * the graphics pipeline), then ClientWaitSync may hang + * forever. To help prevent this behavior, if + * ClientWaitSync is called and all of the following are + * true: + * + * * the SYNC_FLUSH_COMMANDS_BIT bit is set in flags, + * * sync is unsignaled when ClientWaitSync is called, + * * and the calls to ClientWaitSync and FenceSync were + * issued from the same context, + * + * then the GL will behave as if the equivalent of Flush + * were inserted immediately after the creation of sync." + * + * This means we need to flush for such fences even when we're + * not going to wait. + */ rctx->gfx.flush(rctx, timeout ? 0 : RADEON_FLUSH_ASYNC, NULL); rfence->gfx_unflushed.ctx = NULL; -- cgit v1.2.3