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 <andresx7@gmail.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>

diff --git a/src/gallium/drivers/radeonsi/si_fence.c b/src/gallium/drivers/radeonsi/si_fence.c
index cce9a33..0f15df4 100644 (file)
--- 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 2b1b6dd..458b90f 100644 (file)
--- 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;