Re: [PATCH 10/10] drm/i915: Use MI_BATCH_BUFFER_START on 830/845

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux