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

[Eric Anholt]

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

> 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.

Not without using CPUID or parsing /proc/cpuinfo, but given that it's
all heuristics, guessing "about 3MB on this CPU" or whatever sounds fine
to me.
-------------- 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/3c1a9942/attachment.pgp>