On 05/10/2013 10:16 AM, Eric Anholt wrote:
Chad Versace <chad.vers...@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 <matts...@gmail.com> Signed-off-by: Chad Versace <chad.vers...@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. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
