On Tue, Dec 15, 2015 at 10:24:13AM +0000, Chris Wilson wrote: > On Tue, Dec 15, 2015 at 10:09:30AM +0000, Chris Wilson wrote: > > On Mon, Dec 14, 2015 at 07:25:13PM +0200, Ville Syrjälä wrote: > > > On Mon, Dec 14, 2015 at 04:58:54PM +0000, Chris Wilson wrote: > > > > On Mon, Dec 14, 2015 at 06:23:49PM +0200, ville.syrjala@xxxxxxxxxxxxxxx wrote: > > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > > > MI_BATCH_BUFFER is nasty since it requires that userspace pass in the > > > > > correct batch length. > > > > > > > > > > Let's switch to using MI_BATCH_BUFFER_START instead (like we do on > > > > > other platforms). Then we don't have to specify the batch length > > > > > at all, and the CS will instead execute until it sees the > > > > > MI_BATCH_BUFFER_END. > > > > > > > > Oh. My. Gosh. There's a BB_START?!!! > > > > > > Looks like ;) At least my 830 seems perfectly happy with it. Well, > > > as happy as it's ever been. Though I still couldn't get it complete > > > a piglit run without hanging last I tried. > > > > > > > > > > > > We still need the batch length since we do the CS TLB workaround > > > > > and copy the batch into the permanently pinned scratch object > > > > > and execute it from there. But for this we can simply use the > > > > > batch object length when the user hasn't specified the actual > > > > > batch length. So specifying the batch length becomes just a > > > > > way to optimize the batch copy a little bit. > > > > > > > > > > We lost batch_len from a bunch of igts (including the quiesce batch) > > > > > so without this igt is utterly broken on 830/845. Also some igts such > > > > > as gem_cpu_reloc never specified the batch_len and so didn't work. > > > > > With MI_BATCH_BUFFER_START we don't have to fix up igt every time > > > > > someone forgets that 830/845 exist. > > > > > > > > > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > Looks sane. > > > > Checked against bspec, and it does indeed list BB_START for 830/845 and > > we already comply with the errata. Yeah, the coloring stuff should be enough. > > The other question, does this obsolete our work around? Can I be that > optimisitic? The CS TLB one? I think I tried it at some point, and things till failed. But stuff fails even with the w/a (like I said piglit will hang the GPU eventually), so I can't be sure that I actually tested the CS TLB fail. I think I need to retest at some point. As far as the docs go, I only remember it mentioning some TLB fail affecting the blitter. I guess the CS TLB fail isn't actually documented anywhere? -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
