nouveau: synchronize "scratch runout" destruction with the command stream

When nvc0_push_vbo calls nouveau_scratch_done it does not mean
scratch buffers can be freed immediately. It means "when hardware
advances to this place in the command stream the scratch buffers
can be freed".

To fix it, just postpone scratch runout destruction after current
fence is signalled.

The bug existed for a very long time. Nobody noticed, because
"scratch runout" code path is rarely executed.

Fixes hang at the very beginning of first mission in "Serious Sam 3"
on nve7/gk107. It manifested as:

nouveau E[   PFIFO][0000:01:00.0] read fault at 0x000a9e0000 [PTE] from GR/GPC0/PE_2 on channel 0x007f853000 [Sam3[17056]]

Cc: "10.4 10.5" <mesa-stable@lists.freedesktop.org>
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu>

1 files changed, 5 insertions, 3 deletions

diff --git a/src/gallium/drivers/nouveau/nouveau_context.h b/src/gallium/drivers/nouveau/nouveau_context.h
index 14608d3..c2ba015 100644
--- a/src/gallium/drivers/nouveau/nouveau_context.h
+++ b/src/gallium/drivers/nouveau/nouveau_context.h
@@ -40,8 +40,10 @@ struct nouveau_context {
       unsigned end;
       struct nouveau_bo *bo[NOUVEAU_MAX_SCRATCH_BUFS];
       struct nouveau_bo *current;
-      struct nouveau_bo **runout;
-      unsigned nr_runout;
+      struct runout {
+         unsigned nr;
+         struct nouveau_bo *bo[0];
+      } *runout;
       unsigned bo_size;
    } scratch;
 
@@ -71,7 +73,7 @@ static INLINE void
 nouveau_scratch_done(struct nouveau_context *nv)
 {
    nv->scratch.wrap = nv->scratch.id;
-   if (unlikely(nv->scratch.nr_runout))
+   if (unlikely(nv->scratch.runout))
       nouveau_scratch_runout_release(nv);
 }