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 <el...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
