On Thu, Jan 22, 2015 at 02:24:18PM +0100, Daniel Vetter wrote: > On Thu, Jan 22, 2015 at 2:13 PM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > This looked like an odd regression from > > > > commit ec5cc0f9b019af95e4571a9fa162d94294c8d90b > > Author: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Date: Thu Jun 12 10:28:55 2014 +0100 > > > > drm/i915: Restrict GPU boost to the RCS engine > > > > but in reality it undercovered a much older coherency bug. The issue that > > boosting the GPU frequency on the BCS ring was masking was that we could > > wake the CPU up after completion of a BCS batch and inspect memory prior > > to the write cache being fully evicted. In order to serialise the > > breadcrumb interrupt (and so ensure that the CPU's view of memory is > > coherent) we need to perform a post-sync operation in the MI_FLUSH_DW. > > > > Testcase: gpuX-rcs-gpu-read-after-write > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: stable@xxxxxxxxxxxxxxx > > We also need this in gen8_emit_flush and gen6_bsd_ring_flush I think. > > And interesting that the subsequent seqno write can apparently be > reordered with cache flushing. Or do we just need lots more of those > (wasn't the magic number once 32 or so)? That magic number was for the reordering of the seqno write with interrupt generation, iirc. But yes, it does sound oddly reminiscent. At least they did give us post-sync operations, even if we always end up having to use then. -Chris -- Chris Wilson, Intel Open Source Technology Centre -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html