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-0001.pgp>