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

[Chad Versace]

On 05/10/2013 10:16 AM, Eric Anholt wrote:
> 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.

Can Mesa query for the size of the LLC? If so, then I'm considering assigning
each surface's LLC cacheability per draw call by taking into account the LLC size
and each surface's size and usage. What do you think? Of course, such a scheme
still needs wide testing before committing.