On Wednesday 8 February 2012 18:28:05 Michel Dänzer wrote: > On Fre, 2012-02-03 at 17:32 +0000, Simon Farnsworth wrote: > > r300g is able to sleep until a fence completes rather than busywait > > because it creates a special buffer object and relocation that stays > > busy until the CS containing the fence is finished. > > > > Copy the idea into r600g, and use it to sleep if the user asked for an > > infinite wait, falling back to busywaiting if the user provided a > > timeout. > > > > Signed-off-by: Simon Farnsworth <simon.farnswo...@onelan.co.uk> > > --- > > > > v3: At Dave Airlie's suggestion on dri-devel, make use of the BO to give > > us a fighting chance of recovering after a GPU reset. > > > > We know that the fence will never be signalled by hardware if the dummy > > BO has gone idle - we use that information to escape the loop. This > > might be a useful addition to the 8.0 branch. > > That's a nifty trick. :) > It's just a shame that the rest of recovering from a GPU reset isn't as simple - at least this stops us busywaiting eternally after the kernel's detected a CP stall.
> > diff --git a/src/gallium/drivers/r600/r600_hw_context.c > > b/src/gallium/drivers/r600/r600_hw_context.c index 8eb8e6d..acfa494 > > 100644 > > --- a/src/gallium/drivers/r600/r600_hw_context.c > > +++ b/src/gallium/drivers/r600/r600_hw_context.c > > @@ -1623,6 +1623,13 @@ void r600_context_emit_fence(struct r600_context > > *ctx, struct r600_resource *fen> > > ctx->pm4[ctx->pm4_cdwords++] = 0; /* DATA_HI > > */ > > ctx->pm4[ctx->pm4_cdwords++] = PKT3(PKT3_NOP, 0, 0); > > ctx->pm4[ctx->pm4_cdwords++] = r600_context_bo_reloc(ctx, fence_bo, > > RADEON_USAGE_WRITE);> > > + > > + /* Create a dummy BO so that fence_finish without a timeout can sleep > > waiting for completion */ + *sleep_bo = (struct r600_resource*) > > + pipe_buffer_create(&ctx->screen->screen, > > PIPE_BIND_CUSTOM, > > + PIPE_USAGE_STAGING, 1); > > + /* Add the fence as a dummy relocation. */ > > + r600_context_bo_reloc(ctx, *sleep_bo, RADEON_USAGE_READWRITE); > > Sorry for only thinking of this now, but what's the advantage of doing > this here, rather than in r600_create_fence()? Seems like that would be > simpler and cleaner. I've done it here because this is the bit of code that deals with all the hardware-related stuff, and it already knows about writing out relocations. I have no particular opinion either way, though, and wouldn't get upset about moving it. Thoughts? -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
