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?!!! > 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. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
