[Intel-gfx] [PATCH 3/3] drm/i915: Use PIPE_CONTROL for flushing on gen6+.

Ben Widawsky ben at bwidawsk.net
Thu Oct 6 21:01:05 CEST 2011


On Thu, Oct 06, 2011 at 11:00:18AM -0700, Eric Anholt wrote:
> On Thu, 6 Oct 2011 05:15:23 +0000, Ben Widawsky <ben at bwidawsk.net> 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 <ben at bwidawsk.net> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20111006/d59aff9d/attachment.sig>


More information about the Intel-gfx mailing list