[Intel-gfx] [RFC PATCH 00/11] i915 HW context support

[Eric Anholt]

On Thu, 16 Feb 2012 14:58:59 +0100, Ben Widawsky <ben at bwidawsk.net> wrote:
> On Thu, 16 Feb 2012 13:21:42 +0100
> Ben Widawsky <ben at bwidawsk.net> wrote:
> 
> > On Thu, 16 Feb 2012 13:04:14 +0100
> > Ben Widawsky <ben at bwidawsk.net> wrote:
> > 
> > > On Wed, 15 Feb 2012 12:33:38 -0800
> > > Eric Anholt <eric at anholt.net> wrote:
> > > 
> > > > On Tue, 14 Feb 2012 22:09:07 +0100, Ben Widawsky <ben at bwidawsk.net> wrote:
> > > > > These patches are a heavily revised version of the patches I wrote over
> > > > > a year ago. These patches have passed basic tests on SNB, and IVB, and
> > > > > older versions worked on ILK.  In theory, context support should work
> > > > > all the way back to Gen4, but I haven't tested it. Also since I suspect
> > > > > ILK may be unstable, so the code has it disabled for now.
> > > > > 
> > > > > HW contexts provide a way for the GPU to save an restore certain state
> > > > > in between batchbuffer boundaries. Typically, GPU clients must re-emit
> > > > > the entire state every time they run because the client does not know
> > > > > what has been destroyed since the last time. With these patches the
> > > > > driver will emit special instructions to do this on behalf of the client
> > > > > if it has registered a context, and included that with the batchbuffer.
> > > > 
> > > > These patches look pretty solid.  In particular, the API
> > > > (create/destroy/context id in execbuf) looks like just what we want for
> > > > Mesa.  I'll try to get around to testing it out soon (I'm poking at some
> > > > performance stuff currently where this might become relevant soon).
> > > 
> > > I've just started noticing GPU hangs with Ken's test mesa branch on
> > > nexuiz with vsync, full 13x7 and max effects.  It seems to work fine 
> > > with variations like windowed, lower detail, etc. Although it looks
> > > weird on IVB, I cannot reproduce the hangs there. Also, I'd never seen 
> > > the hangs before this morning, and I'm not sure what has changed. So 
> > > FYI, you may want to start out with IVB (unless you want to help me 
> > > figure out what is broken on SNB :-)
> > > 
> > > I've not tried very hard, but so far it only seems to occur when doing
> > > context switches, however MI_SET_CONTEXT is nowhere in the error state.
> > 
> > Seems like sandybridge + fullscreen nexuiz is the exact fail combo.
> 
> So here was part of Ken's patch
> -   brw->state.dirty.brw |= BRW_NEW_CONTEXT | BRW_NEW_BATCH;
> +   if (intel->hw_ctx == NULL)
> +      brw->state.dirty.brw |= BRW_NEW_CONTEXT;
> +
> +   brw->state.dirty.brw |= BRW_NEW_BATCH;
> 
> 
> If I go back to normal and use contexts, but also set BRW_NEW_CONTEXT, I
> don't get hangs. So it sounds like some part of the state isn't being
> saved or restored properly. Still trying to figure out what changed to
> make it break.

Likely.  The *idea* behind CONTEXT vs BATCH was that you could just turn
the CONTEXT flagging off, but since there was no effective difference
it's totally untested until now.

> As a side note, IVB has weird artifacts which I thought were just
> because I was using an experimental mesa, but now think it's likely the
> same cause. Maybe you can figure out what isn't be saved or restored
> based on seeing IVB?

IVB weird rendering in nexuiz appears to be related to some failure in
the FS codegen.  I think.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20120216/2f10b13c/attachment.sig>