[Mesa-dev] [PATCH 9/9] i965/drm: Add stall warnings when mapping or waiting on BOs.

[Chris Wilson]

On Mon, Apr 10, 2017 at 10:09:17AM +0200, Daniel Vetter wrote:
> On Mon, Apr 10, 2017 at 12:18:54AM -0700, Kenneth Graunke wrote:
> > diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > index 8ccc5a276b9..6e4b55cf9ec 100644
> > --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> > @@ -100,7 +100,7 @@ intel_batchbuffer_reset(struct intel_batchbuffer *batch,
> >  
> >     batch->bo = brw_bo_alloc(bufmgr, "batchbuffer", BATCH_SZ, 4096);
> >     if (has_llc) {
> > -      brw_bo_map(batch->bo, true);
> > +      brw_bo_map(NULL, batch->bo, true);
> 
> Why NULL here? Mapping a fresh buffer might incur a clflush, which isn't
> cheap. I think for atom tuning you want to hear about those.

I thought it was because there is no brw pointer at this point.

For !llc, please do a WB mapping of the batch on first use, then a WC
mapping thereafter. The clflush at execbuf is "free" - or rather it is
done asynchronously, after taking advantage of the WB for any fixups
required. Afterwards, you want to avoid clflushing which is where the
pwrite was useful but now you can use the WC mmap to avoid the penalty
of performing a copy and avoiding the WB/clflush 2-pass.

In general, does 10us resolution require compensation for clock_gettime()
overhead and checking against clock_getres()? (I hope getime is using
MONOTONIC_RAW!) Longer term feeding the callsite down to set-domain is
useful to make diagnosing the problem easier. I tried to give the name
as being the closest GL entry point along with the function/line of the
culprit.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre