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.
pgpZ5a6t4YDSB.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
