On Tue, Jan 12, 2016 at 04:30:03PM +0200, Mika Kuoppala wrote: > Chris Wilson <ch...@chris-wilson.co.uk> writes: > > > On Tue, Jan 12, 2016 at 12:05:06PM +0200, Mika Kuoppala wrote: > >> Chris Wilson <ch...@chris-wilson.co.uk> writes: > >> > - intel_ring_emit(ring, GFX_OP_PIPE_CONTROL(4) | > >> > PIPE_CONTROL_QW_WRITE | > >> > - PIPE_CONTROL_WRITE_FLUSH | > >> > - PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE); > >> > - intel_ring_emit(ring, ring->scratch.gtt_offset | > >> > PIPE_CONTROL_GLOBAL_GTT); > >> > - intel_ring_emit(ring, i915_gem_request_get_seqno(req)); > >> > + intel_ring_emit(ring, > >> > + GFX_OP_PIPE_CONTROL(4) | > >> > + PIPE_CONTROL_QW_WRITE | > >> > + PIPE_CONTROL_WRITE_FLUSH); > >> > >> Why no more PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE? > > > > I opened vim to add it back in and I coulnd't bring myself to commit > > that attrocity. > > I just noticed the asymmetry. Ilk doesn't need it?
Here and now, we are doing 8 writes (1 seqno, 6 scratch, 1 seqno again for good luck) simply to try and flush the pipecontrol queue to ensure the seqno write lands before the notify interrupt is asserted. The TC invalidate on the first and only first write is superfluous - it imposes a top of pipe stall when we already have a bottom of pipe stall in the flush (the write will not occur until the pipeline is drained). We do the TC invalidate along with the reset of the cache invalidation before the next batch. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
