On Thu, Oct 06, 2011 at 11:00:18AM -0700, Eric Anholt wrote: > 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. >
Ok, we drop the patch. I *do* think it doesn't hurt, and it will make things just work if we ever change the GFX_MODE bit, but we can always re add this later as well. I don't understand the pipeline flushing well enough to push it any further. Ben
pgptn8SU9htdA.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
