<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [BXT] up to 6% performance drop with "i965: Set "Subslice Hashing Mode" to 16x16 on Apollolake"" href="https://bugs.freedesktop.org/show_bug.cgi?id=102272#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [BXT] up to 6% performance drop with "i965: Set "Subslice Hashing Mode" to 16x16 on Apollolake"" href="https://bugs.freedesktop.org/show_bug.cgi?id=102272">bug 102272</a> from <a class="email" href="mailto:eero.t.tamminen@intel.com" title="Eero Tamminen <eero.t.tamminen@intel.com>"> Eero Tamminen</a> <pre>I.e. it seems that things depending on raw sampler throughput have perf drops, and everything that is completely memory bandwidth bound improves a bit. If latter gets verified by bisection, I'm not sure whether anything should be done about this bug, as bandwidth limitations should be more common for real-world use-cases than being purely sampler limited. Both FurMark and GiMark use anisotropic filtering, but I think changing hash mode for a draw, based on sampling mode, would have too much overhead. Terrain tessellation doesn't use costly filtering, so for a drop in that I don't have yet a good explanation. It's possible that using larger (16x16) area for the cross-slice load balancing checkerboard works worse for very small triangles, but impact "should" then be visible both in instancing & tessellation shader terrain tests, as both run about same amount of pixel shader instances, look same and have identical pixel shaders. Maybe different vertex order explain that difference.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>