On Tue, Oct 24, 2017 at 2:10 PM, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> 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. > I'm having a bit of trouble parsing that. Are you saying that the L3 is trying to pull from the LLC even though we've disabled it through the PTE?
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
