On Wed, Mar 26, 2014 at 05:14:05AM +0000, Gupta, Sourab wrote: > On Tue, 2014-03-25 at 10:59 +0000, Chris Wilson wrote: > > On Tue, Mar 25, 2014 at 03:23:34PM +0530, sourab.gupta@xxxxxxxxx wrote: > > > From: Akash Goel <akash.goel@xxxxxxxxx> > > > > > > Added a new rendering specific Workaround 'WaTlbInvalidateStoreDataBefore'. > > > This workaround has to be applied before doing TLB Invalidation on render ring. > > > In this WA, before pipecontrol with TLB invalidate set, need to add 2 MI > > > Store data commands. > > > Without this, hardware cannot guarantee the command after the PIPE_CONTROL > > > with TLB inv will not use the old TLB values. > > > > Note, that our command programming sequence already has multiple dword > > writes between the flush of the last batch and the invalidation of the > > next. > > > > Is this w/a still required? Why? > > -Chris > > > Hi Chris, > Are you referring to the MI_STORE_DWORD_INDEX commands emitted as a part > of add_request functions? > We couldn't find any other place where we are storing dwords between > flush of last batch and invalidation of next. > In that case, we agree that as a part of command programming sequence, > we'll have one set of store dwords emitted. > > But, as per spec, it is required to emit 2 sets of store dwords before > the tlb invalidation. At this moment, I am upset how vague this recommendation is. Why don't the LRI count? Is there a timing requirement? Do the stores have to be different pages to flush a TLB etc? > Also, our motive for having this w/a is just being paranoid, and not > assuming that dwords would already have been emitted before doing tlb > invalidation. So, we try to explicitly ensure the same through our w/a. Which would be as easy as doubling up the STORE_DW(seqno). -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
