<div dir="ltr">On 2 May 2013 12:54, Chris Wilson <span dir="ltr"><<a href="mailto:chris@chris-wilson.co.uk" target="_blank">chris@chris-wilson.co.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, May 02, 2013 at 09:07:08AM -0700, Eric Anholt wrote:<br>
> Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> writes:<br>
><br>
> > On Thu, May 02, 2013 at 07:26:06AM -0700, Paul Berry wrote:<br>
> >>    Can you provide a documentation reference for why the value we're<br>
> >>    currently programming (0xfffff001) is unsafe, and why 0x7fff0001 is<br>
> >>    correct?� I don't see anything in the bspec.<br>
> ><br>
> > The largest GTT size for gen6 is 2GiB (it can be smaller on the whim of<br>
> > the BIOS, though we try to reset it back to 2GiB in i915.ko). The upper<br>
> > bound is used by the hardware to prevent invalid reads and return 0,<br>
> > this is the value we program to ~4GiB. The cause of these hangs is the<br>
> > constant data being read from addresses above 2GiB i.e. beyond the end<br>
> > of the GTT - and so prevented by programming the upper bound to the end<br>
> > of the GTT. Those with access to the simulator can hopefully verify<br>
> > this, and perhaps we should add this to the set of known bad commands in<br>
> > igt.<br>
><br>
> The simulator has no complaints about these batches.<br>
><br>
> I don't think your model of how the constants work (that there's some<br>
> undefined, possibly >2gb address being loaded at shader dispatch time,<br>
> which is fixed by sending these packets) is actually how they work --<br>
> From my reading, the constants are loaded at constant packet time into a<br>
> small buffer on the GPU.  If the last packet and the shader disagree<br>
> about that buffer, the GPU sometimes blows up.<br>
<br>
</div></div>That wouldn't explain why setting the DynamicStateUpperBound to 2GiB<br>
also works around the hang, would it?<br>
<div class="HOEnZb"><div class="h5">-Chris<br></div></div></blockquote><div><br></div><div>Oh, it wasn't clear from your previous email that this was the case.  In that case I like Ken's suggestion of setting the DynamicStateUpperBound to the end of the batch buffer.  I think it's sensible to apply Eric's fix as well, just to be on the safe side.<br>
<br>Ken, how long ago did you bump the kernel requirement to ensure relaxed relocation support?  If it was recent, then Eric's fix should be the one we backport to stable releases.<br></div></div></div></div>