Quoting Jason Ekstrand (2017-10-24 22:03:36) > On Tue, Oct 24, 2017 at 9:06 AM, Chris Wilson <ch...@chris-wilson.co.uk> > wrote: > > Through the use of mocs, we can define the cache usage for any surface > used by the GPU. In particular, we can request that L3 cache be > allocated for either a read/write miss so that subsequent reads can be > fetched from cache rather than memory. A consequence of this is that if > we allocate a L3/LLC cacheline for a read and the object is changed in > main memory (e.g. a PCIe write bypassing the CPU) then the next read > will be serviced from the stale cache and not from the new data in > memory. This is an issue for external PRIME buffers where we may miss > the updates entirely if the image is small enough to fit within our > cache. > > Currently, we have a single bit to mark all external buffers so use that > to tell us when it is unsafe to use a cache override in mocs and > fallback to the PTE value instead (which should be set to the correct > cache level to be coherent amongst all active parties: PRIME, scanout and > render). This may be refined in future to limit the override to buffers > outside the control of mesa; as buffers being shared between mesa > clients should be able to coordinate themselves without resolves. > > Why are we throwing away L3 caching here and in gen7 above? We should be able > to handle L3 caching with manual texture/render cache invalidates/flushes. > Our > performance is already going to be not great with linear buffers with no LLC, > we shouldn't kill it completely.
Because the L3 is shadowing the updates in memory (that bypass the ring/system-agent entirely) and not being invalidated. When you then read back from the L3/LLC you get stale data. -Chris _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
