On Thu, 6 Oct 2011 05:15:23 +0000, Ben Widawsky <[email protected]> wrote: Non-text part: multipart/signed > On Wed, Oct 05, 2011 at 05:59:31PM -0700, Eric Anholt wrote: > > On Wed, 5 Oct 2011 15:57:13 -0700, Ben Widawsky <[email protected]> wrote: > > > I think we also want a TLB invalidate here, bit 18. This requires another > > > workaround before issuing this flush: We need 2 Store Data Commands (such > > > as > > > MI_STORE_DATA_IMM or MI_STORE_DATA_INDEX) before sending PIPE_CONTROL w/ > > > stall > > > (20) and TLB inv bit (18) set > > > > From the docs for GFX_MODE: > > > > "This field controls the invalidation if the TLB cache inside the > > hardware. When enabled this bit limits the invalidation of the TLB > > only to batch buffer boundaries or to pipe_control commands which > > have the TLB invalidation bit set. If disabled, the TLB caches are > > flushed for every full flush of the pipeline" > > > > We're already getting TLB invalidate at batchbuffer boundaries > > (actually, even more: every pipeline stall, since that bit is 0 on my > > hardware). What would we need this new flush for? > > Does this only mean after each batchbuffer (MI_BATCH_BUFFER_END) or also > before actually jumping to the location at MI_BATCH_BUFFER_START? If so, > what happens when we map or unmap, in between batches? Won't the TLBs > need to be flushed in between?
Are you talking about for GTT mapped access? TLBs for those are flushed at PTE update. > Also, wouldn't it be nice for the kernel to flush TLBs without having to > submit a batch (no specific use case in mind for this)? Why would it be nice? We know when we need them flushed for our needs, there's that table that tells when the hardware flushes them, and the two appear to add up to "don't do anything else" to me.
pgp1Xvf3oqVkQ.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
