On Saturday, July 22, 2017 2:14:28 AM PDT Chris Wilson wrote: > Quoting Kenneth Graunke (2017-07-22 00:17:47) > > 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. > > > > This is largely unnecessary - it's just ancient and crufty code. We can > > use the same persistent mapping paths on all platforms. On non-ancient > > kernels, this will use a write combining map, which should be reasonably > > fast. > > > > One aspect that is worse: we do occasionally grow the program cache BO, > > and copy the old contents to the newer BO. This will suffer from UC > > readback performance now. To mitigate this, we use the MOVNTDQA based > > streaming memcpy on platforms with SSE 4.1 (all Gen7+ atoms). Gen4-5 > > are unfortunately going to be penalized. > > > > v2: Add MOVNTDQA path, rebase on other map flag changes. > > Don't forgot cache->bo_used_by_gpu!
Right! fixed locally, thanks!
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
