[Mesa-dev] [PATCH 2/2] i965/hsw: Set MOCS for surfaces

[Eric Anholt]

Chad Versace <chad.versace at linux.intel.com> writes:

> The drivers was setting MOCS (Memory Object Control State) to 0 for all
> objects. This patch sets it as following:
>     renderbuffer, depthbuffer => LLC uncacheable, L3 cacheable
>     texture, stencil, hiz => LLC cacheable, L3 cacheable
>
> The goal here is to avoid blowing out the LLC with too-large buffers.
>
> Performance gains:
>     Haswell Harris Beach GT3
>     Android 4.2.2
>     kernel based on 3.8-4fc7c97
>
>     GLBenchmark 2.5.1 Egypt HD C24Z16 Offscreen DXT1
> 	+32.0309% +/- 0.775397%,  n = 5, 95% confidence
>
>     GLBenchmark 2.7 T-Rex HD C24Z16 Offscreen Fixed timestep ETC1
> 	+20.2435% +/- 0.821163%,  n = 5, 95% confidence
>
> Tested-by: Matt Turner <mattst88 at gmail.com>
> Signed-off-by: Chad Versace <chad.versace at linux.intel.com>

There are two separate changes here:

- Make textures L3 cacheable.
- Change the RB caching to something new.

The L3 for textures seems obviously good.  That cache gets used for
almost nothing else currently (VS pull constants, which are small, and
instruction cache, is a bit larger but the working set is still very
small at any time within a frame).

The render cache change needs more data.  It seems obvious to me, and
the spec spells it out, that a change like this is trying to tune the
workload so that things that get cache hits less frequently (render
targets) don't get put in LLC such that their less-likely-to-hit
accesses push out something that would have been likely to have a cache
hit (texturing).

So, what if your render targets and your textures *both* fit in LLC?
This change needs testing across multiple apps and resolutions.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130510/544e26dd/attachment.pgp>