[Mesa-dev] [PATCH 7/7] i965: Use persistent CPU mappings for the program cache even on non-LLC.

[Chris Wilson]

On Tue, Jan 17, 2017 at 10:40:26AM +0100, Eduardo Lima Mitev wrote:
> Patch 5-7 look good, but I prefer that more experienced eyes take a look
> too.
> 
> Acked-by: Eduardo Lima Mitev <elima at igalia.com>
> 
> On 01/17/2017 08:14 AM, Kenneth Graunke wrote:
> > The non-LLC story was a horror show.  We uploaded data via pwrite
> > (drm_intel_bo_subdata), which would stall if the cache BO was in
> > use (being read) by the GPU.  Obviously, we wanted to avoid that.
> > So, we tried to detect whether the buffer was busy, and if so, we'd
> > allocate a new BO, map the old one read-only (hopefully not stalling),
> > copy all shaders compiled since the dawn of time to the new buffer,
> > upload our new one, toss the old BO, and let the state upload code
> > know that our program cache BO changed.  This was a lot of extra data
> > copying, and flagging BRW_NEW_PROGRAM_CACHE would also cause a new
> > STATE_BASE_ADDRESS to be emitted, stalling the entire pipeline.
> > 
> > Not only that, but our rudimentary busy tracking consistented of a flag
> > set at execbuf time, and not cleared until we threw out the program
> > cache BO.  So, the first shader upload after any drawing would hit this
> > "abandon the cache and start over" copying path.
> > 
> > None of this is necessary - it's just ancient crufty code.  We can
> > use the same persistent mapping paths on all platforms.  On non-LLC
> > platforms, we simply need to clflush after memcpy'ing in new shaders,
> > so they're visible to the GPU.  This is not only better, but the code
> > is also significantly simpler.

Or just use a WC mapping, for even greater simplicity.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre