iris: fix in fences backend for ext_external_objects edge case
authorEleni Maria Stea <elene.mst@gmail.com>
Sun, 14 Feb 2021 18:28:02 +0000 (20:28 +0200)
committerMarge Bot <eric+marge@anholt.net>
Tue, 2 Mar 2021 05:47:06 +0000 (05:47 +0000)
EXT_external_objects require we call glSignalSemaphoreEXT followed by a
glFlush. If the rendering workload is small when Signal and Flush
take place the relevant batch buffers with the actual rendering might
have been submitted already. In that case the following condition is met:
(iris_batch_bytes_used(batch) == 0). This causes:
glFlush() --> iris_fence_flush() -> iris_batch_flush() ->
_iris_batch_flush() to no-op, and so the fence doesn't get submitted to the
kernel. Then when anv tries to submit an execuf2 that must wait on the
shared VkSempahore / drm_syncobj fence, there isn't one and the kernel
rejects the batchbuffer causing an -EINVAL return of the execbuf2 ioctl
and a VK_DEVICE_LOST error. Empty batch buffers do have typically one
fence attached, but the ones carrying the extra fence from a
glSignalSempahore() call do have at least 2.

See also: the discussion in MR!4337.

v2: Changed the batch struct to have a contains_fence_signal variable
that is set to true when i915_EXEC_FENCE_SIGNAL fence is added to the
batch and off when batch is reset (Tapani Pälli)

Authored-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reported-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Eleni Maria Stea <elene.mst@gmail.com>
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8861>

src/gallium/drivers/iris/iris_batch.c
src/gallium/drivers/iris/iris_batch.h
src/gallium/drivers/iris/iris_fence.c

index 8a87f59..5e20111 100644 (file)
@@ -181,6 +181,7 @@ iris_init_batch(struct iris_context *ice,
    batch->state_sizes = ice->state.sizes;
    batch->name = name;
    batch->ice = ice;
+   batch->contains_fence_signal = false;
 
    batch->fine_fences.uploader =
       u_upload_create(&ice->ctx, 4096, PIPE_BIND_CUSTOM,
@@ -394,6 +395,7 @@ iris_batch_reset(struct iris_batch *batch)
    batch->primary_batch_size = 0;
    batch->total_chained_batch_size = 0;
    batch->contains_draw = false;
+   batch->contains_fence_signal = false;
    batch->decoder.surface_base = batch->last_surface_base_address;
 
    create_batch(batch);
@@ -686,7 +688,8 @@ _iris_batch_flush(struct iris_batch *batch, const char *file, int line)
 {
    struct iris_screen *screen = batch->screen;
 
-   if (iris_batch_bytes_used(batch) == 0)
+   /* If a fence signals we need to flush it. */
+   if (iris_batch_bytes_used(batch) == 0 && !batch->contains_fence_signal)
       return;
 
    iris_measure_batch_end(batch->ice, batch);
index 302ebd5..51c407e 100644 (file)
@@ -162,6 +162,9 @@ struct iris_batch {
    /** Have we emitted any draw calls with next_seqno? */
    bool contains_draw_with_next_seqno;
 
+   /** Batch contains fence signal operation. */
+   bool contains_fence_signal;
+
    /**
     * Number of times iris_batch_sync_region_start() has been called without a
     * matching iris_batch_sync_region_end() on this batch.
index bc04fdc..843f0e6 100644 (file)
@@ -579,6 +579,7 @@ iris_fence_signal(struct pipe_context *ctx,
          if (iris_fine_fence_signaled(fine))
             continue;
 
+         ice->batches[b].contains_fence_signal = true;
          iris_batch_add_syncobj(&ice->batches[b], fine->syncobj,
                                 I915_EXEC_FENCE_SIGNAL);
       }