<div dir="ltr">On Tue, Oct 24, 2017 at 2:10 PM, Chris Wilson <span dir="ltr"><<a href="mailto:chris@chris-wilson.co.uk" target="_blank">chris@chris-wilson.co.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quoting Jason Ekstrand (2017-10-24 22:03:36)<br>
<span class="">> On Tue, Oct 24, 2017 at 9:06 AM, Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> wrote:<br>
><br>
>     Through the use of mocs, we can define the cache usage for any surface<br>
>     used by the GPU. In particular, we can request that L3 cache be<br>
>     allocated for either a read/write miss so that subsequent reads can be<br>
>     fetched from cache rather than memory. A consequence of this is that if<br>
>     we allocate a L3/LLC cacheline for a read and the object is changed in<br>
>     main memory (e.g. a PCIe write bypassing the CPU) then the next read<br>
>     will be serviced from the stale cache and not from the new data in<br>
>     memory. This is an issue for external PRIME buffers where we may miss<br>
>     the updates entirely if the image is small enough to fit within our<br>
>     cache.<br>
><br>
>     Currently, we have a single bit to mark all external buffers so use that<br>
>     to tell us when it is unsafe to use a cache override in mocs and<br>
>     fallback to the PTE value instead (which should be set to the correct<br>
>     cache level to be coherent amongst all active parties: PRIME, scanout and<br>
>     render). This may be refined in future to limit the override to buffers<br>
>     outside the control of mesa; as buffers being shared between mesa<br>
>     clients should be able to coordinate themselves without resolves.<br>
><br>
</span><span class="">> Why are we throwing away L3 caching here and in gen7 above?  We should be able<br>
> to handle L3 caching with manual texture/render cache invalidates/flushes.  Our<br>
> performance is already going to be not great with linear buffers with no LLC,<br>
> we shouldn't kill it completely.<br>
<br>
</span>Because the L3 is shadowing the updates in memory (that bypass the<br>
ring/system-agent entirely) and not being invalidated. When you then<br>
read back from the L3/LLC you get stale data.<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">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?<br></div></div>