radeonsi: fix fence_server_sync() holding up extra work v2

When calling si_fence_server_sync(), the wait operation is associated
with the next kernel submission. Therefore, any unflushed work
submitted previous to fence_server_sync() will also be affected by
the wait.

To avoid adding the dependency to the unflushed work, we flush before
emitting the fence dependency.

v2: s/semaphore/fence

Signed-off-by: Andres Rodriguez <[email protected]>
Reviewed-by: Marek Olšák <[email protected]>

2 files changed, 28 insertions, 25 deletions

diff --git a/src/gallium/drivers/radeonsi/si_fence.c b/src/gallium/drivers/radeonsi/si_fence.c
index cce9a3302ab..0f15df4807c 100644
--- a/src/gallium/drivers/radeonsi/si_fence.c
+++ b/src/gallium/drivers/radeonsi/si_fence.c
@@ -114,30 +114,6 @@ struct pipe_fence_handle *si_create_fence(struct pipe_context *ctx,
 	return (struct pipe_fence_handle *)fence;
 }
 
-static void si_fence_server_sync(struct pipe_context *ctx,
-				 struct pipe_fence_handle *fence)
-{
-	struct r600_common_context *rctx = (struct r600_common_context *)ctx;
-	struct si_multi_fence *rfence = (struct si_multi_fence *)fence;
-
-	util_queue_fence_wait(&rfence->ready);
-
-	/* Unflushed fences from the same context are no-ops. */
-	if (rfence->gfx_unflushed.ctx &&
-	    rfence->gfx_unflushed.ctx == rctx)
-		return;
-
-	/* All unflushed commands will not start execution before
-	 * this fence dependency is signalled.
-	 *
-	 * Should we flush the context to allow more GPU parallelism?
-	 */
-	if (rfence->sdma)
-		si_add_fence_dependency(rctx, rfence->sdma);
-	if (rfence->gfx)
-		si_add_fence_dependency(rctx, rfence->gfx);
-}
-
 static bool si_fine_fence_signaled(struct radeon_winsys *rws,
 				   const struct si_fine_fence *fine)
 {
@@ -515,6 +491,31 @@ static void si_fence_server_signal(struct pipe_context *ctx,
 	si_flush_from_st(ctx, NULL, PIPE_FLUSH_ASYNC);
 }
 
+static void si_fence_server_sync(struct pipe_context *ctx,
+				 struct pipe_fence_handle *fence)
+{
+	struct r600_common_context *rctx = (struct r600_common_context *)ctx;
+	struct si_multi_fence *rfence = (struct si_multi_fence *)fence;
+
+	util_queue_fence_wait(&rfence->ready);
+
+	/* Unflushed fences from the same context are no-ops. */
+	if (rfence->gfx_unflushed.ctx &&
+	    rfence->gfx_unflushed.ctx == rctx)
+		return;
+
+	/* All unflushed commands will not start execution before
+	 * this fence dependency is signalled.
+	 *
+	 * Therefore we must flush before inserting the dependency
+	 */
+	si_flush_from_st(ctx, NULL, PIPE_FLUSH_ASYNC);
+
+	if (rfence->sdma)
+		si_add_fence_dependency(rctx, rfence->sdma);
+	if (rfence->gfx)
+		si_add_fence_dependency(rctx, rfence->gfx);
+}
 
 void si_init_fence_functions(struct si_context *ctx)
 {
diff --git a/src/gallium/drivers/radeonsi/si_get.c b/src/gallium/drivers/radeonsi/si_get.c
index 2b1b6dd2e7d..458b90fbe09 100644
--- a/src/gallium/drivers/radeonsi/si_get.c
+++ b/src/gallium/drivers/radeonsi/si_get.c
@@ -270,9 +270,11 @@ static int si_get_param(struct pipe_screen *pscreen, enum pipe_cap param)
 	case PIPE_CAP_TILE_RASTER_ORDER:
 	case PIPE_CAP_MAX_COMBINED_SHADER_OUTPUT_RESOURCES:
 	case PIPE_CAP_CONTEXT_PRIORITY_MASK:
-	case PIPE_CAP_FENCE_SIGNAL:
 		return 0;
 
+	case PIPE_CAP_FENCE_SIGNAL:
+		return sscreen->info.has_syncobj;
+
 	case PIPE_CAP_NATIVE_FENCE_FD:
 		return sscreen->info.has_fence_to_handle;